■ はじめに
* AWSのロードバランササービスである ELB (Elastic Load Balancing) のトラブルシューティング について、纏める。
【１】HTTP 502: Bad Gateway」が表示された
HTTP 502: Bad Gatewayの発生原因
より抜粋
考えられる原因
+ 接続の確立を試みているときに、ロードバランサーがターゲットから TCP RST を受信した。 + ロードバランサーにターゲットへの未処理のリクエストがあるときに、 ターゲットが TCP RST または TCP FIN との接続を閉じた。 + ターゲットのレスポンス形式が正しくないか、有効でない HTTP ヘッダーが含まれている。 + 新しいターゲットグループが使用されたが、最初のヘルスチェックに合格したターゲットがまだない。 ターゲットが正常と見なされるには、1 つのヘルスチェックに合格する必要があります。
切り分け作業
* 『「ロードバランサ（又はサーバ外）」が原因』なのか『「サーバ側(EC2)」が原因』なのかを 切り分ける必要がある
構成例
+----------------+ +----------------+ +----------------+ +----------------+ | クライアント側 | <===> | ロードバランサ | <===> | サーバ側(EC2) | <===> | データベース側 | +----------------+ +----------------+ +----------------+ +----------------+
切り分けするために確認方法 / 確認項目
[1] ロードバランサのアクセスログをONにする [2] ロードバランサの状態は「healthy」になっているか確認 / サーバ側のアクセスログを確認 [3] 「サーバ側(EC2)」のTCPのダンプをとる [4] netstatコマンドで、ポートが枯渇していないか確認
[1] ロードバランサのアクセスログをONにする
* ロードバランサのアクセスログは、デフォルトで無効なので AWSマネジメントコンソールから有効化にしておく
[2] ロードバランサの状態は「healthy」になっているか確認 / サーバ側のアクセスログを確認
「ロードバランサ」側の確認
* 対象が「healthy」になっているか確認
=> 「healthy」以外の場合、ヘルスチェックの条件やヘルスチェック先を確認し、
『「サーバ側(EC2)」側の確認』を行う
=> Cloud Watch の HealthyHostCount/UnHealthyHostCount でも確認可能
「サーバ側(EC2)」側の確認
* 「サーバ側(EC2)」のアクセスログを確認し、該当する時間帯に対象のリクエストが来ているか確認する
* できれば処理時間を表示できるといい
=> ヘルスチェックの条件の規定値内にレスポンスが返っていないか確かめるため
[3] 「サーバ側(EC2)」のTCPのダンプをとる
【目的】 * 上記の原因（「TCP RST」を送信していないか）を確認するため => RST送っていたら、「サーバ側(EC2)」以降が原因で、ログ(syslogなど)で原因究明を試みる 【方法】 * Linuxの場合、tcpdumpでTCPダンプログをとり、そのログをWiresharkなどのソフトで開き、確認 【補足】 * ハードディスクの空き容量を確認し、十分に空きがあることを確認してから行う事 => 容易にハードディスクが枯渇できるので、不要なログをとらないようにフィルタするようにする
[4] netstatコマンドで、ポートが枯渇していないか確認
* ポートが枯渇していないかnetstatコマンド（例えば、「netstat -an | wc -l」など）で確認
関連記事
ELB ～ 入門編 / ロードバランサ ～
https://dk521123.hatenablog.com/entry/2017/02/17/232855
ELB ～ 基本編 / Auto Scaling ～
https://dk521123.hatenablog.com/entry/2019/10/19/212241
ELB ～ 基本編 / パスベースのルーティング ～
https://dk521123.hatenablog.com/entry/2017/02/27/234919
