Application Load Balancer (ALB) はヘルスチェックを実行して、バックエンドサーバーが期待どおりに機能するかどうかをテストします。 ヘルスチェックを有効にした後、バックエンドサーバーがヘルスチェックに合格しなかった場合、ALBは自動的にリクエストを正常なバックエンドサーバーにルーティングします。 ヘルスチェックにより、障害が発生したバックエンドサーバーがサービス全体に影響を与えることを防ぎ、高いサービス可用性を確保します。 このトピックでは、ヘルスチェックの問題のトラブルシューティング方法について説明します。
発行
ALBインスタンスのリスナーの [ヘルスチェックステータス] 列に [異常] が表示されます。
原因
最初のヘルスチェックプローブの送信後にエラーが発生した場合、不適切なヘルスチェック設定が原因で問題が発生している可能性があります。 次の原因を確認する必要があります。
不適切なパラメータ設定
不適切なヘルスチェックポート
ヘルスチェックが適切に設定されている場合、バックエンドサーバーが原因でエラーが発生している可能性があります。 この場合、次の原因を確認してください。
不適切なセキュリティサービス構成
不適切なルート設定
バックエンドサーバーの負荷が大きい
解決策
最初のヘルスチェックプローブの送信後に発生するエラー
原因1: 不適切なパラメータ設定
ALBコンソールにログインします。
上部のナビゲーションバーで、ALB管理するインスタンスがデプロイされます。
左側のナビゲーションウィンドウで、 .
[サーバーグループ] ページで、ALBインスタンスに関連付けられているサーバーグループを見つけ、サーバーグループIDをクリックします。
サーバーグループの詳細ページで、[ヘルスチェック] セクションの [ヘルスチェックの変更] をクリックします。
[ヘルスチェックの変更] ダイアログボックスで、パラメーター設定を確認します。 デフォルト設定を使用することを推奨します。
詳細については、「ヘルスチェック管理」をご参照ください。
原因2: 不適切なヘルスチェックポート
ALBコンソールにログインします。
上部のナビゲーションバーで、ALB管理するインスタンスがデプロイされます。
左側のナビゲーションウィンドウで、 .
[サーバーグループ] ページで、ALBインスタンスに関連付けられているサーバーグループを見つけ、サーバーグループIDをクリックします。
サーバーグループの詳細ページで、[バックエンドサーバー] タブをクリックし、バックエンドサーバーポートを記録します。
サーバーグループの詳細ページで、[詳細] タブをクリックします。 次に、[ヘルスチェック] セクションの [ヘルスチェックの変更] をクリックします。 [ヘルスチェックの変更] ダイアログボックスで、ヘルスチェックの設定を記録します。
バックエンドサーバーにログインし、ncまたはcurlコマンドを実行してバックエンドサーバーをプローブします。
Elastic Compute Service (ECS) インスタンスにログインする方法の詳細については、「インスタンス接続のガイドライン」をご参照ください。
# The nc command: echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] #Format echo -e "HEAD /index.html HTTP/1.0\r\nHost: wwww.example.org\r\n\r\n" | nc -t 127.0.0.1 80 #Example # The curl command: curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH] #Format curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html # Example
説明サーバグループのヘルスチェック方式に [$Method] を設定します。
サーバグループのヘルスチェックパスに [$PATH] を設定します。
[$VERSION] をサーバーグループのHTTPプロトコルのバージョン (HTTP/1.0など) に設定します。
[$Domain] をサーバーグループのヘルスチェックドメイン名に設定します。 ドメイン名が ----- の場合、ECSインスタンスのプライベートIPアドレスがヘルスチェックドメイン名として使用されます。 この場合、[$Domain] を [$IP] に置き換えることができます。
[$IP] をECSインスタンスのプライベートIPアドレスに設定します。
サーバグループのヘルスチェックポートに [$Port] を設定します。 ポートが指定されていない場合、ECSインスタンスのポートがデフォルトで使用されます。 ポートを指定する場合は、指定したポートを入力します。
コマンドを実行した後、返されたHTTPステータスコードを表示し、返されたHTTPステータスコードが正常な状態を示しているかどうかを判断します。
返されたHTTPステータスコードが正常な状態を示しているが、ヘルスチェック設定に含まれていない場合は、ヘルスチェック設定を変更してHTTPステータスコードを含めます。
返されたHTTPステータスコードが異常な状態を示す場合、トラブルシューティングについては次の表をご参照ください。 次の表に、返されるHTTPステータスコードとトラブルシューティングの方法を示します。
ステータスコード
説明
トラブルシューティング
400
HTTPリクエストの形式が無効です。
HTTPヘッダーの形式が無効です。 たとえば、コンテンツの長さが空であるか、ヘッダーの一部のフィールドに小文字が含まれています。 HTTPリクエストの形式を確認してください。
404
要求されたリソースが見つかりません。
リクエストされた URL が正しいかどうかを確認します。
405
ヘルスチェックのリクエスト方法はサポートされていません。
バックエンドサービスがヘルスチェックリクエストメソッドをサポートしているかどうかを確認します。
500
サーバーに内部エラーがあるため、リクエストを処理できません。
バックエンドサービスのビジネスロジックを確認します。
503
サーバーは一時的に利用できません。
バックエンドサービスのビジネスロジック、またはバックエンドサーバーが過負荷になっているかどうかを確認します。
その後のヘルスチェックプローブ中に発生するエラー
原因1: 不適切なセキュリティサービス設定
ALBインスタンスは、プライベートCIDRブロック100.64.0.0/10または仮想プライベートクラウド (VPC) CIDRブロックを使用して、バックエンドECSインスタンスと通信します。 ALBインスタンスで使用されているCIDRブロックが、バックエンドECSインスタンスのIptablesなどのセキュリティサービスによってブロックされていないことを確認します。
ALBインスタンスは、CIDRブロックの予約済みIPアドレスを使用して、バックエンドECSインスタンスと通信します。 ALBインスタンスで使用されているCIDRブロックがブロックされている場合、ヘルスチェックエラーが発生し、ALBインスタンスが期待どおりに機能しません。 次の例では、100.64.0.0/10がIptablesによってブロックされます。
ECSインスタンスにログインし、次のコマンドを実行して、フィルターテーブル内のすべてのルールを照会します。
iptables -nL
次の出力は、ECSインスタンスがALBインスタンスのプライベートCIDRブロックからのリクエストをブロックしていることを示しています。
次のコマンドを実行して、ルールを削除します。
iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP
次のコマンドを実行して、ECSインスタンスがALBインスタンスのプライベートCIDRブロックからのリクエストをブロックしないことを確認します。
iptables -nL
原因2: 不適切なルート設定
バックエンドECSインスタンスの対応するルートを確認します。 ルートは、ALBインスタンスのプライベートCIDRブロックである100.64.0.0/10を指します。 ルートが不適切に設定されている場合、ALBはバックエンドECSインスタンスから返されたヘルスチェックプローブパケットを受信できません。 これにより、ヘルスチェックエラーが発生します。 この例では、Linuxのrouteコマンドを使用してルート設定を確認します。
問題のあるバックエンドECSインスタンスにログインし、次のコマンドを実行してルート設定を確認します。
route -n
ルートのDestination値が100.64.0.0で、ルートのGenmask値が255.192.0.0で、Gateway値が対応するelastic network interface (ENI) のデフォルトゲートウェイに設定されていない場合、ルートは不適切に構成されています。 宛先値が0.0.0.0の場合、デフォルトゲートウェイはゲートウェイ値を参照します。
次のコマンドを実行して、100.64.0.0/10を指すルートを削除します。
route del -net 100.64.0.0/10
原因3: バックエンドECSインスタンスが過負荷
「Linuxインスタンスのシステム負荷の照会と分析」を参照し、ECSインスタンスが過負荷になっているかどうかを確認します。