ヘルスチェックとは？解説

ヘルスチェックは、サービスが機能しているかどうかをテストする定期的なプローブであり、システムが機能していないものを迂回したり再起動したりできるようにします。

分散システムは、自身のどの部分が動作しているかを知る必要があります。ヘルスチェックはそれに自動で答えます。サービスをプローブし、レスポンスを解釈し、プラットフォームが対応できるようにして、正常なインスタンスにのみトラフィックを送り、異常なものを回復させます。同じ考え方は、jobがservice containerに依存するCIでも重要です。

ヘルスチェックが行うこと

ヘルスチェックは、リクエスト、HTTP呼び出し、TCP接続、またはコマンドを送信し、その結果からサービスが正常かどうかを判断します。繰り返し合格すればサービスは稼働中とみなされ、失敗すればプラットフォームはそのインスタンスを信頼しなくなり、是正措置を取ります。

liveness と readiness

2つのタイプが一般的です。livenessチェックは「このプロセスは生きているか、それともスタックして再起動が必要か？」を問います。readinessチェックは「このインスタンスはまだトラフィックを受け取る準備ができているか？」を問います。両者は異なる問いに答えており、これらを混同すると、再起動ループや準備ができていないサービスへのトラフィック送信を引き起こします。

CIでなぜ重要か

jobは頻繁にservice container、データベース、cache、message brokerを立ち上げ、それらに対してテストを実行します。サービスが正常になる前にテストが始まると、競合状態による不安定な失敗が発生します。jobが待機するヘルスチェックは、まず依存先が準備できていることを保証することで、その競合を取り除きます。

良いチェックの設計

負荷やレイテンシを増やさないよう、チェックは軽量で高速にします。
ポートが開いているだけでなく、実際のreadiness（処理できるか）を確認します。
1回の瞬間的な不調でサービスがばたつかないよう、適切なthresholdを設定します。
依存するテストのstepを実行する前にreadinessを待ちます。

Latchkey の視点

ヘルスチェックはレジリエントなjobを書くための一部であり、自己修復インフラと相性が良いです。一時的な障害がそれでもすり抜けたとき、Latchkeyの自己修復マネージドrunnerが自動でretryするため、サービスの起動が一時的に遅かったといった単発の瞬間的な不調があなたのbuildを失敗させることはありません。

重要なポイント

ヘルスチェックは、サービスが動作しているかどうかをプローブします。
livenessはプロセスが生きているかを問い、readinessはトラフィックを処理できるかを問います。
readinessを待つことで、CIにおける競合状態によるflakinessを防げます。
良いチェックは軽量で、実質的で、適切なthresholdを備えています。