[障害対応] ALB で502エラーが発生！！その時あなたはどうする！？

障害対応

#Amazon RDS

#AWS

Takaaki Kakei

2020.01.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「ALB で502エラーが出たら、どうやって原因究明したら良いのだろう？」

ってお悩みではありませんか？今回は、「ALB の502エラーのおさらい」と私が実施している「障害切り分け方法」を紹介します。最後には、「実際にあった原因」もいくつか紹介します。

それでは早速やっていくっ！

ALB の502エラーのおさらい

HTTP 502: Bad Gateway

説明: 登録されたインスタンスから送信された応答をロードバランサーが解析できなかったことを示します。

考えられる原因としては、 Application Load Balancer のトラブルシューティング - HTTP 502: Bad Gateway の記載が参考になります。

(一部抜粋)

接続の確立を試みているときに、ロードバランサーがターゲットから TCP RST を受信した。

接続の確立を試みているときに、ロードバランサーがターゲットから予期しないレスポンスを受信した。

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

ALB のターゲットが予期しないレスポンスを返している可能性も十分に考えられる為、「ALB でエラーが出ているから、ALB の基盤側の問題だ！」と早とちりせず、「ALB 配下のリソースは正常か？」と言う観点も意識して障害切り分けしていきましょう。

障害切り分け方法

私は以下の順番で行います。

システム構成の把握
アクセスがどこまで来ているか確認
障害点のメトリクスや設定、ログの確認

1. システム構成の把握

いきなりピンポイントでどこが原因かを見極めることは難しいので、全体構成を把握して通信の流れを確認します。弊社サポートに問い合わせいただく際も構成図や関係するリソース情報をいただけると、システム構成の把握の時間分が短縮されるので迅速な解決に繋がります。

2. アクセスがどこまで来ているか確認

アクセスがどこまで来ているか確認することで、障害点を絞り込みます。例えば、ALB で 502エラーが出ているが EC2 上の WEB サーバのログにも502エラーが確認されれば、AWS 基盤側の問題でない可能性が高いと判断します。

3. 障害点のメトリクスや設定、ログの確認

障害点のメトリクスや設定、ログを詳細確認することで、原因を特定します。以下に各リソースにおいて私がよく確認するものを紹介します。

ALB
- ALB のアクセスログ ^*1
- CloudWatch のメトリクス
- ターゲットのヘルスステータス
- KeepAlive のタイムアウト値
EC2
- CloudWatch メトリクス
- WEBサーバのシステム情報(アクセスログ、エラーログ、プロセスの稼働状況)
- WEBサーバの KeepAlive の設定
- WEBサーバの tcpdump
その他
- AWS Service Health Dashboard
- AWS Personal Health Dashboard
- CloudTrail

実際にあった原因

いくつか紹介します。

KeepAlive の設定が不適切
Webサーバの Module が原因で SEGV
AWS 基盤側の問題

1. KeepAlive の設定が不適切

バックエンドサーバでの KeepAliveTimeout 値が ALB の Idle Timeout 値よりも短い場合です。バックエンドサーバにおける KeepAlive の有効化および KeepAliveTimeout 値を当該 ALB の Idle Timeout 値より大きくするよう設定することで解消します。

Application Load Balancer のトラブルシューティング - HTTP 502: Bad Gateway

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

Web サーバ（Apache や NGINX）の最適な設定については、以下の公式ドキュメントが参考になります。

ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。

2. Webサーバの Module が原因で SEGV

経験としては少ないですが、 Web サーバの Module が原因で SEGV ^*2が発生している場合です。 Web サーバのエラーログなどを確認してメッセージ内容から原因を特定します。復旧優先であれば該当モジュールを一時的に無効化することを検討しましょう。

3. AWS 基盤側の問題

AWS 基盤側が問題の場合もあります。具体的には、配下の EC2 インスタンスが稼働していた仮想ホスト上で一時的な問題が発生していたり、ALB の基盤上で障害が発生していたなどです。先述した障害切り分けを行っても原因が分からない場合は AWS サポートに問い合わせして確認しましょう。弊社メンバーズポータルをご利用の場合は、弊社の専用フォームよりお問い合わせください。

技術的なお問い合わせに関するガイドライン