Server Load Balancer:ALB の一般的なステータスコードと発生する可能性のある原因

考えられる原因:

• バックエンドサーバーが HTTP 400 ステータスコードを返し、ALB がバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 400 ステータスコードを返す理由を確認してください。

• HTTP ヘッダーの形式が無効です。たとえば、コンテンツの長さがリクエスト本文の長さと一致しません。クライアントで HTTP リクエストの形式を分析し、有効なリクエストと比較することをお勧めします。

• ALB インスタンスに HTTPS リスナーが追加されています。クライアントが HTTPS リクエストを送信していないのに HTTP 400 ステータスコードが返された場合は、クライアントが HTTPS ポートに HTTP リクエストを送信したかどうかを確認することをお勧めします。

• HTTP リクエストが送信される前に、クライアントが接続を閉じます。パケットをキャプチャし、切断の原因を特定することをお勧めします。

• ALB では、各 HTTP ヘッダーの長さが 32 KB を超えないようにする必要があります。この制限を超えると、HTTP 400 ステータスコードが返されます。HTTP ヘッダーの長さを調整することをお勧めします。

考えられる原因:

• バックエンドサーバーは、クライアントで使用されているリクエストメソッドをサポートしていません。クライアントで使用されているメソッドがバックエンドサーバーで使用されているメソッドと一致するかどうかを確認することをお勧めします。たとえば、バックエンドサーバーで特定のメソッドがサポートされているかどうかを確認するには、curl -X method ip:port コマンドを実行します。method はクライアントで使用されるリクエストメソッドを指定し、ip はバックエンドサーバーの IP アドレスを指定し、port はバックエンドサーバーのポートを指定します。

• ALB は、TRACE リクエストメソッドをサポートしていません。別のメソッドを使用することをお勧めします。

考えられる原因:

• リクエストのタイムアウト期間中に、リクエストの一部のみが送信され、ALB が接続を閉じます。たとえば、HTTP ヘッダーのみが送信され、本文は送信されません。パケットをキャプチャして、クライアントにパフォーマンスボトルネックやその他の異常な動作があるかどうかを確認することをお勧めします。ALB リスナーのリクエストタイムアウト期間を増やして、問題が解決するかどうかを確認することもできます。詳細については、「リスナーの変更」をご参照ください。

• クライアントと ALB インスタンス間の接続にエラーがあります。TCP パケットの往復レイテンシ (RTT) が過度に大きい、またはパケットが失われています。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、パケットをキャプチャして、クライアントネットワークにエラーが含まれているかどうかを確認することをお勧めします。

• ALB インスタンスへのネットワークトラフィック量が過度に大きく、帯域幅の調整とパケット損失が発生しています。CloudMonitor を使用して、ALB インスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することをお勧めします。詳細については、「ALB モニタリングメトリック」および「ALB インスタンスに関するモニタリング情報の表示」をご参照ください。

考えられる原因:

• バックエンドサーバーが HTTP 414 ステータスコードを返し、ALB がバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 414 ステータスコードを返す理由を確認してください。

• ALB へのリクエストの URI の長さは、32 KB を超えることはできません。リクエストの URI が 32 KB を超えると、HTTP 414 ステータスコードが返されます。URI を短縮することをお勧めします。送信するデータ量が大きい場合は、POST メソッドを使用してデータを送信することをお勧めします。ALB への POST リクエストの本文のサイズは最大 50 GB です。

考えられる原因:

• クライアントと ALB インスタンス間の接続にエラーがあります。RTT が大きい、またはパケットが失われています。アクセスログの request_time フィールドと tcpinfo_rtt フィールドを確認するか、パケットをキャプチャして、クライアントネットワークにエラーが含まれているかどうかを確認することをお勧めします。

• ALB インスタンスへのネットワークトラフィック量が過度に大きく、帯域幅の調整とパケット損失が発生しています。CloudMonitor を使用して、ALB インスタンスのアウトバウンド帯域幅とドロップされた接続数を確認することをお勧めします。詳細については、「ALB モニタリングメトリック」および「ALB インスタンスに関するモニタリング情報の表示」をご参照ください。

• バックエンドサーバーのリクエスト処理時間が長すぎて、クライアントのリクエストタイムアウト期間を超えています。アクセスログの upstream_response_time フィールドは、バックエンドサーバーがリクエストを処理するために必要な時間を示します。バックエンドサーバーの CPU、メモリ、およびネットワークにパフォーマンスボトルネックがないか確認することをお勧めします。

• クライアントに設定されているリクエストタイムアウト期間が短すぎます。その結果、HTTP リクエストが送信される前に、クライアントが接続を閉じます。アクセスログの request_time フィールドを確認することをお勧めします。このフィールドは、クライアントがリクエストを送信するために必要な時間を示します。このフィールドの値を参照して、クライアントに適切なリクエストタイムアウト期間を設定します。

• クライアントで不明な問題が発生し、HTTP リクエストが送信される前に接続が閉じます。HTTP リクエストが送信される前に、クライアントが接続を閉じているかどうかを確認することをお勧めします。

考えられる原因:

• バックエンドサーバーが HTTP 500 ステータスコードを返し、ALB がバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 500 ステータスコードを返す理由を確認してください。

• 応答を送信する前に、バックエンドサーバーが接続を閉じます。バックエンドサーバーでパケットをキャプチャして原因を特定し、トラブルシューティングすることをお勧めします。

考えられる原因:

• バックエンドサーバーが HTTP 502 ステータスコードを返し、ALB がバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 502 ステータスコードを返す理由を確認してください。

• ALB バックエンドサーバーが別の HTTP ステータスコード (504 や 444 など) を返しますが、ALB は HTTP 502 ステータスコードを返します。アクセスログの upstream_status フィールドと status フィールドを確認するか、パケットをキャプチャして、バックエンドサーバーにエラーがあるかどうかを確認することをお勧めします。

• TCP を介した ALB とバックエンドサーバー間の通信にエラーが含まれています。バックエンドサーバーが正常かどうか、サービスポートがリスナーによってリッスンされているかどうか、または TCP ハンドシェイクが成功するかどうかを確認してください。

• バックエンドサーバーのバックログがいっぱいで、パケットがドロップされています。netstat を使用して、バックエンドサーバーのネットワーク統計にドロップされたパケットの数が表示されているかどうかを確認することをお勧めします。たとえば、netstat -s | grep -i listen コマンドを実行できます。

• クライアントから送信されたパケットの長さが、バックエンドサーバーの最大転送単位 (MTU) を超えています。この場合、ヘルスチェックは成功するか、短いパケットは予期どおりに送信されます。ただし、長いパケットは予期どおりに送信されません。バックエンドサーバーでパケットをキャプチャして、パケットの長さが要件を満たしているかどうかを分析することをお勧めします。

• バックエンドサーバーから返されたパケットの形式が無効であるか、無効な HTTP ヘッダーが含まれています。バックエンドサーバーでパケットをキャプチャして、HTTP 応答の形式が無効かどうかを確認することをお勧めします。

• ALB のバックエンドサーバーがリクエストの処理を完了していません。バックエンドサーバーのログデータを確認してください。さらに、CPU とメモリの使用量を確認してください。

考えられる原因:

• バックエンドサーバーが HTTP 503 ステータスコードを返し、ALB がバックエンドステータスコードをクライアントに渡します。バックエンドサーバーが HTTP 503 ステータスコードを返す理由を確認してください。

• クライアントからのネットワークトラフィックが ALB の調整をトリガーします。次のいずれかの方法を使用して、問題をトラブルシューティングできます。

  • CloudMonitor コンソールで 1 秒あたりのリクエスト数を確認します。詳細については、「ALB モニタリングメトリック」および「ALB インスタンスに関するモニタリング情報の表示」をご参照ください。

  • CloudMonitor は、分単位でモニタリングデータを表示します。アクセスログを使用して、1 秒あたりのリクエスト数を確認できます。アクセスログの upstream_status フィールドを表示します。コンテンツが「-」の場合、リクエストはバックエンドサーバーに送信されません。

  • 応答ヘッダーに ALB-QPS-Limited:Limited フィールドが含まれているかどうかを確認します。含まれている場合、リクエストが ALB の調整をトリガーしたことを示します。

• クライアントが ALB にアクセスするときに、ドメイン名を使用する代わりに ALB インスタンスの IP アドレスにアクセスするか、クライアントがドメイン名を使用して ALB にアクセスするときに DNS 解決結果を更新しません。その結果、複数の ALB IP アドレス間でリクエストを分散できず、HTTP 503 エラーコードが返されます。クライアントは、IP アドレスではなく ALB のドメイン名にアクセスすることをお勧めします。さらに、クライアントが DNS によって返された異なる IP アドレスを使用して ALB にアクセスしていることを確認してください。

• ALB リスナーに関連付けられているバックエンドサーバーがないか、バックエンドサーバーの重みが 0 に設定されています。

考えられる原因:

• バックエンドサーバーによって 504 ステータスコードが返された場合は、バックエンドサーバーが過負荷になっているかどうかを確認してください。

• ALB からバックエンドサーバーへの接続がタイムアウトしました。タイムアウト期間はデフォルトで 5 秒に設定されています。アクセスログの upstream_connect_time フィールドが 5 秒または約 5 秒に設定されているかどうかを確認できます。パケットをキャプチャして、応答タイムアウトの原因を特定することをお勧めします。

• バックエンドサーバーのワークロードが重く、応答を返すために必要な時間が指定されたタイムアウト期間よりも長くなっています。たとえば、リクエストタイムアウト期間が 60 秒に設定されているとします。応答時間が 60.001 秒の場合、ALB は HTTP 504 ステータスコードを返します。CloudMonitor コンソールまたはアクセスログで、問題が発生している期間のネットワークレイテンシを確認できます。ネットワークレイテンシを表示するには、CloudMonitor の upstream_rt フィールド、またはアクセスログの upstream_response_time フィールドを確認します。