ヘルスチェックの実装

ヘルスチェックは、特定のサーバー上のサービスに、作業を正常に実行できるかどうかを確認する方法です。ロードバランサーは、各サーバーにこの質問を定期的に行い、トラフィックを転送しても安全なサーバーを判断します。キューからメッセージをポーリングするサービスは、キューからさらに作業をポーリングすることを決定する前に、自身が正常であるかどうかを自問する場合があります。モニタリングエージェント (各サーバーまたは外部モニタリングフリートで実行) は、サーバーが正常であるかどうかを確認して、アラームを発したり、障害が発生したサーバーに自動的に対処したりすることができます。

私のウェブサイトのバグの例で見たように、異常なサーバーがサービスを継続すると、サービス全体の可用性が不均衡に低下する可能性があります。10 台のサーバーのフリートでは、1 つの不良サーバーは、フリートの可用性が 90% 以下になることを意味します。さらに悪いことに、「最小リクエスト」などの一部の負荷分散アルゴリズムが、最速のサーバーにより多くの作業を与えます。サーバーに障害が発生すると、多くの場合、リクエストがすぐに失敗し始め、正常なサーバーよりも多くのリクエストを引き付けることで、サービスフリートに「ブラックホール」が作成されます。場合によっては、追加の保護を加えて、失敗したリクエストの速度を落としてブラックホールを防ぎ、成功したリクエストの平均レイテンシーに一致させます。ただし、キューポーラーなど、この問題を回避するのがより難しい他のシナリオがあります。たとえば、キューポーラーがメッセージを受信できる速度でポーリングしている場合、障害が発生したサーバーもブラックホールになります。作業を分散するためのこのような多様な環境のセットでは、部分的に障害が発生したサーバーの保護について考える方法は、システムによって異なります。

書き込み不能になり、リクエストがすぐに失敗するディスク、突然スキューし、依存関係の呼び出しが認証に失敗するクロック、更新された暗号素材を取得できず、復号化と暗号化の失敗を引き起こすサーバー、それにバグ、メモリリーク、および処理をフリーズするデッドロックのためにクラッシュする重要なサポートプロセスなど、さまざまな理由でサーバーに独立して障害が発生することがわかっています。

フリート内の多くのサーバーまたはすべてのサーバーが同時に障害を引き起こす相関関係のある理由でも、サーバーに障害が発生します。相関する理由には、共有依存関係の停止と大規模なネットワークの問題が含まれます。理想的なヘルスチェックは、サーバーおよびアプリケーションのヘルスのあらゆる側面をテストし、おそらく重要ではないサポートプロセスが実行されていることをも検証するものでしょう。ただし、重大ではない理由でヘルスチェックが失敗し、その失敗がサーバー間で相関している場合、トラブルが発生します。サーバーがまだ有用な作業を実行できたときに、自動化によってサーバーがサービスから削除されると、自動化は害をもたらします。

ヘルスチェックの難しさは、一方では徹底的なヘルスチェックの利点と、単一サーバー障害の迅速な軽減の利点、他方ではフリート全体での誤検出による障害との間のこの緊張状態にあります。したがって、良好なヘルスチェックを構築するための課題の 1 つは、誤検出を慎重に防ぐことです。一般的に、これは、ヘルスチェックを取り巻く自動化がトラフィックを単一の不良サーバーに転送するのを停止し、フリート全体に問題があるように見える場合はトラフィックを許可し続けることを意味します。