AWSのネットワークトラブルが起きたときにVPC Reachability Analyzerを使って解決したら便利だったという話です。
困っていたこと
ALBからECSタスクにリクエストを送りたかった。
しかし、ECSタスクを登録しているターゲットグループのヘルスチェックがRequest timed outになってしまいリクエストがECSタスクに到達していないのを何とかしたい。
調べたこと
ヘルスチェックのリクエストが到達していないので、ネットワーク周りの問題の可能性が高そうと考え下記のようなことを確認しました。
- ECSタスクのセキュリティグループでは、ALBのセキュリティグループから8000番ポートへのインバウンドを許可している
- ECSタスクの8000番ポートにアクセスしたときに正しいレスポンスが返ってくることは別の経路から確認済み
ここまで調べても原因が分からず、他の可能性が思いつかなくてお手上げに近い状態になっていました。
こんな時の救世主こそ、VPC Reachability Analyzerです。
VPC Reachability Analyzerとは
Reachability Analyzer は、静的な設定分析ツールです。Reachability Analyzer を使用して、VPC 内の 2 つのリソース間のネットワーク到達可能性を分析し、デバッグします。Reachability Analyzer は、到達可能なときにこれらのリソース間の仮想パス hop-by-hop の詳細を生成し、それ以外の場合はブロッキングコンポーネントを識別します。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/reachability-analyzer.html
簡単に言うと、2つのリソースでネットワークが到達するかを分析し、経路を表示してくれるツールです。 まさに、今回のような問題が起きているときに重宝するツールですね！
VPC Reachability AnalyzerはAWS Network Managerの一機能として提供されています。
VPC Reachability Analyzerを使ってみる
使い方は簡単です。
Reachability Analyzerのページを開いて、「パスの作成と分析」から設定を行っていきます。
パスの送信元
まず、送信元はALBになるのですが直接指定することはできないので、ALBに紐付いているeniをパスの送信元として指定します。
ここでALBのeniを調べるのに少し時間が掛かったのですが、EC2 > ネットワーク&セキュリティ > ネットワークインターフェイスの一覧からALBのeniを確認することができました。
AZごとに複数のeniがありますが、使うのはどれか1つで大丈夫です。
送信元タイプをNetwork Interfacesにすると、先ほど調べたeniが選択出来るはずです。
ここで、オプションの「送信元での追加のパケットヘッダー設定」を開いて、送信先ポートをターゲットグループの転送先ポートで指定している8000番に指定します。
パスの送信先
続いて、送信先はECSタスクになります。こちらも直接指定することはできないので、ECSタスクのeniをパスの送信先として指定します。
ECSタスクのeniはタスクの設定画面から確認出来るのですぐ見つかりました。
「送信先での追加のパケットヘッダー設定」に送信元での追加のパケットヘッダー設定と同じ項目があったのですが、こちらは設定しませんでした。
送信元と送信先の追加のパケットヘッダー設定をどう使い分けるのか最後まで分からないままでした。
プロトコルはTCPのままでよいので、このままパスの作成と分析を行います。
分析結果
VPC Reachability Analyzerの分析には数分くらい掛かりました。
結果は... 到達不可能。これでネットワーク設定が原因であることが確定しました。
パスの詳細を確認
Reachability Analyzer でできることはこれだけではありません。経路の詳細を表示してどこに原因があるか特定までしてくれます。
なんと、ALBのセキュリティグループでエグレスがブロックされていました。これは盲点だった。
設定変更して、再実行
早速、セキュリティグループでアウトバウンドのルールを追加して、
同じ経路の到達確認であれば、再実行ができるので便利ですね！ちゃんとツールのユースケールを理解して作られていそう。
結果は... 到達可能。
そして、無事ターゲットグループのヘルスチェックも通過しました！
ALBのヘルスチェックも通過するようになって、めでたしめでたし。
