なぜコンテナのヘルスチェックはアイドル状態のホームサーバーに負荷をかけるのですか？

コンテナのヘルスチェックはスケジュールされた作業であるため、アイドル状態のホームサーバーに負荷をかけます。各プローブはコマンドや接続を開始し、サービスに応答を求めます。

1分ごとの軽量なチェックは無視できる程度です。多くのコンテナ、短い間隔、シェルベースのプローブ、データベースクエリ、DNSルックアップ、同期されたスケジュールが重なると、ユーザーがアクティブでなくても継続的なCPUの起動、ストレージの読み取り、ログ記録、ネットワークトラフィックが発生する可能性があります。

アイドル状態のアプリでも健康であることを証明するよう求められる

コンテナはプロセスが実行中でも、アプリケーションがデッドロックしていたりリクエストに応答できなかったりすることがあります。ヘルスチェックはテストを繰り返し実行することでその可視性のギャップを埋めます。実用的なDockerヘルスチェックガイドでは、プローブが単にプロセスの存在を確認するだけでなく、HTTP、データベース、システムの状態を検証する方法を示しています。

この有用なテストは無料ではありません。execプローブはコンテナ内でプロセスを作成します。HTTPプローブは接続を開き、アプリケーションフレームワークを通過します。より深いエンドポイントはデータベース接続を取得し、ストレージを読み取り、認証情報を検証したり、他のサービスを呼び出したりすることがあります。

プローブの種類が起動するリソースを決定する

TCPプローブはソケットが接続を受け入れるかを確認しますが、アプリケーションの正確性についてはほとんど示しません。HTTPはルーティングやアプリコードを実行できます。Execプローブはシェル、インタプリタ、クライアントバイナリを起動できます。ヘルスプローブの比較では、liveness、readiness、startupチェックが異なる運用上の質問に答える理由を説明しています。

小規模なサーバーでは、シェルとネットワークユーティリティの組み合わせがテスト対象のエンドポイントよりもコストがかかる場合があります。データベースクエリもデータベースや基盤となるストレージを完全に静かにさせません。正しいプローブは、障害発生後に取るアクションをサポートできる最も浅いものです。

短い間隔はコンテナスタック全体で乗算される

10秒間隔は1つのコンテナで1時間あたり360回のチェックを意味します。これを12のサービスに掛けると、各チェックの小さなコストが定期的なバックグラウンド負荷になります。ヘルスチェックがアイドルコンテナの負荷を増加させる事例では、過度に短い間隔を上げることでCPUの継続的な活動を減らせる理由が示されています。

タイムアウトやリトライは失敗したチェックをさらに増やします。依存関係が遅くなると、各プローブはタイムアウトまでアクティブなままで新しいチェックが到着します。システムは不健康であることを証明するためにより多くのリソースを消費し、依存関係の遅延やインシデントの長期化を招くことがあります。

同期されたチェックは周期的な負荷スパイクを生む

一緒に起動したコンテナは同じ間隔と位相を継承することが多く、プローブがほぼ同時に発火してDNS、リバースプロキシ、データベースに対して小さな「サンダリングハード（群れの暴走）」を引き起こします。平均負荷は低いままですが、短いスパイクがインタラクティブなリクエストを妨げたりHDDのスタンバイ移行を阻害したりします。

一般的なサンダリングハードパターンの説明では、集中したリクエストが時間を分散した同数のリクエストより悪影響を及ぼす理由を説明しています。ランダムな開始遅延、異なる間隔、中央監視により位相の整合を減らせます。

ヘルスチェックは回復アクションに合わせるべき

livenessの失敗はサービスを再起動する可能性があるため、1つの任意の依存関係が遅いだけでアプリを死んだと宣言しないようにチェックすべきです。readinessはトラフィックの到達を制御するためより厳格にできます。startupチェックはlivenessを永遠に緩めることなく初期化時間を与えます。

ヘルスチェックのタイミングガイドは間隔、タイムアウト、リトライ、開始期間を結果の状態に結びつけます。ホームサーバーの起動依存関係に関する記事は関連する境界を追加しています：起動順序だけではデータベース、ネットワーク、マウントが準備完了かどうかは証明できません。

FAQ

アイドル状態のホームサーバーでヘルスチェックは無効にすべきですか？

デフォルトでは無効にすべきではありません。ヘルスチェックは有用な障害検出を提供します。不要な深さや頻度を減らし、残ったプローブが電力、騒音、応答時間に実質的な影響を与えるか測定してください。

HTTP 200の応答だけでコンテナが健康であることを証明できますか？

それはそのエンドポイントがテストする内容のみを証明します。浅いエンドポイントは壊れたデータベースを見逃すかもしれませんし、深いエンドポイントは1つの任意の依存関係が遅いだけで健康なアプリを再起動するかもしれません。

コンテナがアイドル状態でもなぜHDDが起動するのですか？

ヘルスハンドラはアクセスログを書き込み、データベースをクエリし、設定を読み取り、HDDプールに保存されたメトリクスを更新することがあります。プローブのリクエストは小さいですが、その副作用がストレージに影響を与えます。