はじめに
AWS re:Invent2024でGAとなった新しいネットワーク監視サービスであるAmazon CloudWatch Network Flow Monitorを早速触ってみました！
Network Flow Monitorは、モニターを作成してAWSワークロードのネットワークパフォーマンスを監視できるサービスです。
これまでCloudWatchで利用可能なネットワークモニタリングサービスとしては、以下の2つがありました。
- Amazon CloudWatch Internet Monitor : AWSアプリケーションとエンドユーザ間のインターネット通信のパフォーマンスを監視
- Amazon CloudWatch Network Synthetic Monitor (Network Monitorから名称が変わったようです) : Direct ConnectやSite-to-Site VPNを利用したハイブリッドネットワークのEnd-to-Endでのパフォーマンス監視
今回GAとなったNetwork Flow Monitorは、これらに続く3つ目のネットワーク監視系サービスで、AWS内のネットワークパフォーマンスを監視できるマネージドサービスです。
現在はEC2やEKSのインスタンス同士、インスタンスからS3, DynamoDB, RDSなどのAWSサービスへの通信が監視対象としてサポートされています。
今まで、AWSワークロード内の通信要件の確認ツールとしてAmazon VPC Network Access Analyzerがありましたが、Network Flow Monitorは設定情報をもとに通信要件を確認するのではなくAgentが収集した実トラフィックに基づくメトリクスを提供する、通信に問題があるときにAWS側の問題なのかユーザ側の問題なのか切り分けができるという違いがあります。
Network Flow MonitorはCloudWatchのコンソール画面からアクセス可能です。
Network Flow Monitorの詳細は以下の記事をご覧ください。
やったこと
以下の検証を実施しました。
- EC2上にWebサーバを建てて、別のEC2から定期的にHTTP通信を実行する
- AZ内及びAZ間で通信を行い、それぞれを監視できることを確認する
- セキュリティグループを変更し、HTTP通信を遮断した際のメトリクスの変化を観察する
構成図は以下の通りです。
環境構築
Network Flow Monitorを利用できるようにするには、以下のステップを踏む必要があります。
-
Network Flow Monitorの有効化：CloudWatchのコンソール画面で有効化することで、Network Flow Monitorのサービスロールに必要な権限が許可され、CloudWatchにメトリクスが送信されるようになります。
-
Network Flow Agentのインストール：AWS Systems Managerのディストリビューターで
AmazonCloudWatchNetworkFlowMonitorAgentを実行することで、監視対象のインスタンスにFlow Monitor Agentをインストールできます。Agentがインストールされると、自動でメトリクスの送信が始まります。(現状、メトリクスの送信まで20分ほどかかるらしい)2-1. AWS Systems Managerのディストリビュータで
AmazonCloudWatchNetworkFlowMonitorAgentを選択
2-2. 「1回限りのインストール」を選択
2-3. コマンドの実行画面で、監視対象のインスタンス (通信の送信元)を選択
Network Flow Monitorの環境が構築されると、後述するワークロードインサイトでメトリクスが可視化されるようになり、モニター作成の準備が整います。
モニター作ってみた
環境を構築できたので、実際にNetwork Flow Monitorを使ってみました。
Network Flow Monitorは大きく、ワークロードインサイトとモニターの2つの機能で構成されます。
ワークロードインサイト
ワークロードインサイトは、Agentが取得したメトリクスを様々なスコープで可視化します。
メトリクスはAZ内、AZ外、VPC間、AWSサービス向けに自動でカテゴライズされ、各カテゴリごとにメトリクスの値が大きなワークロードが可視化されます。
ワークロードインサイトで可視化されたワークロードを選択することで、モニターの作成画面に移動することができ、ワークロード間でのメトリクスの比較としてもモニター作成の前情報としても便利な機能です。
モニター
モニターの作成画面では、監視したいワークロードの両端となるローカルリソースとリモートリソースを選択します。
ローカルリソースは、Agentがインストールされたリソースの所属するサブネットやVPCを、リモートリソースは通信の宛先を選択します。ローカルリソースとリモートリソースは様々なスコープで複数リソースを選択できるので、監視経路を柔軟に選択できます。
実際にAZ内の通信を監視するモニターを作成してみました。
モニターを作成して数分経過すると、メトリクスの表示が始まります。
モニターでは以下のメトリクスを取得できます。
- ネットワークヘルスインジケータ (NHI)
- RTT
- TCP再送信回数
- TCP再送信タイムアウト回数
- 転送されるデータ量
NHIは監視ワークロード内にてAWSの責任範囲内のネットワークパフォーマンス低下が発生しているかを示す2値のメトリクスです。正常時はHealthy、異常時はDegradedと表示されます。また、NHIの棒グラフを見ることで過去にいつ異常が発生していたのかを確認することもできます。
ワークロードに通信障害などの異常が発生した時に、NHIを確認することでユーザ起因の障害なのかAWS起因の障害なのかを切り分けることができます。
Historical Explorerでは、TCP再送信が発生したワークロード上のノードが全て可視化されます。(スゴすぎる...!)
ネットワークパフォーマンスが低下した時はHistorical Explorerで表示されるリソースを確認すると、迅速に問題を切り分けられそうです。
色々遊んでみた
せっかくなので、色々条件を変えてメトリクスを比較してみました。
AZ内の通信とAZ間の通信を比較
AZ内とAZ間でそれぞれモニターを作成して、地理的に距離が変わるとメトリクスに変化があるのか検証してみました。
AZ内の通信を監視するモニター
AZ間の通信を監視するモニター
やはり、地理的に離れているAZ間の通信の方がRTT値は大きくなっていることが分かります。
また、AZ間の通信ではTCP再送信が発生していることが分かります。
通信を遮断してみた
リモートリソースのセキュリティグループを変更することで、ローカルリソースからの通信を拒否する設定にしてみました。
通信不可になったタイミングで、再送信とTCP再送信タイムアウトのメトリクスが大きくなりました。
CloudWatch AlarmでNHIをトリガーにしてAWS起因の通信異常を検知したり、NHIとその他のメトリクスを組み合わせることでユーザ起因の通信異常のみを検知したりなど、様々な用途に使えそうです！
Network Flow Monitorを利用したCloudWatch Alarmの設定例
おわりに
今回はAWS re:InventでGAとなったNetwork Flow Monitorを体験しました。
手軽な環境構築でマネージドにネットワークパフォーマンスを監視できるのはとても便利だと感じました。特にNHIやHistorical Explorerは障害対応の切り分けで大きな武器になりそうな予感がします。
ちなみにNetwork Flow Monitorは12ヶ月分の無料枠があります。環境構築も簡単なのでぜひ試してみてはいかがでしょうか。
初めての投稿で拙い記事でしたが、最後までお読みいただきありがとうございました！Network Flow Monitorの魅力が伝われば嬉しいです。