この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
最終更新： 2024年1月4日（概念図を追加しました）
こんにちは、テクニカルサポートのShimizuです。
サポートデスクにおいて、Application Load Balancer（ALB）をご利用中のお客様から、よく以下のようなお問い合わせをいただきます。
「ALB の 502 エラー（もしくは 504 エラー）の原因調査で、メトリクスの画面に "ELB 5XXs" が出ていますが、"HTTP 5XXs" は出ていません。これはロードバランサー側（AWS基盤側）に問題があったと判断してよいでしょうか？」
結論から言いますと「いいえ」です。
必ずしもロードバランサー側の問題とは限りません。
筆者のサポートデスクでの経験上、多くの場合バックエンドサーバー側（EC2側）の問題に起因しています。具体的には下記図のような状況です。
どの点を確認すればそう判断できるのか、実際にあったケースをもとに、調査方法をご紹介します。
メトリクスの意味を読み解く
そもそも "ELB 5XXs" と "HTTP 5XXs" は何を意味しているのでしょうか。
AWS の公式ドキュメントには以下の記載があります。
【AWS】Application Load Balancer のメトリクスより抜粋：
HTTPCode_ELB_5XX_Count（= ELB 5XXs）
ロードバランサーから送信される HTTP 5XX サーバーエラーコードの数。この数には、ターゲットによって生成される応答コードは含まれません。HTTPCode_Target_5XX_Count（= HTTP 5XXs）
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。
上記を踏まえて、冒頭の状況を振り返ると、
「"ELB 5XXs" が出ている = ロードバランサーが500系のサーバーエラーを出している」
「"HTTP 5XXs" が出ていない = ターゲット側（EC2）からは500系のエラーが出ていない」
という意味になるため、ロードバランサーの不具合と考えるのは一見、自然に思われます。
ですが、ここで注意したいのは
「ターゲット側（EC2）から500系のエラーが出ていない = ターゲット側に問題がない」とは言い切れない点です。
「ターゲット側（EC2）の内部で問題が発生して、ロードバランサーへ応答コードを返さなかったため、500系のエラーが何も記録されていない」という可能性もあり得ます。
さらに詳しく調査するには、メトリクスだけではなく ALB のアクセスログも併せて確認する必要があります。次の項で見ていきましょう。
ALB のアクセスログを読み解く
メトリクスの画面で "ELB 5XXs" が出ている日時を特定し、その日時付近の ALB のアクセスログから 502 エラーが出力されている行を抜き出します。
※今回は 502 エラーの例を説明していますが、504 エラーの場合でも同様のため、読み替えてください。
ALB アクセスログの一例：
ここで注視する項目は、8カラム目～10カラム目です。
-1 502 -それぞれの項目の意味を、AWS の公式ドキュメントで調べてみましょう。
【参考】Application Load Balancer のアクセスログ | AWSより抜粋：
response_processing_time（8カラム目）
ロードバランサーがリクエストをターゲットに送信できない場合、この値は -1 に設定されます。この状況が発生するのは、ターゲットがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。elb_status_code（9カラム目）
ロードバランサーからの応答のステータスコード。target_status_code（10カラム目）
ターゲットから応答のステータスコード。この値は、ターゲットへの接続が確立され、ターゲットが応答を送信した場合のみ記録されます。それ以外の場合は、- に設定されます。
これらの意味を上記のログに当てはめてみると、
-1 502 -「"response_processing_time" が "-1"」→ ターゲット側（EC2）がアイドルタイムアウト前に接続を閉じた
「"elb_status_code" が "502"」→ ALB がステータスコード 502 を返している
「"target_status_code" が "-"」→ ターゲットが応答を返していない
ということが読み取れます。
さら ALB が 502（もしくは 504）エラーを返す理由については、下記の AWS ドキュメントに記載があります。
【参考】Application Load Balancer のトラブルシューティング | AWSより抜粋：
HTTP 502: Bad gateway（一部を抜粋）
ロードバランサーにターゲットへの未処理のリクエストがあるときに、ターゲットが TCP RST または TCP FIN との接続を閉じた。ターゲットのキープアライブ期間がロードバランサーのアイドルタイムアウト値よりも短いことを確認します。HTTP 504: Gateway Timeout（一部を抜粋）
ロードバランサーはターゲットへの接続を確立したが、アイドルタイムアウト期間が経過する前にターゲットが応答しなかった。
ここまでで確認したことをまとめると、
「バックエンドサーバー（EC2）内部で何らかの問題が発生して、ロードバランサーから送信したリクエストに対して応答を返さず接続を閉じた（もしくはタイムアウトした）ため、ロードバランサー側がステータスコード 502（もしくは 504）を返した」
という状況が推測されます。
冒頭でお伝えした、以下のような状況です。
以上で「"ELB 5XXs" が出ていて、"HTTP 5XXs" は出ていない」という状況が必ずしもロードバランサー側の問題ではなく、バックエンドサーバー側（EC2内部）の問題に起因している理由がご説明できたかと思います。
ロードバランサー側で基盤障害が起きている可能性は？
前項では弊社へのお問い合わせで最も多く見られる事例（ターゲット EC2 側に起因している例）を挙げましたが、状況によってはロードバランサー側に起因している可能性も皆無ではありません。
実際に AWS サポートへ問い合わせて確認すると、稀にですが AWS 基盤側の問題だったケースもあります。
前項でご紹介した調査方法と併せて、以下のような観点も判断基準になります。
500系のエラーが発生する頻度
500系エラーが日常的に発生している場合は、まずターゲット EC2 側の問題を疑いましょう。
ELB は AWS のマネージドサービスであるため、基盤障害がそう頻繁に発生するとは考えにくいです。 例えば毎回アクセスが増加する時間帯に500系エラーが出るような場合、EC2 内部のアプリケーション側の問題や、EC2 インスタンスの性能のひっ迫も考えられます。
逆に普段はまったく500系エラーが発生しないのに、ある日突然一度だけ発生した、というような場合は、基盤障害の可能性もあるかもしれません。
500系エラーが発生している範囲
1つの EC2 でのみ500系エラーが発生している場合は、インスタンス側の問題が疑われます。
逆に複数のターゲット EC2 や複数ターゲットグループ、複数アベイラビリティゾーンで同時発生している場合は、基盤障害の可能性も考えられます。
確認方法としては、ALB アクセスログ内で500系エラーの行を抜き出し、ターゲットのIPアドレスから EC2 インスタンスを特定しましょう。
500系エラーが毎回ある特定の EC2 でのみ発生している場合は、ターゲット EC2 側の問題である可能性が高いと言えます。
対処方法は？
ターゲット EC2 側の問題が疑われる場合
対象 EC2 のメトリクスや EC2 内部の アプリケーションログなどを調査して、500系エラーにつながった処理遅延の原因を特定しましょう。
500系エラーが頻発する場合によく見られるケースとして、EC2 内部の Webサーバーの KeepAliveTimeout の設定値が関連している可能性があります。下記ドキュメントを参考に、この設定に問題がないかもチェックしましょう。
【参考】Apache または NGINX を ELB のバックエンドサーバーとして使用する | AWS
また、バックエンド EC2 のリソース不足により処理遅延が発生し、ELB の 504 Timeout エラーにつながる可能性も考えられます。もし EC2 側のCPU不足やメモリ不足が疑われる場合は、必要に応じて EC2 の台数増加、スペック増強も検討しましょう。
ロードバランサー側（AWS 基盤側）の問題が疑われる場合
まずはAWS Health Dashboard を確認し、AWS 側から公開されている障害の情報がないか確認しましょう。
「障害の情報は見つからないものの、ターゲット EC2 側の内部調査でも、どうしても問題が見つからない」という場合は、ALB のアクセスログや調査した内容を添えてサポートへ問い合わせましょう。
おわりに
ALB の 502 や 504 エラーの調査には確認するべき点が多く、弊社サポートデスクにもよくお問い合わせをよくいただくため、「問題箇所がロードバランサー側か、ターゲット EC2 側か」の切り分けに絞った記事を書いてみました。
分かりやすく Yes/No 形式でトラブルシューティングできる記事も書きましたので、皆様の調査のお役に立てば幸いです！
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
2
