Server Load Balancer:ALB のヘルスチェック失敗のトラブルシューティング

問題の説明

ALB インスタンスのリスナーの ヘルスチェックステータス 列に 異常 と表示されます。

原因

解決策

初期設定時のヘルスチェック失敗

原因 1：ヘルスチェックパラメーターの不正な設定

1. ALB コンソールにログインします。

2. 上部のナビゲーションバーで、ALB インスタンスがデプロイされているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、ALB > サーバーグループを選択します。

4. サーバーグループ ページで、対象の ALB インスタンスにアタッチされているサーバーグループを見つけ、サーバーグループ ID をクリックします。

5. サーバーグループの詳細ページで、ヘルスチェック セクションの ヘルスチェックの変更 をクリックします。

6. ヘルスチェックの変更 ダイアログボックスで、ヘルスチェックパラメーターが正しく設定されているかを確認します。デフォルトのヘルスチェックパラメーターを使用することを推奨します。

   詳細については、「ALB のヘルスチェック」をご参照ください。

原因 2：リスナーポートの問題

1. ALB コンソールにログインします。

2. 上部のナビゲーションバーで、ALB インスタンスがデプロイされているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、ALB > サーバーグループ を選択します。

4. サーバーグループ ページで、対象の ALB インスタンスにアタッチされているサーバーグループを見つけ、サーバーグループ ID をクリックします。

5. サーバーグループの詳細ページで、バックエンドサーバー タブをクリックし、バックエンドサーバーのポートを確認して記録します。

6. サーバーグループの詳細ページで、詳細 タブをクリックします。ヘルスチェック セクションで ヘルスチェックの変更 をクリックします。ヘルスチェックの変更 ダイアログボックスで、ヘルスチェックパラメーターを確認して記録します。

7. バックエンドサーバーにログインし、`nc` または `curl` コマンドを使用してバックエンドサーバーをプローブします。

   ECS インスタンスへのログイン方法の詳細については、「ECS インスタンスへの接続」をご参照ください。

   # nc コマンド:
   echo -e "[$Method] [$PATH] [$VERSION]\r\nHost: [$Domain]\r\n\r\n" | nc -t [$IP] [$Port] # フォーマット
   echo -e "HEAD /index.html HTTP/1.0\r\nHost: wwww.example.org\r\n\r\n" | nc -t 127.0.0.1 80 # 例
   
   # curl コマンド:
   curl -X [$Method] -H "Host: [$Domain]" -I http://[$IP]:[$Port][$PATH]  # フォーマット
   curl -X HEAD --http1.0 -H "Host: www.example.org" -I http://127.0.0.1:80/index.html # 例

   説明

   • [$Method] は、サーバーグループに設定されたヘルスチェックメソッドです。

   • [$PATH] は、サーバーグループに設定されたヘルスチェックパスです。

   • [$VERSION] は、ヘルスチェックで使用される HTTP プロトコルのバージョンです (例：`HTTP/1.0`)。

   • [$Domain] は、サーバーグループに設定されたヘルスチェックドメイン名です。値が `-----` の場合、ALB はデフォルトで各バックエンド ECS インスタンスのプライベート IP アドレスをドメイン名として使用します。この場合、代わりに `[$IP]` を使用できます。

   • [$IP] は、バックエンド ECS インスタンスのプライベート IP アドレスです。

   • [$Port] は、ヘルスチェックプローブに使用されるポートです。デフォルトでは、ALB はバックエンド ECS インスタンスのポートを使用します。ヘルスチェックポートを指定した場合、ALB はそのポートを使用します。

8. コマンドによって返されたステータスコードを確認し、それがアプリケーションにとって期待されるものかどうかを判断します。

   • 返されたステータスコードが期待どおりであるものの、ヘルスチェック設定に含まれていない場合は、ヘルスチェックを更新してそのステータスコードを正常な応答として含めます。

   • 返されたステータスコードが予期しないものである場合、次の表に考えられる HTTP ステータスコードとそのトラブルシューティング方法を示します。

     ステータスコード	説明	トラブルシューティング
     400	クライアントの HTTP リクエストのフォーマットが無効です。	HTTP ヘッダーのフォーマットが無効です。例えば、`content-length` が空であるか、HTTPS ポートに HTTP リクエストが送信されています。HTTP リクエストのフォーマットを確認してください。
     404	リクエストされたリソースが見つかりません。	リクエストされた URL が正しいか確認してください。
     405	ヘルスチェックのリクエストメソッドがサポートされていません。	バックエンドサービスがヘルスチェックのリクエストメソッドをサポートしているか確認してください。
     500	サーバーで内部エラーが発生し、リクエストを処理できません。	バックエンドサービスのビジネスロジックを確認してください。
     503	サーバーが一時的に利用できません。	バックエンドサービスのビジネスロジックを確認するか、サーバーが過負荷になっていないか確認してください。

設定成功後のヘルスチェック失敗

原因 1：セキュリティソフトウェアの問題

ALB は、内部の予約済みアドレス範囲の IP アドレスを使用して、バックエンドの ECS インスタンスと通信します。したがって、ALB のこのアドレス範囲がブロックされると、ヘルスチェックが失敗し、ALB は正常に機能しなくなります。このトピックでは、iptables を使用して 100.64.0.0/10 CIDR ブロックを確認する方法の例を示します。

1. 影響を受けるバックエンドの ECS インスタンスにログインし、次のコマンドを実行してフィルターテーブル内のすべてのルールを表示します。

   iptables -nL

   出力が次のようになっている場合、バックエンドの ECS インスタンスは ALB のプライベート CIDR ブロックからのリクエストをブロックしています。

2. 次のコマンドを実行してルールを削除します。

   iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP

3. 次のコマンドを実行して、ALB のプライベート CIDR ブロックからのリクエストがブロックされなくなったことを確認します。

   iptables -nL

原因 2：不正なルート設定

アップグレードされていない ALB インスタンスが使用する 100.64.0.0/10 CIDR ブロックのルートがバックエンドの ECS インスタンスで誤って設定されている場合、ALB インスタンスはヘルスチェックのプローブパケットを受信できず、ヘルスチェックが失敗します。次の例では、`route` コマンドを使用して Linux インスタンスのルート設定を確認する方法を示します。

1. 影響を受けるバックエンドの ECS インスタンスにログインし、次のコマンドを実行して現在のルート設定を確認します。

   route -n

   `宛先` が `100.64.0.0`、`Genmask` が `255.192.0.0` で、`ゲートウェイ` が対応する Elastic Network Interface のデフォルトゲートウェイでないルートエントリが見つかった場合、ルートは不正に設定されています。デフォルトゲートウェイは、`宛先` が `0.0.0.0` のときの `ゲートウェイ` の値です。

2. 次のコマンドを実行して、不正に設定された `100.64.0.0/10` のルートを削除します。

   route del -net 100.64.0.0/10

原因 3：バックエンドサーバーの過負荷

サーバーの高負荷を確認するには、「Linux インスタンスの高負荷問題のトラブルシューティングと解決」をご参照ください。