GCP VPCフローログを制する者は、クラウドの「真実」を制する —— サンプリングと集約の深淵
エンジニアの皆さん、こんにちは。夜中の3時にアラートで叩き起こされ、原因不明のパケットロスを追ってVPCの深淵を彷徨った経験はありますか？
AWSのVPC Flow Logsに慣れ親しんだエンジニアがGCP（Google Cloud）に触れたとき、最初に驚くのがその「精緻さと大胆さの同居」です。GCPのVPCフローログは、単なる通信記録ではありません。適切に設定すれば、ネットワークの「鼓動」を可視化する強力な武器になります。
しかし、デフォルト設定のまま運用するのは、暗闇でヘッドライトを消して走るようなもの。今回は、実務で絶対に外せないVPCフローログの生成条件と、サンプリングレートの最適解について、現場の知見を込めて解説します。
—
1. VPCフローログは「いつ」生まれるのか？
VPCフローログは、VMインスタンスのネットワークインターフェース（NIC）を通過するIPトラフィックのサンプルを記録します。ここで重要なのは、「ログはパケットそのものではなく、フロー（流れ）の要約である」という点です。
フローログが生成される条件は、主に以下の3点です。
1. 接続の確立/終了: TCP接続の開始や終了（SYN/FINパケットの検知）。
2. 集約間隔（Aggregation Interval）の満了: 接続が継続している場合、一定時間ごとに「これだけ通信しました」という中間報告が生成されます。
3. サンプリングレートの適用: 全パケットを記録するとログコストが爆発するため、トラフィックの一部を間引いて記録します。
現場の教訓：なぜ「全量」ではないのか
「全パケットをログに取れば完璧なデバッグができるのでは？」と考えがちですが、それはコストとパフォーマンスの自殺行為です。数万件のコネクションを捌くAPIサーバーで全ログを有効にすれば、Cloud Loggingの課金はあっという間に青天井。だからこそ、サンプリングの概念を理解することが不可欠なのです。
—
2. サンプリングと集約を制御する「3つの鍵」
VPCフローログを設定する際、以下の3つのパラメータが運命を分けます。
① サンプリングレート (aggregation_interval との兼ね合い)
0.0 から 1.0 の範囲で指定します。例えば 0.1 に設定すると、トラフィックの10%がサンプリングされます。
- 低トラフィック環境:
1.0（全量）でも許容可能。 - 高トラフィック環境:
0.01〜0.1程度に絞り、統計的に傾向を掴むのが定石です。
② 集約間隔 (aggregation_interval)
ログを何秒ごとに集計して出力するか。
- デフォルトの
5sは、リアルタイムに近い監視が必要な場合向け。 - ログのボリュームを抑えたい場合は
15minなどの長めの設定を検討しましょう。
③ メタデータの追加
metadata=INCLUDE_ALL を設定すると、TCPフラグやRTT（往復遅延時間）などの「泣くほどありがたい」情報が付与されます。ネットワークのレイテンシ問題を追うときは、これがなければ始まりません。
—
3. 実践：Terraformによる設定例
口で説明するより、コードを見せたほうが早いでしょう。以下は、実務で推奨する「可観測性とコストのバランス」を重視したTerraformの設定例です。
resource "google_compute_subnetwork" "prod_subnet" {
name = "prod-network-subnet"
ip_cidr_range = "10.0.0.0/24"
network = google_compute_network.vpc_network.id
# フローログの有効化
log_config {
aggregation_interval = "INTERVAL_15_MIN" # 15分間隔で集約（コスト抑制）
flow_sampling = 0.5 # 50%をサンプリング
metadata = "INCLUDE_ALL" # RTT等を含めて詳細を記録
}
}—
4. 現場でのトラブルシューティング：パケットを追跡する
ログがCloud Loggingに溜まり始めたら、BigQueryにエクスポートして解析するのがプロの作法です。以下は、特定のWeb APIに対するレイテンシの異常値をPython（BigQuery Client）で簡易チェックするイメージです。
from google.cloud import bigquery
# クエリ：特定の送信元から、高レイテンシな通信を抽出する
query = """
SELECT
json_payload.connection.src_ip,
json_payload.rtt_ms,
timestamp
FROM `your-project.your_dataset.vpc_flows_*`
WHERE json_payload.rtt_ms > 100 -- 100ms以上の遅延があるもの
ORDER BY timestamp DESC
LIMIT 100
"""
client = bigquery.Client()
query_job = client.query(query)
for row in query_job:
print(f"Source: {row.src_ip}, RTT: {row.rtt_ms}ms")—
最後に：ネットワークを「直感」で捉えるな
ネットワークのトラブルは、往々にして「設定ミス」ではなく「想定外のトラフィックパターン」によって引き起こされます。
- サンプリングレートを下げすぎない: 異常の予兆を見逃すリスクとトレードオフです。
- メタデータを活用せよ:
rtt_msは、アプリケーションの不調が「サーバー由来」なのか「ネットワーク由来」なのかを切り分ける魔法の数字です。
GCPのVPCフローログは、設定して終わりではありません。定期的にBigQueryで集計し、トラフィックのベースラインを把握しておくこと。それこそが、何かが起きたときに「いつもの通信と何が違うのか」を一瞬で見抜く、一流のSREの仕事術なのです。
皆さんのインフラに、平穏と可観測性がもたらされることを願っています。それでは、また次回の深掘りでお会いしましょう。
コメント