VPCフローログは「嘘をつかない」：パケットの深淵を可視化するSREの視点
クラウドネイティブなインフラにおいて、ネットワークは「魔法」ではありません。それは極めて泥臭い、カーネル空間と物理NIC、そしてハイパーバイザー間の物理的な電子のやり取りです。
多くのエンジニアがVPCフローログを単なる「トラフィック統計」と捉えていますが、第一線のSREにとって、それはネットワークパフォーマンスとセキュリティの綻びを特定するための、最も純度の高い観測データです。Google CloudのVPCフローログが吐き出すJSONフォーマットには、TCP/IPスタックの挙動を読み解くためのヒントが圧縮されています。
今回は、このレコードフォーマットを解剖し、単なるログ収集を超えた「ネットワーク・オブザーバビリティ」の極意を紐解いていきましょう。
—
1. パケットの足跡：主要フィールドが語る「接続の真実」
VPCフローログの各フィールドは、OSI参照モデルの第3層から第4層の状態を克明に示しています。特に注目すべきは以下のフィールドです。
src_ip,dst_ip: 通信の起点と終点。ここにはGCP特有の「内部IP」だけでなく、場合によってはGCLB（Google Cloud Load Balancing）のプロキシIPが含まれます。src_port,dst_port: Ephemeral Port（一時ポート）の枯渇問題や、ファイアウォールによるドロップの予兆を掴む鍵です。proto: プロトコル番号（TCPなら6、UDPなら17）。tcp_flags: ここが最大の深淵です。SYN-ACKの往復だけでなく、RST（強制切断）やFINの混入は、アプリケーションのタイムアウトやバックエンドの負荷過多を即座に物語ります。packets,bytes: この比率は、通信効率の指標です。「パケット数は多いがバイト数が極端に少ない」場合、TCPのACKストームや、Keep-Aliveの過剰な試行を疑うべきです。
—
2. パフォーマンスチューニング：RTTとTCPウィンドウの最適化
フローログで packets と bytes の比率を分析すると、MTU（最大転送単位）の不一致によるフラグメンテーションや、TCPウィンドウサイズが適切でないことによる「スループットの頭打ち」が見えてきます。
例えば、レイテンシが想定より高い場合、フローログの bytes を packets で割った値がMTUに近いか確認してください。もし極端に小さい場合、アプリケーション層での「小さなパケットを大量に送る」という非効率な設計が疑われます。
TCPバッファチューニングのヒント
Linuxカーネルのネットワークスタックを触る際は、以下のように sysctl を調整することで、フローログ上の通信効率を劇的に改善できる場合があります。
# TCPウィンドウサイズを拡大し、高レイテンシ環境でのスループットを向上させる
# /etc/sysctl.conf に追記
net.ipv4.tcp_rmem = 4096 87380 16777216 # 受信バッファの最小/デフォルト/最大
net.ipv4.tcp_wmem = 4096 65536 16777216 # 送信バッファの最小/デフォルト/最大
net.core.rmem_max = 16777216 # 受信バッファのOS制限最大値
net.core.wmem_max = 16777216 # 送信バッファのOS制限最大値—
3. セキュリティ：フローログから読み解く攻撃の兆候
セキュリティの観点から最も警戒すべきは、tcp_flags に現れる RST や、異常に短い接続間隔です。
もし特定の src_ip から大量の SYN パケットが特定の dst_port に向かっている場合、それはポートスキャンやDDoSの初期段階である可能性が高いです。また、フローログをBigQueryにエクスポートし、以下のSQLで「接続の異常」を可視化するダッシュボードを構築することは、SREの標準的な防衛術です。
-- 異常な接続終了（RST）の多発を検出するクエリ
SELECT
src_ip,
COUNT(*) as rst_count
FROM
`your_project.vpc_logs.flow_log_table`
WHERE
-- TCPフラグのビットマスクでRST (0x04) を判定
JSON_EXTRACT_SCALAR(tcp_flags, '$.rst') = '1'
GROUP BY
src_ip
HAVING
rst_count > 100 -- 短時間でRSTが多発するIPを抽出
ORDER BY
rst_count DESC;—
4. 極限の最適化：TLSハンドシェイクとRTTの削減
ネットワークアーキテクトとして避けて通れないのが、TLSハンドシェイクによるRTT（Round Trip Time）の増加です。フローログで src_port の変動が激しい場合、クライアントが接続のたびに新規ハンドシェイクを行っている証拠です。
1. Keep-Aliveの徹底: アプリケーション層（HTTP/1.1やgRPC）で接続を再利用する設定を行ってください。
2. TLS 1.3の採用: 1-RTTハンドシェイクにより、従来のTLS 1.2よりも確実にレイテンシを削減できます。
3. Cloud CDN/Load Balancerの最適化: QUIC (HTTP/3) を有効にすることで、UDPベースの多重化を行い、ヘッド・オブ・ライン・ブロッキングを回避します。
—
結論：ログを「知性」に変える
VPCフローログは、単なるテキストの羅列ではありません。それは、あなたのクラウド環境を流れる「血液」の検査結果です。
「なぜこの接続は遅いのか？」「なぜこの接続は途切れるのか？」という疑問に対して、フローログは常に正しい答えを持っています。重要なのは、そのデータをただ溜め込むのではなく、TCPの挙動やOSのネットワークスタックという「物理的な実態」と照らし合わせる、その一歩踏み込んだ知的好奇心です。
次回のメンテナンスウィンドウでは、ぜひこれらのフィールドを深く掘り下げ、あなたのインフラを「動くだけのもの」から「洗練されたシステム」へと昇華させてください。
コメント