【ITニュース解説】Liveness vs Readiness in Kubernetes: The Truth for Frontend Apps

KubernetesにおけるLivenessプローブとReadinessプローブは、アプリケーションの健全性を監視し、必要に応じて再起動やトラフィックのルーティングを制御するために重要な役割を果たす。特にシステムエンジニアを目指す初心者は、これらの概念を正しく理解することが不可欠だ。

従来、LivenessプローブとReadinessプローブは常に分離して設定すべきだと考えられてきた。Livenessプローブは、アプリケーションが停止または応答不能になった場合にKubernetesに再起動を指示する。一方、Readinessプローブは、アプリケーションがトラフィックを処理できる状態になったかどうかをロードバランサに通知する。しかし、これは常に正しいとは限らない。

特に、外部のデータベースやRedisなどの依存関係を持たないシンプルなフロントエンドアプリケーションの場合、LivenessプローブとReadinessプローブに同じエンドポイントを使用しても問題ない。通常、/healthや/pingのようなエンドポイントを用意し、サーバーが起動していればHTTPステータスコード200 OKを返すように設定するだけで十分だ。

なぜなら、このようなシンプルなアプリケーションでは、ウォームアップやコネクションプールの確立を待つ必要がなく、起動と同時にトラフィックを処理できるためだ。複雑なヘルスチェックのロジックは不要で、単にアプリケーションが「起動している」ことを確認できればよい。

ただし、LivenessプローブとReadinessプローブを分離すべきケースも存在する。例えば、アプリケーションがデータベースや他のサービスに接続する必要があり、それらの依存関係が利用可能になるまで時間を要する場合だ。また、アプリケーションが長時間稼働しているうちにフリーズしたり、応答が遅くなったりする可能性がある場合も分離を検討するべきだ。さらに、ReadinessプローブとLivenessプローブで異なる失敗許容値を設定したい場合もある。

このような場合、Readinessプローブはすべての依存関係が利用可能になった場合にのみ200 OKを返し、Livenessプローブはアプリケーションが完全に停止または応答不能になった場合にのみ失敗を通知するように設定する。Readinessプローブは「リクエストを受け付けられるか？」を、Livenessプローブは「まだ生きているか？」を判断するものと考えると理解しやすい。

具体的な設定例として、インフラ側の設定では、同じパスに対して異なるプローブを設定できる。例えば、/health/readinessをReadinessプローブ、/health/livenessをLivenessプローブとして設定し、それぞれ異なるinitialDelaySeconds（初期遅延秒数）とperiodSeconds（ポーリング間隔）を設定することで、監視の頻度を調整できる。

アプリケーション側の実装例としては、FastifyやExpressなどのフレームワークを使用して、/health/livenessと/health/readinessのエンドポイントを作成し、単純にステータスコード200と{ status: 'READY' }のようなJSONレスポンスを返すようにする。複雑なロジックやリトライ処理、依存関係のチェックなどは不要だ。

重要なことは、ヘルスチェックを過剰に複雑化しないことだ。外部の依存関係を持たないフロントエンドアプリケーションであれば、単一の/healthエンドポイントで十分な場合が多い。しかし、アプリケーションが成長し、データベースやキャッシュ、非同期キューなどのインフラストラクチャの複雑性が増すにつれて、LivenessプローブとReadinessプローブを分離することを検討する必要がある。いつ分離が必要かを理解することが、より重要だ。