こんにちは！クラウドの海原で、目に見えないパケットの奔流に頭を抱えていませんか？
「マイクロサービス化を進めたのはいいけれど、サービスAからサービスBへの通信がなぜかたまにタイムアウトする……」
「Kubernetesクラスターの中で、一体どのPodとどのPodが裏でトラフィックを食い合っているんだ？」
夜中にこんな障害アラートが飛んできて、AWSのVPCフローログの海に溺れかけた経験、あなたにもあるのではないでしょうか。テキストの羅列からIPアドレスを目で追いかけ、タイムスタンプを突き合わせる作業は、もはや「監視」ではなく「苦行」です。
今回は、そんな泥臭いネットワークのトラブルシューティングを過去のものにする、Datadogの秘密兵器「Network Performance Monitoring (NPM)」についてお話しします。
これをマスターすれば、カオスなクラウドネイティブ環境の通信が「ひと目でわかる地図」になり、毎日の運用作業が劇的に楽になりますよ。さあ、一緒に扉を開けましょう。
—
1. なぜ従来の監視ではマイクロサービスを救えないのか？
まず、私たちが直面している敵の正体を整理しましょう。
モダンなインフラ、特にKubernetesやコンテナベースの環境では、仮想IP、Service Mesh、ロードバランサー、Ingressなどが複雑に絡み合っています。ここで問題が起きるたびによく使われるのが「VPCフローログ」です。
しかし、VPCフローログには以下の「3つの罪」があります。
1. 情報量が多すぎてノイズまみれ（パケットの羅列で、アプリケーションの文脈が全く見えない）
2. コストが高い（全トラフィックを保存・解析しようとすると、AWSの請求書を見て冷や汗をかくことになる）
3. リアルタイム性がない（S3やLog Group経由で見ると、インシデント発生時の「今」の通信状態が掴めない）
ここで登場するのが Datadog NPM です。NPMは、カーネルレベル（eBPFなどの技術）でネットワークの通信をキャプチャし、「どのサービスから、どのサービスへ、どれだけのレイテンシーとパケットロスで通信しているか」をアプリケーションのコンテキスト（サービス名やPod名）と紐づけて可視化してくれます。
つまり、「IPアドレスのパズル」を解く必要がなくなるのです。
—
2. Datadog NPMの全体像と仕組み
Datadog NPMを語る上で欠かせないのが、Datadog Agent です。
従来のプロセス監視やメトリクス収集に加え、NPMを有効化したAgentは、ホストのネットワークスタックを監視します。
AWSなどのクラウド環境であれば、VPCフローログに頼るのではなく、各ノード（仮想マシンやK8sワーカーノード）の上で動くエージェントが直接トラフィックを計測します。これにより、クラウドベンダーのログ基盤を通さない、超低遅延で高精度なトポロジーマップが描けるようになります。
—
3. 実践：最短でNPMをセットアップする（HelloWorld）
「難しそうな設定が必要なのでは？」と思うかもしれませんが、ご安心ください。Datadogの美しさは、その圧倒的な導入のしやすさにあります。
ここでは、最も一般的な Kubernetes (Helm) 環境 をベースに、NPMを有効化する手順を解説します。
ステップ1: Helm Valuesの修正
Datadog Agentをデプロイしている `values.yaml` を開きます。ここで、NPMの収集機能（`system_probe`）を有効にするのがポイントです。
datadog-values.yaml
datadog:
apiKey: “
site: “datadoghq.com” # 契約しているリージョンに合わせて変更
# Network Performance Monitoring を有効化
networkMonitoring:
enabled: true
# eBPFを利用したシステムプローブを有効化（これがNPMの心臓部です）
systemProbe:
enabled: true
# コネクション追跡を有効にする
conntrackEnabled: true
DaemonSetとして動作させ、全ノードでパケットをキャプチャする
agents:
enabled: true
ステップ2: Helmでデプロイ・アップデート
設定ファイルを保存したら、Helmコマンドでクラスタに適用します。
helm repo update
helm upgrade datadog-agent datadog/datadog \
-f datadog-values.yaml
たったこれだけです。これだけで、Datadog Agentは各ノードのカーネルレベルで通信の監視を始めます。
—
4. 動作確認：トラフィックマップで世界が変わる瞬間を体験する
エージェントが起動して数分待ったら、いよいよDatadogのUIを覗いてみましょう。
1. Datadogのダッシュボードメニューから [Network] -> [Network Analytics] または [Service Map] を開きます。
2. フィルターで `env:production` や `service:frontend` などを指定してみましょう。
そこには、私たちが頭の中で想像していた「マイクロサービスの通信相関図」が、リアルタイムにアニメーションとして描かれているはずです。
🔍 現場で役立つ！ボトルネック特定のユースケース
ここで、NPMを使った極上のトラブルシューティングシナリオを一つご紹介します。
- シチュエーション: 「Checkout（決済）サービスから、Databaseへのレイテンシーが悪化している」というアラートを検知。
- NPMでのアプローチ:
1. DatadogのNetwork Mapで `checkout` サービスをクリック。
2. 接続先である `database` へのエッジ（線）をクリックすると、TCP再送率（TCP Retransmits）やラウンドトリップタイム（RTT）がグラフで表示されます。
3. もし「TCP再送率」が跳ね上がっていれば、アプリケーションのバグではなく、ネットワーク層（セキュリティグループの設定ミスや、ENIの帯域制限、パケットドロップ）が原因であると一発で特定できます。
わざわざインフラエンジニアに「ネットワークの調子どうですか？」とチャットを投げなくても、NPMの画面を見せるだけで「ここ、再送率が5%を超えてるので、ルーター側のバッファかセキュリティグループを当たりましょう」と秒速で回答できるようになります。この瞬間、あなたはチームのヒーローです。
—
5. 先輩エンジニアからのアドバイス：運用上の注意点
最後に、現場でNPMを運用する上での「知恵」をいくつか授けておきます。
- カーネルバージョンの確認: eBPFをフル活用するため、Linuxカーネルはなるべく新しいもの（理想はLinux 4.14以上、できれば5.x系以降）を推奨します。古いカーネルだと一部の高度なメトリクスが取れないことがあります。
- コスト管理: NPMはホスト単位のライセンス体系であることが多いです。開発環境すべてに入れるとコストが膨らむため、まずは「本番環境（Production）」の主要なクラスターから導入し、効果を実感してから横展開するのがスマートなやり方です。
—
まとめ
Datadog Network Performance Monitoring (NPM) は、単なる「ネットワークの監視ツール」ではありません。それは、複雑怪奇なクラウドネイティブの迷宮を照らす羅針盤です。
インフラとアプリの境界線を溶かし、トラブルシューティングの時間を数時間から数秒に縮めてくれるこのツールを導入すれば、あなたの毎日の運用作業は劇的に楽になります。
さあ、今すぐHelmチャートを書き換えて、あなたのシステムの「本当の姿」を覗きに行きましょう！