gRPC & High Performance APIs · レッスン

ヘルスチェックとReadiness Probe

標準のgRPCヘルスチェックプロトコルを使い、ロードバランサーやオーケストレーターがサービスのトラフィック受け入れ準備を把握できるようにします。

「ヘルスチェックとReadiness Probe」はCoddyKit上の無料gRPC & High Performance APIsレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはgRPC & High Performance APIs学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 gRPC & High Performance APIsコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Health Checks Matter

An orchestrator must know whether a service instance can handle requests. Sending traffic to a starting, overloaded, or broken instance causes errors.

The gRPC health checking protocol answers: is this service healthy?

The Standard Health Service

gRPC defines grpc.health.v1.Health with two methods:

Check — a one-shot status query
Watch — a stream of status updates

Status is SERVING, NOT_SERVING, or UNKNOWN.

Per-Service Status

A health request names a service. An empty name asks about the whole server; a specific name asks about one service, so you can report each independently.

Registering the Health Server (Go)

The health package provides a ready implementation you register on your server.

import 'google.golang.org/grpc/health'
import hpb 'google.golang.org/grpc/health/grpc_health_v1'

hs := health.NewServer()
hpb.RegisterHealthServer(s, hs)

Setting Status

Update status as your service transitions. Mark NOT_SERVING during startup or shutdown, then SERVING when ready.

hs.SetServingStatus('', hpb.HealthCheckResponse_SERVING)
hs.SetServingStatus('my.pkg.Orders', hpb.HealthCheckResponse_SERVING)

Readiness vs Liveness

Two distinct ideas:

Liveness: is the process alive? Restart if not.
Readiness: can it serve now? Remove from rotation if not, but do not restart.

Health status maps cleanly to readiness.

Kubernetes gRPC Probes

Kubernetes supports native gRPC probes. Point them at your health service.

readinessProbe:
  grpc:
    port: 9090
    service: my.pkg.Orders

Probing with grpc_health_probe

The grpc_health_probe binary lets you check health from a shell or older Kubernetes versions.

grpc_health_probe -addr=localhost:9090 -service=my.pkg.Orders

Watch for Live Updates

Smart load balancers use Watch to receive a stream of status changes, reacting instantly when an instance flips to NOT_SERVING instead of polling.

Graceful Shutdown

Before stopping, set status to NOT_SERVING and wait. Load balancers drain you out, in-flight requests finish, and clients avoid hitting a dying instance.

Tying Health to Dependencies

Report NOT_SERVING when a critical dependency (database, cache) is unreachable, so traffic routes only to instances that can actually do work.

Quick Check

Test your health-check knowledge.

Recap

You learned gRPC health checking:

The standard Health service offers Check and Watch
Status is per-service: SERVING, NOT_SERVING, UNKNOWN
Map health to readiness; pair with liveness probes
Kubernetes and grpc_health_probe consume it
Flip to NOT_SERVING for graceful drain and failed dependencies

よくある質問

「ヘルスチェックとReadiness Probe」レッスンは無料ですか？

はい。「ヘルスチェックとReadiness Probe」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、gRPC & High Performance APIsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 gRPC & High Performance APIsコースには全4レッスンが含まれています。

「ヘルスチェックとReadiness Probe」で何を学びますか？

標準のgRPCヘルスチェックプロトコルを使い、ロードバランサーやオーケストレーターがサービスのトラフィック受け入れ準備を把握できるようにします。ブラウザで直接実行するハンズオンコードでgRPC & High Performance APIsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

gRPC & High Performance APIsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのgRPC & High Performance APIsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「ヘルスチェックとReadiness Probe」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このgRPC & High Performance APIsレッスンでコードを書いて実行できますか？

はい。すべてのgRPC & High Performance APIsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← gRPC & High Performance APIsに戻る