GCP VPCフローログの深淵：サンプリングと「見えないパケット」を可視化する技術
クラウドアーキテクトとして多くの大規模システムをレビューしていると、必ずと言っていいほど直面するのが「ネットワークの解像度」という壁です。特にGCPの VPC Flow Logs は、その実装の妙を知らないと、重要なパケットの欠落を「正常」だと誤認させかねない諸刃の剣です。
今回は、単なるログ収集ツールの設定を超え、カーネルレベルの挙動とパケットの行方にまで踏み込んで、この機能を極限まで使いこなすための勘所を語ります。
—
1. ログ生成のメカニズム：なぜ「すべて」ではないのか
まず前提として、VPC Flow Logs はパケットキャプチャ（PCAP）ではありません。これは、GoogleのSDN（Software Defined Network）のデータプレーンである Andromeda が、接続のメタデータをサンプリングして集約するプロセスです。
ここで重要なのは、「ログ生成はカーネルのフィルタリングではなく、仮想スイッチ層での統計処理である」という点です。
サンプリングレートの正体
設定項目である aggregation_interval と sampling_rate は、ログのコストと精度を決定づけるパラメータですが、ここには見落とされがちな「集約」の罠があります。
sampling_rate(0.0 – 1.0): どの程度のパケットがログとして処理されるか。例えば0.5に設定した場合、統計的に50%のトラフィックが無視されます。本番環境でセキュリティ監査を目的とするならば、この値は可能な限り1.0に寄せるのが定石です。aggregation_interval(5s – 15m): ログがフラッシュされるまでの時間です。短すぎるとログが肥大化し、長すぎると「今まさに起きている攻撃」の追跡が遅延します。通常は5s程度が妥当ですが、高負荷なマイクロサービス間通信では、集約の粒度を調整しないとCloud Loggingのコストが爆発します。
—
2. 現場で役立つVPCフローログの最適化設定
以下の gcloud コマンド例は、特定のサブネットに対して「精度」と「コスト」のバランスを最適化した設定です。
# 特定のサブネットに対してフローログを詳細設定で有効化
gcloud compute networks subnets update [SUBNET_NAME] \
--region=[REGION] \
--enable-flow-logs \
--logging-aggregation-interval=INTERVAL_5_SEC \
--logging-flow-sampling=1.0 \ # 100%サンプリングで欠落を排除
--logging-metadata=INCLUDE_ALL # TCPフラグやRTT情報を含めるここで --logging-metadata=INCLUDE_ALL を指定することが、プロフェッショナルには必須です。これを含めることで、tcp_flags や rtt_nanos が記録され、TCPハンドシェイクの遅延や、再送によるRTTの増大といった「ネットワークの健康状態」を定量的に測定可能になります。
—
3. パケットの行方とTCPバッファのチューニング
ネットワークのパフォーマンスを語る上で、VPC Flow Logs が記録する rtt_nanos は宝の山です。これが急激に上昇している場合、問題はアプリコードではなく、多くの場合「TCPウィンドウサイズ」の枯渇にあります。
もし、高いRTTが観測されているなら、Linuxカーネルの sysctl チューニングを検討してください。
# /etc/sysctl.conf に追記してTCP通信を最適化
# 大規模なスループットを維持するための最大バッファ設定
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 設定を反映
sysctl -pこのチューニングにより、フローログ上で観測される「パケット再送」や「ウィンドウフルによる遅延」を劇的に改善できる可能性があります。
—
4. セキュリティと脆弱性回避の視点
セキュリティの観点では、VPC Flow Logs は「侵入検知の最後の砦」です。特に、TLSハンドシェイクが完了する前の SYN パケットの大量発生は、SYNフラッド攻撃のサインです。
ログの jsonPayload.connection.protocol が 6 (TCP) で、かつ tcp_flags に SYN フラグのみが異常に多く立っている場合、Cloud Armor の設定を見直すべきタイミングです。
賢いSREはログをこう見る
単にログを溜め込むだけでなく、BigQuery へシンクし、以下のクエリで「不審な長時間コネクション」を抽出してください。
-- TCPセッションの持続時間が長い通信を抽出（攻撃やスキャン検知）
SELECT
src_instance.vm_name,
src_ip,
dest_ip,
JSON_EXTRACT_SCALAR(json_payload, '$.connection.dest_port') as port,
TIMESTAMP_DIFF(end_time, start_time, SECOND) as duration
FROM
`your-project.your_dataset.cloudaudit_googleapis_com_vpc_flows`
WHERE
TIMESTAMP_DIFF(end_time, start_time, SECOND) > 3600 -- 1時間以上続く通信
ORDER BY duration DESC—
まとめ：ネットワークは嘘をつかない
VPCフローログは、単なるテキストの羅列ではありません。そこには、分散システムの中を駆け巡るパケットの鼓動が刻まれています。
1. sampling_rate は 1.0 に。 異常検知には情報の欠落が最大の敵です。
2. metadata を活用せよ。 RTTとTCPフラグこそが、ネットワーク遅延の犯人を特定する鍵です。
3. カーネルと同期せよ。 ネットワークの遅延はアプリからログへと伝播します。
インフラアーキテクトとして最も重要なのは、「ログを見ている」ではなく「パケットの挙動を予測し、その予測がログと一致するかを確認する」という姿勢です。この深い洞察こそが、堅牢なクラウドインフラを支える唯一の道なのです。
コメント