Readiness Probe とは？解説

readiness probeは、インスタンスがトラフィックを受け取る準備ができているかを確認し、起動が完了した後にのみリクエストがそこへ送られるようにします。

起動していることと、準備ができていることは同じではありません。サービスは、config読み込み、cacheのウォームアップ、接続の確立の最中でも実行中であり得ます。readiness probeはその違いを捉え、プラットフォームやあなたのCIのjobが、単なる「起動済み」ではなく「準備完了」を待つようにします。これは競合の頻繁な原因です。

「準備完了」の意味

readiness probeは、狭い問いに答えます。このインスタンスは今すぐリクエストを処理できるか？合格するまで、インスタンスは存在しますがトラフィックを受け取るべきではありません。合格すると、poolに組み込まれます。これが、rolling deployがまだウォームアップされていないインスタンスへリクエストを送らないようにする仕組みです。

readiness と liveness

liveness probeは、プロセスが生きているか、ハングしているかを問います（失敗すると再起動がトリガーされます）。readiness probeは、処理できるかを問います（失敗するとローテーションから外されますが、再起動はされません）。これらを取り違えると、不要な再起動か、準備ができていないインスタンスへのトラフィックのどちらかを引き起こします。

CIが気にする理由

典型的な不安定な失敗は、データベースやサービスの準備ができる前に実行されるテストです。containerが「起動済み」と報告し、テストが発火し、依存先がまだ実際には処理していなかったために失敗します。単に起動済みではなくreadiness条件を待つことで、その競合を完全に取り除けます。

うまく実装する

ポートが開いているだけでなく、実際の処理経路（query、ping用エンドポイント）を確認します。
CIでは、テストを実行する前に依存するstepをreadiness条件でゲートします。
遅いが正常な起動が失敗として扱われないよう、十分な起動時間を許容します。

Latchkey の視点

readiness probeは競合を減らすjob設計のツールであり、自己修復が残りを処理します。一時的な起動の不調がそれでもjobをつまずかせたとき、Latchkeyの自己修復マネージドrunnerが自動でretryするため、単発の瞬間的な不調があなたのbuildを失敗させることはありません。

重要なポイント

readiness probeは、インスタンスがまだトラフィックを処理できるかを確認します。
起動済みは準備完了ではありません。このギャップは競合の一般的な原因です。
readinessはローテーションから外し、livenessは再起動します。混同しないでください。
CIのstepをreadinessでゲートすることで、競合状態によるflakinessを防げます。