【応用①】Flow分析で通信の"犯人"を探す｜ネットワーク可観測性エンジニアへの道

【応用①】Flow分析で通信の"犯人"を探す

この記事では、「ネットワークが重い」といった漠然とした問題の真の原因を突き止めるための強力な手法であるFlow分析の理論について解説します。

これまでの連載で、私たちはPingとSNMPを使ってネットワーク機器の「健康状態」を把握し、Syslogから機器の「つぶやき」を聞く方法を学びました。これらは、いわばネットワークの定期健診です。しかし、もし健診で「血圧が高い（＝ネットワークの帯域使用率が高い）」という結果が出たとき、その原因が「食べ過ぎ（＝特定のアプリケーションの過剰な通信）」なのか「運動不足（＝不要なバックアップトラフィック）」なのか、根本的な原因までを特定するのは難しいのではないでしょうか。

SNMPでは、インターフェースを通過する通信の「総量」はわかります。しかし、「誰が、どのアプリケーションで、誰と通信した結果、その総量になっているのか」という内訳までは知ることができません。この「なぜ？」に答えるための技術が、今回ご紹介するFlow分析です。

Flow分析とは？ネットワークの「交通量調査」

Flow分析を理解する最も簡単な方法は、道路の「交通量調査」をイメージすることです。

交通量調査では、調査員が「いつ、どんな種類の車が、どこから来てどこへ向かったか」を記録します。これにより、特定の時間帯になぜ渋滞が発生するのか、その原因が大型トラックの集中なのか、あるいは特定の交差点へ向かう乗用車の増加なのか、といった詳細な分析が可能になります。

Flow分析は、この交通量調査をネットワークの世界で行うものです。ルーターやスイッチといったネットワーク機器が「調査員」となり、そこを通過する通信（パケット）の特性を記録します。この記録された一連の通信情報が「フローレコード」と呼ばれます。

具体的には、一般的に以下の情報が同じ通信の「フロー」としてまとめられます。

• 送信元IPアドレス
• 宛先IPアドレス
• 送信元ポート番号
• 宛先ポート番号
• プロトコル番号 (TCP/UDPなど)
• Ingressインターフェース (どのインターフェースから入ってきたか)

これらの情報を持つフローレコードを大量に収集し、分析することで、「いつ、誰（どのIPアドレス）が、どのアプリケーション（ポート番号）を使い、誰と、どれくらいの量の通信をしていたのか」を手に取るように把握できるようになるのです。

なぜ今、Flow分析が重要なのか？

なぜ、SNMPによる量的な監視だけでは不十分なのでしょうか。それは、現代のネットワークにおける問題が、より複雑化しているからです。

• 問題①：原因不明の帯域逼迫
  • SNMPの限界: インターフェースの帯域使用率が90%であることはわかります。しかし、その90%のうち、50%が業務用のビデオ会議で、残りの40%が特定の社員による大容量ファイルのダウンロードだった、という内訳まではわかりません。
  • Flow分析の価値: Flow分析を行えば、「誰の」「どの通信が」帯域を圧迫しているのかを正確に特定できます。これにより、不要な通信の制限や、帯域の増強といった具体的な対策を、根拠を持って判断できるようになります。
• 問題②：アプリケーションパフォーマンスの低下
  • SNMPの限界: あるアプリケーションサーバーへのPing応答時間は正常で、サーバー自体のCPUやメモリ使用率も問題ない。しかし、ユーザーからは「アプリケーションが遅い」という声が上がっています。
  • Flow分析の価値: Flow分析でアプリケーションサーバーとクライアント間の通信を調べれば、特定のデータベースへのクエリ応答に時間がかかっている、あるいは特定のAPIコールが頻発している、といったネットワークレベルでのボトルネックを発見できる可能性があります。
• 問題③：不審な通信の検知（セキュリティ）
  • SNMPの限界: ネットワーク全体のトラフィック量が増加していることはわかりますが、それが外部からの攻撃の予兆なのか、内部のマルウェア感染によるものなのかを判断することはできません。
  • Flow分析の価値: 通常では見られない国への通信や、不審なポートを使った通信が大量に発生していることを検知できます。これは、セキュリティインシデントの早期発見に直結する重要な情報となります。

このように、Flow分析は、パフォーマンス問題の解決からセキュリティインシデントの調査まで、幅広い用途でその真価を発揮します。「ネットワークが重い」という漠然とした課題に対して、「犯人」を特定するための最も強力な捜査手法の一つと言えるでしょう。

Flow分析の仕組み

Flow分析は、主に3つのコンポーネントで構成されます。

1. Exporter (エクスポーター)
   • 役割: ネットワークトラフィックを監視し、フローレコードを生成して送信する機器。
   • 具体例: ルーター、L3スイッチ、ファイアウォールなど。
2. Collector (コレクター)
   • 役割: Exporterから送られてくるフローレコードを受信し、ストレージに保存するサーバー。
   • 具体例: New Relicのktranslateエージェントなどがこの役割を担います。
3. Analyzer (アナライザー)
   • 役割: Collectorが収集した膨大なフローデータを分析し、人間が理解しやすいようにグラフや表の形で可視化するツール。
   • 具体例: New Relicプラットフォームがこれにあたります。

このExporter → Collector → Analyzerという一連の流れを構築することが、Flow分析の第一歩となります。

【コラム】NetFlow, sFlow, IPFIX - それぞれの違いとは？

さて、Flow分析の仕組みは理解できましたが、Exporterがフロー情報を送信する際のプロトコルには、NetFlow v5, NetFlow v9, sFlow, IPFIXなど、いくつかの種類が存在します。New Relicのktranslateエージェントはこれら主要なプロトコルに全て対応していますが、それぞれの特徴を知ることで、より適切な技術選定が可能になります。

これらの違いを理解する鍵は、「どのようにデータを集め（収集方式）」「どのような形式で送るか（送信形式）」という2つの視点で捉えることです。

NetFlow/IPFIX: 全パケットを監視し、フロー情報に集約する

NetFlowとIPFIXは、ルーターなどの機器が通過する全てのパケットを監視し、送信元/宛先IPやポート番号などが同じ通信を一つの「フロー」としてメモリー（キャッシュ）上で統計情報にまとめます。そして、その集約されたフロー統計情報（フローの開始/終了時刻、総バイト数など）を定期的にコレクターへ送信します。

• NetFlow v5: 送信形式が固定です。IPv4の情報しか含められず、現代のネットワークでは機能不足となる場面があります。
• NetFlow v9 / IPFIX: 送信形式がテンプレートベースで、非常に柔軟です。IPv6、VLAN-ID、MPLSラベルといった多様な情報を自由に定義して送信できます。IPFIXはNetFlow v9を元にIETFが標準化した、より汎用性の高いプロトコルです。

sFlow: パケットを「サンプリング」して送信する

sFlowはアプローチが根本的に異なります。パケットを全て監視するのではなく、一定の割合でランダムに抽出（サンプリング）します。そして、その抽出したパケットのヘッダー情報そのものを、ほぼリアルタイムでコレクターへ送信します。機器の負荷が低いのが最大のメリットですが、あくまでサンプルであるため精度は統計的なものになります。

これらのプロトコルに優劣はなく、監視対象の機器が何に対応しているか、そしてトラフィックの正確性と機器負荷のどちらを優先するかといった目的によって、最適な選択は異なります。New Relicのように、これら複数の方式に一台のktranslateエージェントで対応できることは、多様なネットワーク環境を統合的に可視化する上で、非常に大きな強みとなるのです。

【深掘りコラム】なぜベンダーはNetFlow/IPFIXを活用するのか？

さて、ここで少し視点を変えてみましょう。New Relicのktranslateエージェントは、実はCisco ASAのNSEL、CiscoのNBAR、Palo AltoのApp-IDといった、各ベンダー独自の高度なフロー情報にも対応しています。なぜベンダーは独自のプロトコルを作らず、NetFlow/IPFIXの仕組みを活用するのでしょうか。

結論から言うと、それはNetFlow v9/IPFIXが持つ「テンプレートによる圧倒的な拡張性」を活かし、自社製品の強みである高度な情報を付加価値として提供するためです。

Cisco ASA: フローで「セキュリティイベント」を通知する

ファイアウォールであるCisco ASAは、一般的なトラフィック量を報告するのではなく、NSEL (NetFlow Security Event Logging) という仕組みを使います。これはNetFlow v9のフレームワークを利用し、「コネクションが作成された」「通信が拒否された」といったファイアウォールならではのセキュリティイベントを通知するためのものです。同じNetFlow v9という報告形式を使いながら、報告する中身（目的）を全く異なるものに特化させている好例です。

Cisco NBAR: フローに「アプリケーション名」を付与する

NBAR (Network Based Application Recognition) は、通信内容を解析し、それが何のアプリケーション（例: "Microsoft 365", "YouTube"）であるかを識別するエンジンです。NBAR自体はプロトコルではありません。NBARは、識別したアプリケーション名をNetFlowの追加項目としてフローレコードに書き込むことで、単なるIPアドレスの羅列だった通信記録を、「誰が何のアプリケーションで通信しているか」というレベルまでリッチにします。

Palo Alto App-ID: フローに「ユーザー名」や「脅威情報」を付与する

Palo Altoのファイアウォールも同様です。その強力な識別能力（App-IDやUser-ID）によって得られた「どのユーザーが」「どのアプリケーションを」使っているか、といった情報を、NetFlow v9のテンプレートを拡張してエクスポートします。これにより、コレクター側では、より具体的でアクションに繋がりやすい分析が可能になるのです。

拡張性を利用した「付加価値」競争

このように、各ベンダーはゼロから独自プロトコルを開発するのではなく、標準化され普及したNetFlow/IPFIXという「共通言語」の上で、いかに独自の「方言（＝付加価値情報）」を乗せるかを競っています。

これは、連載コンセプトである「SNMPの限界」と「ベンダーのAPI戦略」という流れとも合致します。各ベンダーは、基本的な接続情報だけでなく、自社のプラットフォームが解析した高度な情報をいかに外部に提供できるかで差別化を図ろうとしており、そのための手段としてNetFlow/IPFIXの拡張性が活用されているのです。

おわりに

今回は、応用編の第一弾として、Flow分析の「理論」に焦点を当てました。

• Flow分析は、ネットワーク上の「誰が、何を、誰と」通信しているかを明らかにする技術です。
• SNMPではわからない通信の「質」を分析することで、帯域逼迫の真犯人を特定できます。
• パフォーマンス問題の解決だけでなく、セキュリティ対策にも応用が可能です。

しかし、理論を学んだだけでは、漠然とした課題を解決することはできません。本当の力は、実際に自分の手でデータを触ってこそ身につくものです。

次回は、いよいよ実践編です。今回学んだ理論をベースに、実際にFlow分析ツール（New Relic）を導入し、ネットワークを流れる通信を "見える化" するまでの一連の手順を、ハンズオン形式で体験します。ご期待ください。