7.4. Eclipse Vert.x のヘルスチェックの例
以下の例は、実稼働環境での実行を目的としていません。
上達度レベルの例: Foundational
アプリケーションをデプロイする場合は、アプリケーションが利用可能かどうかを確認し、受信した要求の処理を開始することが重要です。ヘルスチェック パターンを実装すると、アプリケーションが利用できるかどうかや要求に対応できるかどうかなど、アプリケーションの健全性を監視できます。
先に進む前に、「ヘルスチェックの概念」セクションでヘルスチェックという用語の説明を参照してください。
このユースケースの目的は、プローブを使用してヘルスチェックパターンを実証することです。プロービングは、アプリケーションの Liveness および Readiness を報告するために使用されます。このユースケースでは、HTTP health エンドポイントを公開して HTTP 要求を発行するアプリケーションを設定します。コンテナーが動作している場合は、HTTP エンドポイント health の Liveness プローブによると、管理プラットフォームは 200 を戻りコードとして受け取り、それ以上のアクションは必要ありません。HTTP エンドポイント health が応答を返さない場合、たとえばスレッドがブロックされている場合は、Liveness プローブにより、アプリケーションが稼働しているとは見なされません。この場合、プラットフォームはそのアプリケーションに対応する Pod を強制終了し、アプリケーションを再起動するために新規 Pod を再作成します。
このユースケースでは、Readiness プローブを実証し、使用することもできます。アプリケーションが実行していても要求を処理できない場合 (再起動中にアプリケーションが HTTP 応答コード 503 を返す場合など)、このアプリケーションは Readiness プローブにより準備ができていないと見なされます。Readiness プローブによってアプリケーションが準備状態にあるとみなされないと、要求は Readiness プローブにより準備が整っているとみなされるまで、要求はそのアプリケーションにルーティングされません。
7.4.1. ヘルスチェックの概念 リンクのコピーリンクがクリップボードにコピーされました!
ヘルスチェックパターンを理解するには、まず以下の概念を理解する必要があります。
- Liveness
- Liveness は、アプリケーションが実行しているかどうかを定義します。実行中のアプリケーションが応答しない状態または停止状態に移行する可能性があるため、再起動する必要があります。Liveness の確認は、アプリケーションを再起動する必要があるかどうかを判断するのに役立ちます。
- Readines
- Readiness は、実行中のアプリケーションが要求を処理できるかどうかを定義します。実行中のアプリケーションがエラーまたは破損状態に切り替わり、要求にサービスを提供することができません。Readiness を確認すると、要求が引き続きそのアプリケーションにルーティングされるべきかどうかが判断されます。
- フェイルオーバー
- フェイルオーバーにより、サービス要求の失敗が適切に処理されるようになります。アプリケーションが要求のサービスに失敗した場合、その要求と今後の要求は フェイルオーバー または他のアプリケーションにルーティングできます (通常、同じアプリケーションの冗長コピーです)。
- 耐障害性および安定性
- 耐障害性および安定性により、要求処理の失敗を適切に処理できます。接続の損失によりアプリケーションが要求を処理できない場合、耐久性のあるシステムでは、接続が再確立された後にその要求を再試行できます。
- プローブ
- プローブは実行中のコンテナーで定期的に実行する Kubernetes の動作です。