この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、テクニカルサポートの Shimizu です。
弊社ヘルプデスクへ「Application Load Balancer（ALB）の 502 エラーの原因調査が難しい」というお問い合わせをよくいただきます。
実際サポート側においても「原因箇所が ALB 側か、またはバックエンド EC2 サーバー側か」の切り分けは確認するべき点が多く、毎回時間がかかります。
そこで「もっと簡単に原因を切り分ける方法がないか」と考えた結果、Yes/No 形式のトラブルシューティングを作ろうと思いつきました。
それでは始めてみましょう！
質問
[質問1] 該当時刻の ALB のメトリクスを確認しましょう。「HTTP 5XXs」は出ていますか？
YES（出ている）
バックエンドサーバーの内部から 500 系のエラーレスポンスが返されており、バックエンド側の問題を明確に示しています。
→ [結果A] へ
NO（出ていない）
問題が ALB 側かバックエンド側か、さらに切り分けが必要です。
→ [質問2] へ
[質問2] ALB の「アイドルタイムアウト」の値を確認しましょう。この値がバックエンドWebサーバー側の KeepAliveTimeout 値よりも大きく設定されていますか？
YES（ALB アイドルタイムアウト値の方が大きい、またはバックエンド側の KeepAlive 設定を無効にしている）
タイムアウトの設定値が ALB 502 エラーの要因となっている可能性があります。設定を見直しましょう。
→ [結果B] へ
NO（バックエンドの KeepAliveTimeout 値の方が大きい）
タイムアウトの設定値には問題なさそうなため、さらに切り分けが必要です。
→ [質問3] へ
[質問3] ALB の CloudWatch メトリクスを「AZ別」で確認しましょう。502 エラーを示す「HTTPCode_ELB_502_Count」メトリクスは、複数のアベイラビリティゾーン（AZ）で同時に出ていますか？
YES（複数のAZで同時に出ている）
ALB 側に起因している可能性がありますが、もう少し切り分けが必要です。
→ [質問3a] へ
NO（単一のAZのみで出ている、もしくは複数AZだが同時には出ていない）
バックエンドサーバー側に起因している可能性が高いです。メトリクスが出ているAZに配置されたバックエンド EC2 インスタンスを特定し、調査対象を絞りこんで次の質問に進みましょう。
→ [質問4] へ
[質問3a] CloudWatch メトリクスの表示期間を数日間に広げてみましょう。「HTTPCode_ELB_502_Count」メトリクスは頻繁に、または継続的に発生していますか？
YES（頻繁に、または継続的に発生している）
ALB 基盤側の問題が頻繁に、長期間にわたって発生するとは考えにくいため、バックエンドサーバー内部の問題である可能性があります。
→ [結果C] へ
NO（一度しか発生していない）
普段は発生しないのに一度だけ発生しているという状況なら、ALB 基盤側の問題である可能性があります。
→ [結果D] へ
[質問4] 質問3で確認したバックエンド EC2 インスタンスのメトリクスを調べましょう。「StatusCheckFailed_System」が 1 になっている、もしくは他のメトリクスの途切れなどの異常が見られますか？
YES（メトリクスの異常が見られる）
バックエンド EC2 インスタンス側の基盤の問題である可能性があります。
→ [結果E] へ
NO（メトリクスの異常は見られない）
メトリクスで特に異常が見られない場合は、バックエンド EC2 インスタンス内部の問題である可能性が高いです。
→ [結果F] へ
結果
[結果A] バックエンドのWebサーバー内部から 500 系エラーレスポンスが返されています。
CloudWatch メトリクスの「HTTP 5XXs(HTTPCode_Target_5XX_Count)」はバックエンドのWebサーバー内部から 500 系のエラー応答コードが返されたことを示しているため、明確にバックエンド側の問題であると言えます。 Application Load Balancer の CloudWatch メトリクス からの引用：
HTTPCode_Target_5XX_Count
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。
バックエンドサーバー側の原因調査は AWS の責任共有モデルによりユーザー側の責任範囲となるため、バックエンドサーバー内部のWebアクセスログやアプリケーションログを調査して、500 エラーが発生した根本原因を特定しましょう。 責任共有モデル
[結果B] ALB とバックエンドWebサーバーのタイムアウト値が関連している可能性があります。
ALB が 502 エラーを返すケースでよく見られる要因の1つとして、バックエンド Webサーバー側の KeepAlive 設定が無効になっている、もしくは KeepAliveTimeout 値が ALB 側のアイドルタイムアウトよりも小さく設定されている場合があります。下記のリンクを参考にこの設定を見直してみましょう。 Apache または NGINX を ELB のバックエンドサーバーとして使用する ※タイムアウトの適正な値はユーザー側のアプリケーション要件等により異なるため、ドキュメント通りに設定すれば必ず 502 エラーが解消するとは限りません。環境に合わせてチューニングする必要があります。
[結果C] バックエンドWebサーバー内部の問題が起因している可能性があります。
ALB の基盤障害が日常的に発生するとは考えにくいため、502 エラーが頻繁に発生している場合はバックエンド側の問題が疑われます。
「バックエンドWebサーバー側から 500 系エラーが返されていないのに、なぜバックエンド側の問題なの？」と疑問に思われるかもしれませんが、例えばバックエンドサーバー内部で処理がスタックして何も応答コードが返されなかった場合に、ALB 側から 502 や 504 のエラーを返すケースがあります。詳しい確認方法は下記のブログ記事でご紹介しているので、参考にしてみてください。
ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか？
この場合の調査は AWS の責任共有モデルでユーザー側の責任範囲となるため、サーバー内部のWebアクセスログやアプリケーションログを調査して根本原因を特定しましょう。
責任共有モデル
毎回Webアクセスが増加するタイミングで 502 エラーが出ているような場合は、ミドルウェアのプロセス滞留を疑ったり、必要に応じてバックエンドサーバーのリソース増強なども検討しましょう。
[結果D] ALB の基盤側に問題が発生している可能性があります。
502 エラーが複数のAZで同時に発生しており、かつ「普段は発生しないのに、ある時一度だけ発生した」という状況であれば、ALB 基盤側に問題が発生していた可能性も考えられます。AWS Health Dashboard を確認して、該当する時間帯やリージョン、リソースに関する障害のイベント情報がないか確認しましょう。
AWS Personal Health Dashboard
「ALB 基盤側の問題が疑われるものの、障害のイベント情報が見つからない」という場合は、詳細調査のために当該時刻の ALB アクセスログを収集して、サポートへ問い合わせてみましょう。
Application Load Balancer のアクセスログ
[結果E] バックエンド EC2 インスタンスの基盤側の問題です。
CloudWatch で「StatusCheckFailed_System」が出ていたり、他のメトリクスに途切れが見られる場合、バックエンド EC2 インスタンスの基盤側の問題が疑われます。
すでに Auto Scaling 等でインスタンスが入れ替えられている場合は問題ありませんが、もし異常のあったインスタンスを継続使用している場合は、当該のインスタンスの stop/start をすることで再発を防ぎましょう。
EC2 インスタンスのステータスチェックが失敗する場合の原因と確認方法
[結果F] バックエンド EC2 インスタンス内部の問題です。
特定の EC2 インスタンスでのみ発生しており、異常なメトリクスも特に出ていない場合、バックエンド EC2 内部の問題が疑われます。
「バックエンドWebサーバー側から 500 系エラーが返されていないのに、なぜバックエンド側の問題なの？」と疑問に思われるかもしれませんが、例えばバックエンドサーバー内部で処理がスタックして何も応答コードが返されなかった場合に、ALB 側から 502 や 504 のエラーを返すケースがあります。詳しい確認方法は下記のブログ記事でご紹介しているので、参考にしてみてください。
ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか？
この場合の調査は AWS の責任共有モデルでユーザー側の責任範囲となるため、サーバー内部のWebアクセスログやアプリケーションログを調査して根本原因を特定しましょう。
責任共有モデル
毎回Webアクセスが増加するタイミングで 502 エラーが出ているような場合は、ミドルウェアのプロセス滞留を疑ったり、必要に応じてバックエンドサーバーのリソース増強なども検討しましょう。
おわりに
いかがでしたでしょうか。
テクニカルサポートでの経験上、ALB 502 エラーの多くの場合はバックエンドサーバー側に起因しており、ALB 側の基盤に問題があったケースは稀です。
しかしながら原因切り分けのハードルが高いため、一次的な切り分けができていない状態でお問い合わせをいただくケースが多く、結果として解決までに時間がかかってしまうことが多い印象です。
ALB の原因切り分けをできるだけ簡単にし、皆様の問題解決までの時間を少しでも短縮できれば、との想いで本記事を執筆しました。この情報がお役に立てれば幸いです！
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
4
