Amazon CloudWatchのNetworkフローモニターを動かしてみた

はじめに

2024年12月1日付で、フローモニターを使用してAWSのワークロードにおけるネットワークのパフォーマンスをモニタリングする新機能が、Amazon CloudWatchに追加されました。

この機能により、AWSのコンピューティングインスタンス(EC2やEKS)と、AWSサービス(Amazon S3、Amazon RDS、Amazon DynamoDB等)間のネットワークであったり、コンピューティングインスタンス間通信(VPC-VPC等)のパフォーマンス状況の可視化が可能になります。これにより、コンピューティングインスタンス上で稼働中のアプリに性能悪化が見られた場合、その原因がアプリ側のパラメータ設定によるものなのか、あるいは、ネットワーク自体に問題があるものか否かを迅速に切り分けできるようになることが期待できます。
そこで、実際にこのフローモニターをセットアップして動かしてみて、感触をつかんでみることにしました。

フローモニター稼働環境設定

事前準備

フローモニターの稼働環境設定の最初の作業は、フローモニター・エージェントのEC2インスタンスへのインストールになります。そのため、事前に以下をプロビジョニングしておきます。

• VPC
• パブリック・サブネット
• インターネット・ゲートウェイ
• パブリックEC2インスタンス (※今回は、Ubuntu Linux 24.0.1LTSを使用)

また、エージェントとの通信先のAWSサービスとして、今回はS3を使用することにしたので、S3バケツを用意しておきます。

フローモニター・エージェントの導入

下記のAWSドキュメントの記載に沿って、実施していきます。

エージェントに対する必要権限の追加

EC2インスタンス内にインストールされるエージェントが、フローモニターに対して必要なメトリクスを送信できるようにするため、EC2インスタンスのIAMロール(インスタンスプロファイル)に、「CloudWatchNetworkFlowMonitorAgentPublishPolicy」という名前のAWS管理ポリシーをアタッチする必要があります。(下記の赤枠が該当のポリシーです。)

AWSドキュメント上は、EC2インスタンスにエージェントをインストールする前に、この権限追加作業を実施しておくことが推奨されています。

エージェントのインストール

フローモニターのエージェントは、AWS Systems Manager(以下、SSM)のディストリビューター・パッケージ「AmazonCloudWatchNetworkFlowMonitorAgent」という形で提供されています。SSMのノードツールのうち、「ディストリビューター」を選択し、「Amazonが所有」タブにおいて、パッケージ検索欄に「AmazonCloudWatchNetwork」と入力し、Enterキーを押下します。

パッケージ検索欄に入力可能な文字数には制限があるらしく、「AmazonCloudWatchNetworkFlowMonitorAgent」とフルスペルを入力して検索すると、文字数オーバーで検索エラーになりましたので、ご注意ください。

検索に成功すると、下記のように対象のエージェントが表示されますので選択します。SSMでインストールの時間をスケジュールすることも可能ですが、ここでは「1回限りのインストール」を押下します。

すると、下記「コマンドの実行」画面に遷移しますので、下にスクロールしていきます。


上記の「コマンドのパラメータ」では、赤枠のAction欄が「install」になっていること、および、Name欄が今回導入するエージェント名「AmazonCloudWatchNetworkFlowMonitorAgent」が表示されていることを確認し、更にスクロールします。

上記の「ターゲット」では、エージェントをインストールするEC2インスタンスを選択し、更に下にスクロールします。

上記の「出力オプション」のところは、コマンドの実行結果をS3バケツに格納するか、CloudWatch Logsに書くか否かを選択できます。いずれもオプションなので必須ではないですが、コマンドの実行がエラーになった場合に詳細ログを確認できるのと、SSMコンソール上は最大2500文字までしか表示されないという制約があるため、ここでは、S3バケツに詳細ログを書き込むように設定しておきます。その後は一番下までスクロールして右下の「送信」ボタンを押下します。すると下記のような画面に遷移します。

画面遷移後のステータスは「進行中」となっていますが、赤枠のリフレッシュボタンを何度か押下して、最終的に下記のようにステータスが「成功」と表示されればOKです。

コマンド実行時の出力内容は、下記画面の赤枠のインスタンスIDをクリックすれば参照可能です。基本的にステータスが「成功」の場合は特段見る必要はありませんが、参考までにコマンド実行時のログを添付しておきます。

Initiating AmazonCloudWatchNetworkFlowMonitorAgent 1.0 install
Plugin aws:runShellScript ResultStatus Success
install output: Running sh install.sh
Selecting previously unselected package networkflowmonitoragent.
(Reading database ... 70601 files and directories currently installed.)
Preparing to unpack AmazonCloudWatchNetworkFlowMonitorAgentInstaller.deb ...
Unpacking networkflowmonitoragent (0.1-2) ...
Setting up networkflowmonitoragent (0.1-2) ...
creating cgroupv2 mount point
Network Flow Monitor Agent 0.1-2 installed successfully.

Successfully installed AmazonCloudWatchNetworkFlowMonitorAgent 1.0

エージェントのアクティベート

次はエージェントのアクティベートになります。これも、SSMの変更管理ツール配下の「ドキュメント」から実行するという、SSM独特の導入方法です。

AWSドキュメント上は「In the AWS Management Console, in AWS Systems Manager, under Shared Resources, choose Documents.」と記述がありますが、SSMコンソール上に「Shared Resources」といったメニューはないので、ご注意ください。ドキュメントの記載不備だと思っています。

実際、私も普段SSMはフリートマネージャーとセッションマネージャー位しか使用しないので、初めての操作であり結構楽しんでます。下記画面の右側のドキュメント検索欄(赤枠箇所)に「AmazonCloudWatch-Network」でサーチし、Enterキーを押下します。

すると、下記画面の赤枠に見られるように「AmazonCloudWatch-NetworkFlowMonitorManageAgent」というものが表示されればOKです。

この後の手順がAWSドキュメント上は一部省略されてしまっていますが、赤枠内のドキュメント名のリンクをクリックすれば先進めできます。すると下記の画面に遷移します。

画面赤枠の「コマンドを実行する」を押下すると、先のエージェントのインストール時にも見た「Run Command」の画面に遷移します。

コマンドドキュメント名が正しいものになっている事を確認して、下にスクロールします。

ここでは、「コマンドのパラメータ」に「Activate」が指定されていることを確認します。下記画面のターゲットの指定方法も、エージェントのインストール時と同様の指定をすればOKです。

後は、念の為「出力オプション」にエージェントのインストール時と同様にS3バケツを指定した後、一番下にスクロールして右下の「送信」ボタンを押下します。以下は、コマンド実行が成功した場合の画面出力になります。

ちなみに今回はコマンド実行時に何かしらのログは出力されていませんでした。Linux側から見れば、エージェントはLinuxの1サービスですし、サービスのアクティベーションといってもLinux上では実質的にサービスの起動コマンドが入っていると思います。Linuxのコマンドの特徴として、コマンドの実行が正常終了した場合に空のプロンプトを返すのが一般的なので、今回もその類だと思いました。

フローモニターのセットアップ

フローモニターの有効化

ここからは、Amazon CloudWatchのコンソールに遷移して設定を行います。まずは、フローモニターを有効化することが必要になります。「ネットワークモニタリング」配下に「フローモニター」というメニューが新規に追加となっています。これを選択すると下記のような画面が表示されるので、右上の「ネットワークフローモニターを有効にする」ボタンを押下します。

すると下記画面のように「保留中」(赤枠箇所)というステータスになります。何故か、画面のリフレッシュボタンがありません。。

私は、以前に別のAWSの新機能検証をした際に、このように「保留中」というステータスのまま処理が長時間終わらなかったことを経験していたので、またあの悪夢の再来かと少しナーバスになっていましたが、体感的に5分位待ったところで、自動的に下記のように画面遷移できたので、ホッとしました。

ここからは後続のフローモニター作成に入っていきます。

フローモニターの作成

上記画面の「モニターを作成」ボタンを押下します。下記のようなモニター作成画面が表示されるので、必要事項を記入していきます。



フローモニターによるネットワーク監視では、どこからどこへのネットワークを監視するのかといった、FromとToの指定が必要になります。「ローカルリソース」がFrom、「リモートリソース」がToに該当します。これらの詳細については、AWSドキュメント内の「Local and Remote Resouces」に記述されています。

• ローカルリソース

  • VPC、サブネット、AZのいずれかから選択することが可能です。基本的には、エージェントが稼働しているEC2のプロビジョニング先サブネットを指定すれば良いと思います。

• リモートリソース

  • VPC、サブネット、AZ、AWSサービスのいずれかから選択することが可能です。今回は、EC2とS3間のネットワーク監視をしたいので、「AWSサービスを選択」プルダウンメニューから「S3」を選択します。

リモートリソースの指定において、「AWSサービスを選択」プルダウンメニューから選択可能なのは「S3」と「DynamoDB」の2つのみのようでした。仮に、EC2とRDS間のネットワークを確認したい場合、ダイレクトにRDSをAWSサービスから選択できないので、その場合には「サブネットを選択」からRDSのプロビジョニング先であるプライベートサブネットを指定すれば良いと思います。

ここまで設定した後、画面右下にある「次へ」ボタンを押下します。設定内容を確認した後、「モニターを作成」ボタンを押下します。


その後、下記画面のようになればモニター作成は完了です。

フローモニター稼働確認

EC2とS3間の通信で、ある程度のサイズのデータの送受信をしないと、画面上の変化は見られないかと思い、S3バケツにAWS CLIのzipファイルを事前に格納しておき、それをEC2からAWS CLIを使用して、何度かzipファイルの送受信を行いました。ちなみに、このzipファイルは6MB程度のものです。しばらく時間が経過すると、下記画面のように「ネットワークヘルスインジケーター」が緑字で大きく「正常」と表示されました。

画面上の記載を見ると、AWSのネットワークに異常が発生すると、このネットワークヘルスインジケーターの所に「パフォーマンス低下」と表示されるとあります。実際にネットワーク異常を検証するのは現実的ではないので、今回はそこまでの確認はしていません。ただ、EC2上で稼働するワークロードにおいて何かしらの性能劣化が見受けられた場合、このネットワークヘルスインジケーターを確認すれば、原因がネットワーク側にあるのか否かの切り分けが迅速にできるようになるので、障害発生時の問題判別の際に有用となる機能だと思いました。また、下記画面からフローモニターが稼働していた時間帯のネットワークヘルスインジケーターの状態が確認できます。

気になった点

フローモニターの概要画面において、「トラフィックの概要」の所に時間が経過しても何も表示されないのが少し気になりましたが、AWSドキュメントに以下の記載がありました。どうやら、エージェントを初回導入後は20分程経過しないと、情報表示できないように読めました。

• ドキュメントの記述
  "Note: After you first install Network Flow Monitor agents, there is a waiting period (about 20 minutes) before you can view performance metrics, while agents gather and send data to the Network Flow Monitor backend."

その後、1度作成したモニターを削除して、再度モニターを作成したところ、作成直後にいきなり「トラフィックの概要」の所に値が入りました。

また、下記図のように、転送されるデータ(平均)、再送値(合計)、再送信タイムアウト(合計)、ラウンドトリップタイム(分)等のグラフに情報が表示されています。

ひょっとしたら、初回のモニター稼働時にデータ送受信していた際の履歴をエージェントが読んで、トラフィックの概要欄に表示したのかなと思いましたが、まだ1度しか動かしたことがないので、正直原因は謎です。発表されて間もない機能ということもあり、もうしばらく使い込みをして、挙動を詳しく見ていく必要があるかと思いました。

さいごに

本記事では、2024年12月1日に発表されたAmazon CloudWatchのNetworkフローモニター新機能の設定方法から使用感を纏めました。現状、少し疑問に思う点もありますが、個人的には今の時代の流れを考慮すると、以下のようなユースケースで重宝しそうな気がしました。

生成AIアプリのナレッジベース使用時の性能劣化調査

生成AIアプリでは、S3バケツをナレッジベースとして、プロンプトを実行時に、事前定義済のモデルでは学習されていない固有の情報を拾ってくるようにRAGを実装することが多いかと思います。その際、RAGからの情報読み込みが遅いような場合、生成AIアプリ側に問題があるのか、はたまた、生成AIアプリとS3間のネットワークに問題があるのかの迅速な原因の切り分けが可能になると期待できます。

当該機能に更にアップデートが行われて、より良いネットワーク監視機能に成長することを期待します。