ヘルスチェックが失敗した場合でも、アプリケーションロードバランサーが準備ができていないインスタンスにトラフィックを転送する原因は何ですか？
アプリケーションロードバランサーで構成された2から3のインスタンスにスケーリングできるAWS Elastic beanstalk環境があります。ロードバランサーには、200応答を探すように構成されたHTTPヘルスチェックがあります。
環境が3つのインスタンスに自動スケーリングすると、新しいインスタンスは準備が整う前にトラフィックの受信を開始します。ヘルスチェックURLを手動で確認すると、新しいインスタンスの準備ができていないため、3回に1回は404を返します。アプリの他のURLも、存在しないため3回に1回エラーが発生します。
私が理解しているように、ヘルスチェックURLの全体的なポイントはこれに対処することです。では、問題の原因は何ですか？
関連する可能性のあるいくつかの情報：
- インスタンスはARRのインストールが必要なASP.Netアプリであるため、準備が整うまでに長い時間がかかります。
- 拡張ヘルスチェックの概要では、正常に機能しているにもかかわらず、2つの機能しているインスタンスが「重大」と表示されます。 5xxエラーがいくつかリストされていますが、その理由はわかりません。トラフィックがほとんど送信されていないため、トラフィックの高い割合を占めています。奇妙なことに、準備ができていない新しいインスタンスは「OK」としてマークされます。ロードバランサーがインスタンスを正常であると見なす場合、強化されたヘルスチェックが指示するとは思わないが、おそらく私は正しくないのですか？
- AWSサポートに連絡しようとすると、エージェントから不変の環境アップデートとローリングアップデートに関する大量の情報が送信されました。私が理解しているように、これは、構成の変更または新しいデプロイメントが行われたときに新しいインスタンスがどのようにオンライン化されるかに関連しており、負荷分散ヘルスチェックおよび自動スケーリングとは異なるため、関係ありません。しかし、おそらく私は誤解しており、エージェントはこれがこの状況に関連している理由を伝えることができませんでした。
ヘルスチェックURLを手動でチェックすると、新しいインスタンスの準備ができていないため、3回に1回は404が返されることがわかります。
バランサーを介してノードの1つにアクセスしたときにヘルスチェックURLが正常なノードに対して機能するという事実は、バランサーがヘルスチェックを行うためにアクセスしたときに正常に機能するヘルスチェックURLと必ずしも同じではありません。
最新のHTTPバージョンでは、各受信リクエストにHostヘッダーが存在する必要があり、バランサーはヘルスチェックリクエストのHTTPホストヘッダーをインスタンスのプライベートIPアドレスに設定しますが、ブラウザーによって設定された値を通過します通常のリクエストの場合-ブラウザは、バランサーへのアクセスに使用しているホスト名に同じヘッダーを設定しています。
あなた（およびあなたのサーバー/フレームワーク/アプリケーション）がそれを考慮に入れておらず、サーバーがそれらを異なって扱う場合、あなたがそれらを試すときに手動チェックが機能しているにもかかわらず、すべてのインスタンスが実際に常にヘルスチェックに失敗している可能性があります。その「すべてのターゲットが正常ではない」状態が発生した場合、ALBは、すべてのインスタンスにトラフィックを転送することが最も安全であると想定します。これは、インスタンスがすべて正常である（フェイルセーフだが必ずしも直感的な設計ではない）かのように、発生していることを正確に説明します。
ターゲットグループに異常な登録済みターゲットのみが含まれている場合、ロードバランサーノードは異常なターゲット間でリクエストをルーティングします。
https://docs.aws.Amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html