Server Load Balancer:ALB ステータスコード

バックエンドサービスが 400 状態コードを直接返す: アクセスログを確認してください。upstream_status フィールドの値が 400 の場合、ALB がバックエンドサービスから状態コードを転送した可能性が高いです。バックエンドサービスのトラブルシューティングを行う必要があります。

HTTPS リスナーに HTTP リクエストが送信される: ALB の HTTPS リスナーは、HTTPS 以外のリクエストを拒否し、400 ステータスコードを返します。クライアントが HTTPS ポートに HTTP リクエストを送信したかどうかを確認します。

リクエストヘッダーのサイズが制限を超えている: ALB の HTTP リクエストヘッダーの最大サイズは 32 KB です。リクエストヘッダーがこの制限を超えると、ALB は 400 エラーを返します。HTTP リクエストヘッダーのサイズを調整することをお勧めします。

リクエストが不完全である: HTTP リクエストが完全に送信される前に、クライアントが接続を閉じました。クライアントでパケットをキャプチャして原因を分析できます。

リクエストヘッダーのフォーマットが無効である: たとえば、Content-Length の値が実際のリクエストボディの長さと一致しません。クライアントでパケットをキャプチャして HTTP リクエストのフォーマットを分析し、通常のリクエストと比較することをお勧めします。

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

バックエンドサービスの制限: TRACE 以外のリクエストメソッドを処理する機能は、バックエンドサーバーがそれらをサポートしているかどうかによって異なります。curl -X METHOD http://<backend_server_IP>:<service_port> コマンドを実行して確認できます。ここで、METHOD はクライアントが使用するリクエストメソッドです。

クライアントからのデータ転送が遅い: クライアントは、リスナーの接続リクエストタイムアウト期間 (デフォルトは 60 秒) 内に、HTTP Header のみで HTTP Body がないなど、一部のデータしか送信しません。パケットをキャプチャして、クライアントのパフォーマンスボトルネックやその他の問題をトラブルシューティングすることをお勧めします。サービスでより長いリクエスト転送時間が必要な場合は、接続リクエストのタイムアウトを長くすることができます。

クライアントと ALB 間のネットワーク品質が悪い: TCP ラウンドトリップタイム (RTT) が高いか、パケット損失などのネットワーク問題が発生しています。アクセスログの request_time および tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行できます。

ALB インスタンスの帯域幅スロットリング: ALB インスタンスへの過剰なトラフィックが帯域幅スロットリングとパケット損失をトリガーします。Cloud Monitor を使用して、outbound bandwidth および Dropped Connections メトリックを確認できます。

ALB 固有の制限: ALB では、リクエスト URI の長さが 32 KB を超えないようにする必要があります。この制限を超えると、ALB は 414 ステータスコードを返します。URI を短くすることをお勧めします。大量のデータを転送するには、POST メソッドを使用し、リクエストボディでデータを転送できます。ALB は最大 50 GB の POST リクエストボディをサポートします。

バックエンドサービスの制限: URI が ALB の制限を超えていないが、バックエンドサービスにさらに厳しい長さの制限がある場合、ALB はバックエンドから返された 414 ステータスコードを転送します。バックエンドサービスのトラブルシューティングを行う必要があります。

バックエンドサービスの構成が正しくない: バックエンドサービスの構成が正しくないため、リクエストが ALB に送り返されてループを形成します。ALB のバックエンドサービス構成を確認してください。

ネットワークアーキテクチャ設計の欠陥: たとえば、単一のリクエストの転送パスに複数の Server Load Balancer (SLB) インスタンスが含まれています。ネットワークアーキテクチャを最適化する必要があります。

クライアントから ALB へのネットワーク品質が悪い: TCP ラウンドトリップタイム (RTT) が高いか、パケット損失などのネットワーク問題が存在します。アクセスログの request_time および tcpinfo_rtt フィールドを確認するか、クライアントでネットワーク診断を実行できます。

ALB インスタンスの帯域幅スロットリング: ALB インスタンスへの過剰なトラフィックが帯域幅スロットリングとパケット損失をトリガーします。Cloud Monitor を使用して、outbound bandwidth および Dropped Connections メトリックを確認できます。

バックエンドリクエストの処理時間が長い: バックエンドリクエストの処理時間がクライアントのリクエストタイムアウトを超えています。アクセスログの upstream_response_time フィールドを確認します。このフィールドの値は、バックエンドリクエストの処理時間です。この値が一貫して高い場合は、バックエンドサービスにパフォーマンスボトルネックがないか確認してください。

クライアント側のリクエストタイムアウトが短すぎる: リクエスト全体が送信される前にタイムアウトしたため、クライアントが接続を閉じます。アクセスログの request_time フィールドを確認できます。このフィールドは、クライアントの合計リクエスト時間を表します。このフィールドの値を使用して、より適切なクライアントリクエストタイムアウトを設定できます。

不明なクライアントの問題: リクエストが完了する前にクライアントが接続を閉じます。クライアントに接続を途中で閉じる動作がないか確認してください。

バックエンドサービスが直接 500 エラーを返す: アクセスログを確認します。upstream_status フィールドの値が 500 の場合、ALB はバックエンドサービスからステータスコードを転送した可能性が高いです。バックエンドサービスのトラブルシューティングを行う必要があります。

バックエンドサーバーが予期せず接続を閉じる: バックエンドサーバーは、完全な応答を送信する前に予期せず接続を閉じます。バックエンドサーバーでパケットをキャプチャして、予期しない接続切断の原因を調査できます。

バックエンドサービスが直接 502 エラーを返す: アクセスログを確認します。upstream_status フィールドの値が 502 の場合、ALB はバックエンドサービスからステータスコードを転送した可能性が高いです。バックエンドサービスのトラブルシューティングを行う必要があります。

バックエンドサーバーが他のエラーステータスコードを返す: たとえば、バックエンドサーバーは 504 または 444 エラーを返す場合がありますが、ALB は 502 エラーを返します。アクセスログの status および upstream_status フィールドを確認し、バックエンドステータスコードに基づいてエラーのトラブルシューティングを行うことをお勧めします。

ALB とバックエンドサーバー間の異常な TCP 通信: バックエンドサービスが正常な状態であるか、サービスポートが正しくリッスンしているかを確認します。パケットをキャプチャして TCP ハンドシェイクが正常であるかを確認することもできます。

バックエンドサーバーのバックログがいっぱいである: これにより、新しい接続リクエストが拒否またはドロップされます。バックエンドサーバーで netstat -s | grep -i listen コマンドを実行して、drop カウントがあるかどうかを確認できます。

クライアントから送信されたメッセージの長さがバックエンドサーバーの MTU を超えている: ヘルスチェックや短いメッセージのパケットは正常に処理されますが、長いメッセージのパケットは処理されません。バックエンドサーバーでパケットをキャプチャして、メッセージの長さが要件を満たしているかどうかを分析できます。

バックエンドサーバーの応答のフォーマットが無効であるか、HTTP ヘッダーが不正である: バックエンドサーバーでパケットをキャプチャして、応答メッセージのフォーマットが標準であるかどうかを分析できます。

バックエンドサーバーがリクエストを時間内に処理しなかった: バックエンドサーバーのログを確認し、その CPU とメモリ使用量を表示します。

バックエンドサービスが直接 503 エラーを返す: アクセスログを確認します。upstream_status フィールドの値が 503 の場合、ALB はバックエンドサービスからステータスコードを転送した可能性が高いです。バックエンドサービスのトラブルシューティングを行う必要があります。

クライアントリクエストが ALB スロットリングをトリガーする:

• Cloud Monitor で Requests per second メトリックを表示します。

• Cloud Monitor は分単位のデータを表示するため、1 秒あたりの制限を超えたタイミングが反映されない場合があります。アクセスログを確認できます。upstream_status フィールドの値が - の場合、リクエストはバックエンドサーバーに配信されませんでした。

• 応答パケットヘッダーに ALB-QPS-Limited:Limited フィールドが含まれている場合、リクエストは ALB のレート制限をトリガーしました。

ALB インスタンスへの直接 IP アクセスまたは異常な DNS 解像度: これにより、トラフィックが少数の IP アドレスに集中し、制限を超える可能性があります。ALB インスタンスにはドメイン名を使用してアクセスし、DNS 解像度が正常であることを確認することをお勧めします。詳細については、「ALB の CNAME レコードを構成する」をご参照ください。

リスナーにバックエンドサーバーが構成されていないか、構成されているバックエンドサーバーの重みが 0 である。

バックエンドサービスが直接 504 エラーを返す: アクセスログを確認します。upstream_status フィールドの値が 504 の場合、ALB はバックエンドサービスからステータスコードを転送した可能性が高いです。バックエンドサービスのトラブルシューティングを行う必要があります。

バックエンドサーバーへの接続がタイムアウトする: タイムアウト期間はデフォルトで 5 秒であり、変更できません。パケットをキャプチャして応答タイムアウトの原因を特定することをお勧めします。

バックエンドサーバーの応答がタイムアウトする: 応答タイムアウト期間はデフォルトで 60 秒です。Cloud Monitor の UpstreamResponseTime メトリックとアクセスログの upstream_response_time フィールドを確認して、バックエンドサーバーがタイムアウトしたかどうかを判断できます。