【入門編】 VPCフローログのパケットサンプリング仕様と記録されない通信 – クラウド＆コンテナネットワーク実践ガイド

クラウドの世界へようこそ！SREとして日々パケットの荒波と格闘していると、「なぜか通信が遮断されているのにログには何も出てこない！」という、なんとも胃が痛くなるトラブルに遭遇することがあります。

今日は、そんな時に頼りになるはずの「VPCフローログ」が、実はちょっとした「おっちょこちょい」な側面を持っているというお話をしましょう。

—

郵便配達員さんは、すべての会話を記録しているわけじゃない

VPCフローログを「ネットワーク上の監視カメラ」だと思っていませんか？実は、これ、監視カメラというよりは「街角に立っている郵便調査員さん」に近い存在なんです。

郵便調査員さんは、行き交うすべての封筒の中身をチェックしているわけではありません。彼らは、決められた時間間隔で「お、今この通りを100通の青い封筒が通り過ぎたな」とメモを取るだけなんです。

「サンプリング」という名の妥協

クラウドの世界でも同じです。AWSやGCPのような巨大なクラウド環境では、1秒間に数百万ものパケットが飛び交っています。もし、そのすべてをリアルタイムで1ビット残さず記録しようとしたら、ネットワークのパフォーマンスはガタ落ちし、ログを保存するストレージも一瞬でパンクしてしまうでしょう。

だから、クラウドベンダーは「サンプリング」という手法をとります。

現実の挙動: 「ある一定期間内に通ったパケットをまとめて統計を取る」
デメリット: 非常に短い時間しか存在しない通信や、たまにしか発生しない特殊なパケットは、この「集計作業」の合間をすり抜けてしまい、ログに記録されないことがあるのです。

—

ログが記録してくれない「隠れた住人たち」

「ログに何も出ていないから、通信なんて発生していないはずだ！」と断言するのは、まだ早いです。フローログには、実は「見えない通信」がいくつか存在します。

1. DHCP（IPアドレスの割り当て）

インスタンスが立ち上がる時、最初に「IPアドレスをください！」と叫ぶ通信（DHCP）があります。これはネットワークの根幹を支える通信ですが、多くのクラウド環境において、フローログの監視対象外、あるいは特殊な扱いになっていることがほとんどです。

2. DNSクエリ（名前解決）

「google.com はどこですか？」と聞くDNS通信。これらも、クラウドプロバイダーが用意している内部DNSサービス（AWSなら 169.254.169.253 など）への通信は、フローログに現れないことが一般的です。

3. メタデータサービスへのアクセス

インスタンス自身が「私はどんな設定で動いているの？」とクラウド側に尋ねるための特別な通信も、フローログのフィルターから除外されることが多いのです。

これらは「クラウド基盤を維持するためのインフラ通信」として、ユーザーの通信とは別枠で管理されているからですね。

—

トラブルシューティング：どうやって確認すべき？

では、フローログに頼れない時、私たちはどうすればいいのでしょうか？実務で使えるTipsをいくつかご紹介します。

AWS CLIでログ設定を確認する

まずは、現在のログ設定が「すべて」をキャプチャするように設定されているか確認しましょう。

# 特定のVPCフローログの詳細を取得して確認するコマンド
aws ec2 describe-flow-logs \
    --filter "Name=resource-id,Values=vpc-xxxxxxxxxxxxxxxxx" \
    --query "FlowLogs[*].{ID:FlowLogId,Status:FlowLogStatus,TrafficType:TrafficType}"

パケットキャプチャという「最後の手段」

もしログに何も出ないけれど、どうしても通信の正体を知りたい！という場合は、tcpdump の出番です。ただし、本番環境でやるときは負荷に注意してくださいね。

# eth0インターフェースのパケットをキャプチャしてファイルに保存
# -i: インターフェース指定, -w: ファイル書き出し
sudo tcpdump -i eth0 -w troubleshooting.pcap

—

SREからのアドバイス：完璧を求めすぎない設計を

初学者の皆さんに一番伝えたいのは、「ログはあくまで『手がかり』であって『真実そのもの』ではない」ということです。

インフラを設計する際は、フローログを過信せず、以下のように多重の防御策を考えておきましょう。

1. アプリレベルのログ: アプリケーション自体が出力するアクセスログを信頼する。
2. メトリクスの監視: 通信が「ある・なし」ではなく、コネクション数やレイテンシの「増減」で異変を察知する。
3. セキュリティグループの可視化: ログを見る前に、そもそもその通信が許可されているルール（セキュリティグループ/ファイアウォール）が存在するか、設定ファイルを読み直す。

—

ネットワークの世界は、目に見えないパケットのダンスです。最初はログに踊らされることもあるかもしれませんが、一歩ずつ「何が通っていて、何が見えていないのか」を想像できるようになれば、あなたはもう立派なエンジニアです！

これからも、一緒に泥臭く、かつスマートにトラブルと向き合っていきましょう。次回は「パケットロスが疑われる時の初動対応」について深掘りします。お楽しみに！