この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「ALB で502エラーが出たら、どうやって原因究明したら良いのだろう？」
ってお悩みではありませんか？今回は、「ALB の502エラーのおさらい」と私が実施している「障害切り分け方法」を紹介します。最後には、「実際にあった原因」もいくつか紹介します。
それでは早速やっていくっ！
ALB の502エラーのおさらい
説明: 登録されたインスタンスから送信された応答をロードバランサーが解析できなかったことを示します。
考えられる原因としては、 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 サポートに問い合わせして確認しましょう。弊社メンバーズポータルをご利用の場合は、弊社の専用フォームよりお問い合わせください。
AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。本ページでは、お客様が技術的なご質問をサポートケースに起票いただく際に、早期解決に役立つポイントをまとめました。例文も掲載していますのでぜひご参照ください。
まとめ
- ALB の502エラーの概要と考えられる原因を理解しよう
- 自分なりの障害切り分け方法を確立しよう
- 実際にあった原因に当てはまっていないか設定を確認してみよう
最後に
いかがだったでしょうか。障害の切り分けの方法は人それぞれかと思いますが、経験則を元に私なりに整理してみました。障害対応シリーズは他にも書いているので良かったら参照下さい！
以上！筧( @TakaakiKakei )でした！
更新履歴
- 2020/01/30 新規作成
6
