Application Load Balancerの HTTP 502 エラーのトラブルシューティング方法を教えてください。

所要時間2分
0

Application Load Balancerで HTTP 502 エラーが発生します。

簡単な説明

HTTP 502には、バッドゲートウェイエラーなど、いくつかの原因が考えられます。原因はターゲットまたはApplication Load Balancerのどちらかである可能性があります。エラーの原因を特定するには、 Amazon CloudWatch メトリックスアクセスログを使用します。

Application Load Balancer のエラーをトラブルシューティングする前に、必ずアクセスログを有効にしてください。アクセスログの各フィールドの意味を理解するには、アクセスログエントリを参照してください。

ターゲットが AWS Lambda 関数の場合は、「解決策」セクションの「ターゲットが Lambda 関数の場合の HTTP 502 エラーのトラブルシューティング」を参照してください。

解決策

HTTP 502 エラーの原因を検索する

クラウドウォッチメトリクスの使用

データポイントが** HTTPCode\ _ELB\ _502\ _Count** メトリクスの下に表示される場合、ロードバランサーが HTTP 502 エラーの原因となります。それらが** HTTPCode\ _Target\ _5XX\ _Count** メトリクスの下に表示されている場合は、ターゲットが原因原因です。

アクセスログを使用する

elb\ _status\ _code が「502」で、target\ _status\ _code が「-」の場合、ロードバランサーが HTTP 502 エラーの原因となります。elb\ _status\ _code が「502」で、target\ _status\ _code が「502」の場合、ターゲットがエラーの原因となります。

HTTP 502 エラーのトラブルシューティング

注:アクセスログを elb\ _status\ _code =「502」 と「**target\ _status\ _code」でフィルタリングすると、**原因を特定しやすくなります。次に、ユースケースに関連する手順を完了します。

接続を確立しようとしたときに、ロードバランサーがターゲットから TCP RST を受信しました

接続の確立時にターゲットから TCP RST を受信した場合、ロードバランサーはターゲットとの TCP 3 ウェイハンドシェイクを確立できません。その結果、ロードバランサーはユーザーリクエストをターゲットに転送できません。

  • TargetConnectionErrorCount メトリクスのデータポイントがあるかどうかを確認します。このメトリックは、ロードバランサーとターゲットの間で正常に確立されなかった接続数を表します。
  • アクセスログのrequest_processing_timetarget_processing_time、およびresponse_processing_timee の各フィールドの値が**\ -1** に設定されているかどうかを確認します。この値は、正常に接続する必要があるため、ロードバランサーがリクエストをターゲットに急送できないことを意味します。

アクセスログエントリの例を以下に示します:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1"
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

注:このアクセスログエントリでは、request_processing_timetarget_processing_timeresponse_processing_timeがそれぞれ\ -1 に設定されています。

接続を確立しようとしたときに、ロードバランサーがターゲットから「ICMP 宛先到達不能 (ホスト到達不能)」などの予期しない応答を受け取りました

  • アクセスログの request_processing_timetarget_processing_timeresponse_processing_time の各フィールドの値が**\ -1** に設定されているかどうかを確認します。
  • ロードバランサーのサブネットからターゲットポートのターゲットへのトラフィックが許可されているかどうかを確認します。

ロードバランサーがターゲットへの未処理のリクエストを持っている間に、ターゲットは TCP RST または TCP FIN との接続を閉じました。

ロードバランサーはリクエストを受け取り、それをターゲットに転送します。ターゲットはリクエストを受け取って処理を開始しますが、ロードバランサーへの接続を早期に終了します。これは通常、ターゲットのキープアライブタイムアウトの期間がロードバランサーのアイドルタイムアウト値よりも短い場合に発生します。キープアライブタイムアウトの期間がアイドルタイムアウト値より長いことを確認してください。

request_processing_timetarget_processing_timeresponse_processing_time の各フィールドの値を確認してください。

次のアクセスログエントリの例を参照してください:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

注:このアクセスログエントリでは、request_processing_time 0.001target_processing_timeは** 4.205**、response_processing_timeは**\ -1** です。

ターゲットの応答の形式が正しくないか、無効な HTTP ヘッダーが含まれています

問題の発生時間帯にターゲット上でパケットキャプチャを実行して、ターゲットの応答を把握します。

ロードバランサーがターゲットに接続しているときに SSL ハンドシェイクエラーまたは SSL ハンドシェイクタイムアウト (10 秒) が発生しました

ロードバランサーからターゲットの HTTPS リスナーへの TCP 接続は成功しますが、その後の SSL ハンドシェイクはタイムアウトします。その結果、ロードバランサーはリクエストをターゲットに転送できません。

ターゲットグループが HTTPS プロトコルを使用しているかどうかを確認します。HTTPS プロトコルを使用していない場合、SSL ハンドシェイクタイムアウトは問題の原因ではありません。ターゲットグループが HTTPS プロトコルを使用している場合は、次の点を確認してください:

  • アクセスログの request_processing_timetarget_processing_timeresponse_processing_time の各フィールドの値が**\ -1** に設定されているかどうかを確認します。
  • TargetTLSNegotiationErrorCount メトリクスのデータポイントがあるかどうかを確認します。
  • 問題が発生した時間帯にターゲットでパケットキャプチャを実行して、SSLハンドシェイクに関連していることを確認します。その場合は、パケットキャプチャの実行 セクションの手順を実行してください。
  • 暗号またはプロトコルが一致していないか確認してください。

登録解除されたターゲットによって処理されたリクエストの登録解除遅延期間が経過しました

CloudTrail イベントで、問題が発生している時間帯に DeregisterTargets アクションを含む API 呼び出しが行われているかどうかを確認します。問題の発生中に** DerRegisterTargets** による API 呼び出しが発生した場合、エラーの原因はターゲットの登録解除が早すぎたためです。この問題を解決するには、時間のかかる操作を失敗せずに完了できるように、登録解除の遅延時間を長くしてください。

ターゲットが Lambda 関数である場合の HTTP 502 エラーのトラブルシューティング

注:Lambda 関数へのリクエストが失敗すると、ロードバランサーは Lambda 固有のエラー理由コードをアクセスログの error\ _reason フィールドに保存します。

ターゲットは Lambda 関数で、レスポンスボディが 1 MB を超えています

  • LambdaUserError メトリクスのデータポイントがあるかどうかを確認します。
  • ロードバランサーのアクセスログの** error\ _reason** フィールドが** LambdaResponseTooLarge** に設定されているかどうかを確認します。

ターゲットは、設定されたタイムアウトに達する前に応答しなかった Lambda 関数です

  • Lambda 関数のタイムアウト設定を確認してください。
  • LambdaUserError メトリクスのデータポイントがあるかどうかを確認します。
  • ロードバランサーのアクセスログの** error\ _reason** フィールドが** LambdaUnhandled** に設定されているかどうかを確認します。

ターゲットはエラーを返した Lambda 関数、または関数が Lambda サービスによってスロットリングされました

サービススロットリングに関するガイダンスについては、AWS サポートにお問い合わせください。

パケットキャプチャを実行する

Linux の場合は、次のコマンドを使用します:

sudo tcpdump -i any -w filename.pcap

Microsoft Windows の場合は、 (Wireshark の Web サイトから) Wireshark アプリケーションをダウンロードして使用してください。

詳細については、「VPC 内の EC2 Linux または Windows インスタンスと、インターネットゲートウェイ経由のオンプレミスホスト間のネットワークパフォーマンスの問題をトラブルシューティングする方法を教えてください」を参照してください。「tcpdumpを使用したパケットキャプチャサンプルのテスト」 および「パケットキャプチャの取得」 セクションを参照してください。

AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ