この記事では、AWS (Amazon Web Services) と GCP (Google Cloud Platform) という二大クラウドプラットフォームに特有のネットワーク監視手法について解説します。具体的には、それぞれのVPC Flow LogsをNew Relicに連携し、クラウド上の通信を可視化する具体的な手順を学びます。オンプレミス環境との違いを理解し、クラウドネイティブな可観測性を手に入れることが本稿のゴールです。
1. なぜクラウドネットワーク監視は "特別" なのか？
オンプレミス環境のネットワーク監視に慣れ親しんだエンジニアにとって、クラウドのネットワークは一見するとシンプルに見えるかもしれません。物理的なスイッチやルーターの配線を意識する必要はなく、コンソール画面から数クリックで仮想ネットワーク（VPC: Virtual Private Cloud）を構築できます。
しかし、その手軽さの裏側には、オンプレミスとは全く異なる監視上の特性、あるいは「新たなブラックボックス」が存在します。
- 物理層のブラックボックス化: 私たちは、AWSやGCPが管理する物理的なネットワークインフラに直接アクセスすることはできません。したがって、物理機器の故障やパフォーマンス劣化を、SNMPで監視するといった従来のアプローチは通用しません。
- 責任共有モデルの理解: クラウド事業者がインフラの稼働責任を負い、ユーザーはVPC内のリソースや設定に責任を持つ、という「責任共有モデル」が基本です。私たちの監視対象は、このユーザー責任範囲に限定されます。
- クラウドネイティブなデータソースの活用: 監視データは、SNMPのように機器から直接ポーリングするのではなく、クラウドプラットフォームが提供する専用のサービス（VPC Flow Logsなど）から取得します。これらのサービスを管理コンソールやCLI/API経由で設定し、生成されるログストリームを処理することがクラウド監視の基本となります。
さらに、VPC Flow Logsが提供する可観測性は、オンプレミスで標準的に用いられてきたSNMPやNetFlowとも、その役割が異なります。それぞれの技術が得意とすることを交通量に例えるなら、以下のように整理できるのではないでしょうか。
- SNMP: ネットワーク機器の健全性を監視します。「道路（インターフェース）はどれくらい混雑しているか（Traffic量）」「道路に異常はないか（CPU/Memory）」を把握することに長けています。
- NetFlow: 通信の内訳を可視化します。「どんな種類の車（プロトコル）が、どこから来て（送信元IP）、どこへ向かっているのか（宛先IP）」という交通実態を分析するのに役立ちます。
- VPC Flow Logs: 上記の内訳に加えて、通信に対するポリシーの適用結果までを記録します。「その車は検問所（セキュリティグループ/ACL）を通過できたか（
ACCEPT）、それとも止められたか（REJECT）」を知ることができます。
このように、VPC Flow Logsは、意図しない設定によってアプリケーションの通信が遮断されている、といった設定レベルの問題を発見する上で極めて強力な武器となります。これは単なるパフォーマンス監視やトラフィック分析に留まらない、クラウドネイティブなセキュリティ・トラブルシューティングの領域と言えるでしょう。
こうした特性を持つクラウドネットワークの "血流" 、すなわち通信状況を把握するために最も重要なデータソースが、今回取り上げる VPC Flow Logs です。
2. AWS VPC Flow Logs を New Relic で可視化する
VPC Flow Logsは、VPC内のネットワークインターフェースを行き来するIPトラフィックに関する情報をキャプチャする機能です。このログを利用することで、「どのIPアドレスからどのIPアドレスへ」「どのポートで」「どれだけのデータが」転送されたか、といった詳細な通信記録を取得できます。
New RelicへAWS VPC Flow Logsを連携させるには、New Relicが公式に推奨している Amazon Kinesis Data Firehose を利用したアーキテクチャを採用します。
この構成は、VPCからFirehoseへログを直接発行し、FirehoseがNew Relicのエンドポイントへデータを自動的に転送する仕組みです。途中でLambda関数のようなカスタムコードを管理する必要がなく、非常にシンプルかつ信頼性の高いデータパイプラインを構築できます。
設定手順の概要
AWS VPC Flow Logsを連携させるには、New Relicのガイド付きインストールを利用することを強く推奨します。これが最も迅速で信頼性の高い方法です。
ガイド付きインストールの画面では、ご利用の環境に応じたAWS CLIコマンドが自動生成されます。このコマンドをAWS CloudShellまたはターミナルで実行すると、CloudFormationスタックがデプロイされ、本稿で解説しているすべてのコンポーネント（Kinesis Data Firehose、IAMロール、そして最も重要なカスタムログフォーマット）が自動的に設定されます。
詳細な手順については、公式ドキュメントも併せてご参照ください。
重要：ログパーティションについて
New Relicでは、AWS VPCフローログは
Log_VPC_Flows_AWSという名前の専用のログパーティションに保存する必要があります。本稿で推奨しているガイド付きインストールを利用する場合、このパーティションは自動的に作成されます。後ほど解説するNRQLクエリでデータを参照する際は、このパーティション名を指定することになります。
補足：データ量を節約するためのサンプリング
もし、VPCフローログの全量を転送せずにデータ取り込み量を節約したい場合、サンプリング用のAWS Lambda関数を利用する選択肢があります。
この方法は、例えば「10件に1件」といった設定したサンプルレートに基づいてログを間引くことで、New Relicに転送されるデータ量を削減します。 New Relicのガイド付きインストールでは、このサンプリング用Lambdaを作成するためのCLIコマンドを生成する機能が提供されています。
注意点として、サンプリングはシンプルなカウントベースの機能であるため、特定の通信が記録から漏れる可能性があることを理解しておく必要があります。 New RelicのUI上では、データがサンプリングされていることを示す表示に注意してください。
以下に掲載する手動での設定手順は、ガイド付きインストールが利用できない環境や、各コンポーネントの役割を深く理解したい方向けの参考情報です。
- New RelicでIngest APIキーを取得: New Relicプラットフォームから、データ取り込み用のAPIキーを生成します。
- Kinesis Data Firehose 配信ストリームの作成:
- ソースとして「Direct PUT」、送信先として「New Relic」を選択します。
- 「HTTP エンドポイント URL」で、New Relicのエンドポイント（例：
https://aws-api.newrelic.com/firehose/v1）を選択します。 - 重要：「パラメータ」セクションで、以下のキーと値をそれぞれ追加します。特に
instrumentation.nameは、ログを正しいパーティションにルーティングするために不可欠です。- キー:
instrumentation.name, 値:vpc-flow-logs - キー:
logtype, 値:aws-flowlogs-nr-v1 - キー:
instrumentation.provider, 値:aws-kinesis-firehose
- キー:
- 「API キー」フィールドに、先ほど取得したAPIキーを設定します。
- VPC Flow Logsの有効化とフォーマット設定:
- 監視したいVPCでFlow Logsを有効化し、出力先として作成したAmazon Kinesis Data Firehose を選択します。
- 重要: ログレコード形式で「カスタム形式」を選択します。
- 「ログの形式」のドロップダウンリストから、以下のフィールドをこのリストの順序通りに1つずつ選択・追加してください。この順序がNew Relicでの正しいデータ認識に不可欠です。
選択するフィールドと順序
versionaccount-idregionaz-idsublocation-typevpc-idsubnet-idinstance-idinterface-idsrcaddrpkt-srcaddrpkt-src-aws-servicedstaddrpkt-dstaddrpkt-dst-aws-servicesrcportdstportprotocolpacketsbytesflow-directiontraffic-pathstartendactionlog-status
この設定が完了すると、VPC内の通信データがほぼリアルタイムでNew Relicに Log データとして取り込まれ始めます。これにより、例えば以下のようなNRQLクエリで通信状況を分析できます。
-- 送信元IPアドレス トップ10
SELECT count(*) FROM `Log_VPC_Flows_AWS` FACET srcaddr SINCE 1 hour agoさらに、これらのデータをダッシュボードで可視化することで、「どの送信元から、どの宛先への通信が、許可されたのか、それとも拒否されたのか」を一目で把握できます。特にサンキーチャートを利用すると、意図しない設定によるREJECTを即座に発見するのに役立ちます。
3. GCP VPC Flow Logs を New Relic で可視化する
GCPにも、AWSとほぼ同様の機能である VPC Flow Logs が提供されています。GCPの場合は、ログの転送に Pub/Sub と Cloud Functions を利用するのが一般的です。
設定手順の概要
- VPC Flow Logsの有効化: 監視対象のサブネットでFlow Logsを有効化します。
- ログシンクの作成: Cloud Loggingで、Flow Logsをフィルタリングし、エクスポート先（宛先）として Pub/Subトピック を指定する「シンク」を作成します。
- Cloud Functionsのデプロイ:
- New Relicが提供するGCP向けのログ転送用Functionをデプロイします。
- このFunctionは、指定したPub/Subトピックにメッセージが発行されることをトリガーとして実行されるように設定します。
これにより、GCPのVPC Flow LogsもNew Relicで一元的に分析できるようになります。
4. まとめ：クラウドネイティブな可観測性への第一歩
今回は、AWSとGCPのVPC Flow LogsをNew Relicに取り込み、クラウド上のネットワーク通信を可視化する方法について解説しました。
- クラウドネットワーク監視の鍵は、VPC Flow Logsのようなプラットフォーム固有のデータソースを理解し、それを処理するためのマネージドサービスを使いこなすこと。
- VPC Flow Logsは、クラウドの "新たなブラックボックス" を解明するための最も重要な情報源である。
- AWSでは Amazon Kinesis Data Firehose、GCPでは Pub/Sub と Cloud Functions といったマネージドサービスを活用することで、カスタムコードの管理を最小限に抑え、信頼性の高いデータパイプラインを構築できる。
なお、本記事ではAWSとGCPに焦点を当てましたが、Microsoft Azureにも同様の機能が存在します。 Azureでは従来のNSG Flow Logsから、より高度な分析が可能になった VNetフローログ への移行が進んでいます。このことからも、Flow Logの活用がクラウドネットワークにおける可観測性の共通したアプローチであることがお分かりいただけるかと思います。
物理的なインフラを意識する必要がなくなったからといって、ネットワーク監視が不要になるわけではありません。むしろ、その監視方法はよりクラウドネイティブな形へと進化が求められています。
次回予告: さて、これまで6回にわたり、様々なネットワークデータをNew Relicに集約する方法を学んできました。しかし、データを集めるだけでは可観測性のゴールではありません。次回、第7回【自動化】NRQLとAPIでデータを自在に操る では、収集したデータをプログラムから自由に抽出し、日々の運用やインシデント対応を自動化していくための強力な武器、NRQLとNerdGraph APIの世界へと足を踏み入れます。ご期待ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
