なぜ「VPCフローログ」は障害時の最強の武器になるのか？GCPネットワークの深層を読み解く
現場で夜中に呼び出される障害対応の際、皆さんは何を確認しますか？アプリケーションのログ、ダッシュボードのメトリクス、それも正解です。しかし、ネットワークの「境界」で何が起きているかを知る唯一の、そして最も信頼できる手がかりは、VPCフローログに刻まれています。
今日は、GCPのVPCフローログが吐き出すJSONレコードの裏側にある「パケットの真実」を、現場の視点から紐解いていきましょう。
VPCフローログは「パケットの羅針盤」である
VPCフローログは単なる統計データではありません。これは、GoogleのSDN（Software Defined Network）の奥深くを流れるパケットの「通信履歴」そのものです。何が、どこから、どのポートへ、どれくらいの熱量（Bytes）で向かったのか。この断片を読み解くことができれば、ファイアウォールの設定ミスなのか、それともアプリケーションのタイムアウトなのか、瞬時に見極めることができます。
主要フィールドが物語る「通信の素顔」
まずは、トラブルシューティングで必ず見るべき主要フィールドの定義を、実務的な解釈を加えて解説します。
src_ip/dst_ip: 通信の起点と終点です。これが期待したIPアドレス（NAT GatewayやLoad Balancerなど）と一致しているか確認しましょう。src_port/dst_port: ここでよくある罠は「エフェメラルポート」の枯渇です。dst_portが443ならWeb通信ですが、src_portが高頻度で変わっているか確認することで、接続の確立状況が分かります。proto: プロトコル番号です。6（TCP）、17（UDP）、1（ICMP）が代表的ですが、protoが6なのに通信が通らない場合、ほぼ間違いなくtcp_flagsのトラブルです。tcp_flags: これこそが「通信の握手」の成否を握る鍵です。SYN（接続開始）、ACK（応答）、FIN/RST（切断）の状態をビットマスクで示します。packets/bytes: パケット数とバイト数です。packetsは多いのにbytesが極端に小さい場合、スキャン攻撃やDoSの予兆である可能性があります。
実践：パケットを可視化する準備
VPCフローログを有効にするのは簡単ですが、ただ垂れ流すだけではノイズに埋もれます。まずは、Cloud Logging上で特定の通信をフィルタリングするクエリの例を見てみましょう。
# フィルタ例: 特定のインスタンスへの拒否された通信を追跡する
# Cloud Loggingのクエリビルダーにそのまま貼り付け可能です
resource.type="gce_subnetwork"
jsonPayload.connection.dest_ip="10.128.0.5"
jsonPayload.reporter="DEST"
# 拒否されたパケットだけを抽出
jsonPayload.tcp_flags=0Pythonでフローログを解析する（現場のTips）
蓄積されたフローログをBigQueryにエクスポートし、Pythonで分析するのはSREの定石です。例えば、「特定の dst_port に対して異常なパケットを送っているクライアント」を特定する簡単なロジックを記します。
import pandas as pd
# BigQueryからエクスポートしたログデータを想定
def detect_traffic_anomaly(log_data):
df = pd.DataFrame(log_data)
# 接続先ポートごとのパケット統計を算出
anomaly = df.groupby(['dst_port', 'src_ip']).agg({
'packets': 'sum',
'bytes': 'sum'
})
# パケット数が閾値を超えている怪しいIPを抽出
suspects = anomaly[anomaly['packets'] > 10000]
return suspects
# 実際の現場ではこの後にGCPのファイアウォールAPIを叩いて自動遮断まで繋げますなぜ tcp_flags が重要なのか？
Web API開発をしていると、Connection Reset や 504 Gateway Timeout に悩まされることがあります。この時、VPCフローログの tcp_flags を見ると、RST フラグが立っていることが多々あります。
- 原因: クライアントがタイムアウトで接続を切ったのか、それともバックエンドのサーバーが
keep-aliveの上限に達して強制切断したのか。 - 判断: サーバー側で
FINを送らずにRSTを送っているなら、アプリケーションのソケット処理が異常終了している証拠です。
まとめ：ネットワークを味方につける
VPCフローログは、クラウドネイティブなインフラにおける「黒箱」を透明にする技術です。設定は gcloud コマンド一行で完了します。
# 特定のサブネットでフローログを有効化する例
gcloud compute networks subnets update [サブネット名] \
--region=[リージョン] \
--enable-flow-logs \
--logging-aggregation-interval=standard \
--logging-filter='{"metadata": {"filter": "true"}}' # 必要なログのみに絞るのがコツですログを読み解く力は、一朝一夕には身につきません。しかし、パケットがどう走り、どう消えていくのかをイメージできるエンジニアこそが、真に「可用性の高いシステム」を構築できるのです。
皆さんの設計するシステムが、今日も健やかでありますように。また、障害に当たったときは、焦らずにまずログの proto と tcp_flags から確認してみてください。そこには必ず、解決への糸口が残されています。
コメント