ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか?

Application Load Balancer で "ELB 5XXs" が出ていた時の調査方法を、サポートデスクの実例からご紹介します。
2022.02.04

こんにちは、テクニカルサポートの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" が出ている = ロードバランサーが 5XX エラーを出している」
「"HTTP 5XXs" が出ていない = ターゲット(EC2)からは 5XX エラーが出ていない」

という意味になるため、ロードバランサーの不具合と考えるのは一見、自然に思われます。

ですが、本当にそうでしょうか?

ここで注意したいのは「ターゲット(EC2)から 5XX エラーが出ていない = ターゲット側に問題がない」とは言い切れない点です。

「ターゲット(EC2)が何らかの理由でロードバランサーへ応答を返さなかったため、5XX エラーも何も記録されていない」という可能性もあり得ます。

さらに掘り下げて調査するには、メトリクスだけではなく ALB のアクセスログも併せて確認する必要があります。
次の項で見ていきましょう。

ALB のアクセスログを読み解く

メトリクスの画面で "ELB 5XXs" が出ている日時が特定できたら、その日時付近の ALB のアクセスログを調べ、502 エラーが出力されている行を抜き出します。
※今回は 502 エラーの例を説明していますが、504 エラーの場合でも同様のため、読み替えてください。

ALB アクセスログの一例:

ALB アクセスログには様々な情報が含まれますが、ここでは「ロードバランサー側とターゲット EC2 側、どちらの問題である可能性が高いか」という点に焦点を絞って見ていきます。

今回の調査で注視する項目は、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"」→ ターゲットがアイドルタイムアウト前に接続を閉じた
「"elb_status_code" が "502"」→ ALB がステータスコード 502 を返している
「"target_status_code" が "-"」→ ターゲットが応答を返していない

ということが読み取れます。

さら ALB が 502 エラーを返す理由については、下記の AWS ドキュメントに記載があります。

【参考】Application Load Balancer のトラブルシューティング | AWSより抜粋:

HTTP 502: Bad gateway(一部を抜粋)
ロードバランサーにターゲットへの未処理のリクエストがあるときに、ターゲットが TCP RST または TCP FIN との接続を閉じた。ターゲットのキープアライブ期間がロードバランサーのアイドルタイムアウト値よりも短いことを確認します。


ここまでで確認したことをまとめると、
「ターゲット(EC2)側で何らかの問題が発生して接続が閉じられ、ロードバランサーから送信したリクエストに対して応答が返されなかったため、ロードバランサー側がタイムアウトして ステータスコード 502(もしくは 504)を返した」
という状況が推測されます。

冒頭でお伝えした「"ELB 5XXs" が出ていて、"HTTP 5XXs" は出ていない」という状況が必ずしもロードバランサー側の問題ではなく「ターゲット側の問題である可能性が高い」という理由がご説明できたかと思います。

結論として、ロードバランサー側とターゲット側、どちらの問題なの?

上記では弊社へのお問い合わせでよく見られる事例(ターゲット EC2 側の問題を示している例)を挙げましたが、状況によってはロードバランサー側(AWS 基盤側)の問題である可能性も皆無とは言えません。

結論としてどちらの問題であるかは、上記の調査方法と併せて、以下のような観点からも判断できます。

5XX エラーが発生する頻度

ELB は AWS のマネージドサービスであるため、基盤障害がそう頻繁に発生するとは考えにくいです。5XX エラーが日常的に発生する場合は、ターゲット EC2 側の問題をまず疑いましょう。
(例えばアクセスが増加する時間帯に毎回発生する、など)

逆に普段はまったく発生しないのに、ある日突然一度だけ発生した、というような場合は、基盤障害の可能性もあるかもしれません。

5XX が発生しているターゲットの範囲

ALB アクセスログ内の IP アドレスから 5XX エラーが発生している時のターゲット EC2 を特定しましょう。1つのターゲットでのみ発生している場合は、ターゲット EC2 側の問題である可能性が高いと言えます。
逆に複数のターゲット EC2 や複数ターゲットグループ、複数アベイラビリティゾーンで同時発生している場合は、基盤障害の可能性もあるかもしれません。

対処方法は?

ターゲットEC2 側の問題が疑われる場合

対象 EC2 のメトリクスや EC2 内部の アプリケーションログなどを調査して、応答遅延が発生した原因を特定しましょう。
最もよくあるケースとして、EC2 内部の Webサーバーの KeepAliveTimeout の設定値が関連していた事例が多く見られます。この点に問題がないかもチェックしましょう。

【参考】Apache または NGINX を ELB のバックエンドサーバーとして使用する | AWS
【参考】ELBのタイムアウトを回避するためApacheのKeepAliveTimeoutを設定する | DevelopersIO

ロードバランサー側(AWS 基盤側)の問題が疑われる場合

まずはAWS Health Dashboard を確認し、AWS 側から公開されている障害の情報がないか確認しましょう。
「公開されている障害情報は無いけど、ターゲット EC2 側にもどうしても問題が見つからない」という場合は、ALB のアクセスログや調査した内容を添えてサポートへ問い合わせましょう。

おわりに

ALB の 502 エラーに関して調査方法が分かりにくいとのお問い合わせをよくいただくため、「問題箇所がロードバランサー側か、ターゲット EC2 側か」の切り分けに絞った記事を書いてみました。下記の記事も併せて、調査のお役に立てれば幸いです!

参考資料

ALB で502エラーが発生!!その時あなたはどうする!? | Developers.IO
CLB/ALB の障害調査依頼を受けた時に確認していること | DevelopersIO

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。