📊 Deep Dive — Network Intelligence Center / Flow Logs / Monitoring 運用

「ネットワーク observability は logs/metrics 量を制御しないとコストが爆発する」が定説。実運用で踏むパターン + SRE の常識を集約。

🚨 重大事故ケース 10 件

#1 「VPC Flow Logs を全 subnet で 100% sampling、Logging cost が月 $50,000」

状況: セキュリティチームが「全 traffic を保存したい」と全 subnet で logging-flow-sampling=1.0 + 5 秒 aggregation。1 ヶ月で Cloud Logging ingestion fee が $50,000。

原因: Flow Logs は ingest size 課金 ($0.50/GB)。100% sampling は通常 10% の 10倍のログ量。

影響: 予算超過、CFO から SRE に問合せ。

復旧: production subnet は 50%, dev は 5% に sampling 調整。Cloud Logging exclusion filter で不要 record 削除。

再発防止:

  • Flow Logs は sampling rate と aggregation intervalを必ず明示
  • BigQuery sink にして、Cloud Logging は短期 (30 日) のみ
  • Cost Explorer で Logging cost を週次レビュー

#2 「Network Analyzer の findings を全部無視、suboptimal 構成が積み上がる」

状況: Network Analyzer が「BGP MD5 keys に弱い暗号」「Cloud NAT port 不足傾向」などの findings を提示するが、誰も見ていない。半年後に複数事故が連鎖発生。

原因: Network Analyzer は API でしか自動取得できない、UI を能動的に見ないと気付かない。

影響: 予防可能だった事故 4 件発生、root cause analysis でこのツールが既に warn していたことが判明。

復旧: Network Analyzer findings を毎週 BigQuery export + Looker Studio で可視化、SRE 週次 review に。

再発防止:

  • Network Analyzer findings を API で自動取得 → ticket 起票
  • HIGH severity finding は SLA で 1 週間以内対応
  • Org 単位の findings dashboard を作成

#3 「Connectivity Tests を実 traffic 発生中に大量実行、quota 枯渇」

状況: ある障害対応で、SRE 全員が手動で Connectivity Tests を実行。プロジェクト quota (1000/day) を超過、tests が rate limit。

原因: Connectivity Tests は 1 test = 1 API call、組織で乱発すると quota 枯渇。

影響: 障害調査が遅延、根本原因特定に 2 時間追加。

復旧: 1 人が代表で実行、結果を全員で共有するワークフローに。

再発防止:

  • Connectivity Tests の実行を incident channel に集約
  • 定期 health check (毎時) を IaC で構築し、ad-hoc 実行を減らす
  • quota 緩和申請

#4 「Cloud Monitoring の uptime check が global で過剰課金」

状況: 100 endpoint × 6 region × 1 min interval = 60万 check/day。月 $600。実は 1 min interval は不要。

原因: uptime check は endpoint × region × frequency で課金 (1M check で $0.30 程度)。"念のため 1min" が積み重なる。

影響: Monitoring cost が想定外の $600/月。

復旧: Critical endpoint のみ 1 min、その他は 5-15 min に。

再発防止:

  • uptime check は SLO に基づき頻度を決定 (99.9% SLO なら 5 min で十分)
  • region 数も 3 に絞る (global redundancy を見るためだけ)

#5 「Packet Mirroring を本番で常時 ON、コレクタ ILB がパンク」

状況: セキュリティ要件で全 subnet を mirror 有効化。コレクタ ILB の backend (Cloud IDS) が CPU 100%、半数のミラーパケットが drop。

原因: Packet Mirroring は 完全コピーのため、subnet traffic が 2 倍に。コレクタ側の処理能力が追いつかず。

影響: IDS の検知が遅延、また mirror がプロダクション NW にも影響 (waste of bandwidth)。

復旧: mirror filter で tcp,80,443 など protocol/port 絞り込み。Cloud IDS backend を scale up。

再発防止:

  • Packet Mirroring は 必要最小限の subnet/protocolのみに
  • コレクタ容量を実 traffic の 2 倍で planning
  • Mirror traffic を VPC Flow Logs と組合せず、重複監視を防ぐ

#6 「Cloud Logging exclusion filter ミスで Audit log まで除外」

状況: Flow Logs cost 削減で exclusion filter を作ったら、誤って Admin Activity Audit Log も除外。3 ヶ月後 SOC2 audit で「監査証跡なし」と指摘。

原因: Exclusion filter の絞り込みが甘く、logName:flow-logs ではなく logName=~".*log.*" のような broad match。

影響: Compliance violation、過去 3 ヶ月分の audit log 再構成不能。

復旧: Exclusion filter を厳密化、Admin Activity は必ず保持。

再発防止:

  • Exclusion filter は 必ず logName で厳密 match
  • Admin Activity / Data Access audit log は exclusion 禁止 Org Policy
  • Logging sink を audit/operational で分離

#7 「Performance Dashboard で Google 側障害を見落とし、自社問題と誤認」

状況: アジア圏で p99 latency 急増、SRE は自社 backend をスケールアップ。実は Google の us-central1 ↔ asia-east1 区間で transient packet loss。

原因: Performance Dashboard を活用していなかった。Google-wide vs project-scoped の latency 切り分けができていない。

影響: 不要な scale up でコスト増 ($800/日)、根本原因特定遅延。

復旧: Performance Dashboard を確認し Google 側問題と特定。Google Cloud Support に case 開設。

再発防止:

  • Latency 急増時は 必ず Performance Dashboard を最初に確認
  • Runbook の冒頭に "Google 側 vs 自分側" 切り分け step を明記
  • Google Cloud Status Dashboard を Slack 通知

#8 「Cloud Logging から BigQuery export しているが、schema 変更で query 壊れる」

状況: Cloud Logging が log schema を更新 (新フィールド追加)。BigQuery export 先のテーブルで partition mismatch、ダッシュボードが壊れる。

原因: Cloud Logging の sink は schema 自動進化するが、既存テーブルの query が新 schema 対応していない。

影響: SRE dashboard が一晩使えず、incident triage が遅延。

復旧: BigQuery view で schema 互換性を吸収、ダッシュボード復旧。

再発防止:

  • BigQuery view 層で schema 抽象化
  • Cloud Logging release notes を購読、schema 変更を事前把握
  • End-to-end ダッシュボードの synthetic test を CI に

#9 「Cloud Monitoring の MQL クエリで policy 評価が高頻度、API quota 枯渇」

状況: 高頻度評価 (10s) の alert policy を 100 個追加。Cloud Monitoring API rate limit に到達、alert 評価が遅延。

原因: MQL ベース alert は per-query API quota がある。複雑な MQL の高頻度評価は cost 高。

影響: 重要 alert が遅延通知、incident response 遅延。

復旧: 評価頻度を 60s に下げ、MQL を simplify。

再発防止:

  • Alert policy 評価頻度は SLI 重要度で決定 (page なら 30s、それ以外 60s+)
  • MQL は pre-aggregate (Recording rule 的に) して軽量化
  • quota dashboard を SRE で monitor

#10 「Network Topology で見えない traffic 経路が実は問題の本体」

状況: Network Topology を信じて分析、ある GKE → 外部 API 経由のトラフィックが「見えない」。実はそれが大量に流れて egress cost を爆発させていた。

原因: Network Topology は VPC Flow Logs が有効な subnet のみ表示。Flow Logs 無効化されている dev subnet は見えない。

影響: 月 $5,000 の egress を半年見落とし。

復旧: 全 subnet で Flow Logs 有効化 (低 sampling)。

再発防止:

  • 本番 subnet は必ず Flow Logs 有効化、dev でも 1-5% sampling
  • egress 統計を Billing から逆引きでクロスチェック
  • Network Topology の "blind spot" を意識

💰 Observability のコスト構造

Cloud Logging

項目単価
Ingestion最初の 50 GB/月 無料、以降 $0.50/GB
Retention > 30 days$0.01/GB/月
BigQuery export無料 (BigQuery 側で storage 課金)
PubSub exportPubSub 課金

Cloud Monitoring

項目単価
Chargeable metrics (custom + non-GCP)最初 150 MB 無料、以降 $0.2580/MB
API calls1M 無料/月、以降 $0.01/1K calls
Uptime check$0.30/1M executions
SLO definition無料

VPC Flow Logs / Packet Mirroring

Flow Logs 自体は無料、保存先 Cloud Logging が ingest 課金。Packet Mirroring もリソース料金は無料、コレクタ ILB と保存先で課金。

Network Intelligence Center

Network Topology, Connectivity Tests (10/project/day 無料、超過 $0.40/test), Performance Dashboard, Firewall Insights, Network Analyzer は基本無料 (一部 advanced 機能で課金あり)。

📈 コスト肥大化パターン 6 種

P1

Flow Logs 100% sampling

全 subnet で full sampling、Logging cost 月 $50,000 級。

P2

Logging retention 過剰

365 day retention で $0.01/GB/month が積み重なる。BigQuery long-term storage の方が安い。

P3

Custom metric 乱発

高 cardinality な label (user_id 等) で metric が爆発、Monitoring cost が桁違いに。

P4

Uptime check 過頻度・過リージョン

1 min × 6 region の積み増しで cost。

P5

Packet Mirroring 全範囲

全 subnet で mirror、コレクタ ILB の処理能力 + コスト両方圧迫。

P6

Connectivity Tests 乱発

API quota 枯渇 + per-test 課金。

🚀 最適化テクニック 10 選

  1. Flow Logs sampling は env 別: prod 50%, stg 10%, dev 1-5%。
  2. Logging exclusion filter で audit 以外の noise log (health check, debug) を除外。
  3. BigQuery sink + long-term storage: Cloud Logging は 30 day、BigQuery で 1 year+。
  4. Custom metric は cardinality を抑える: label 値を bucketize、user_id を直接使わない。
  5. Uptime check は SLO 駆動: 99.9% なら 5 min、99.99% なら 1 min。
  6. Packet Mirroring は filter で絞る: protocol, port, CIDR を厳密に。
  7. Network Analyzer findings を automated triage: HIGH severity を ticket 起票自動化。
  8. Connectivity Tests を schedule で実行: 毎時 health check、ad-hoc を減らす。
  9. Multi-window burn-rate alert: SLO 駆動でアラート品質を向上。
  10. BigQuery view 層で schema 抽象化: Cloud Logging の schema 変化を吸収。

🔔 監視アラート設計

シグナルメトリック / 仕組み閾値
Logging ingest 急増logging.googleapis.com/log_entry_countbaseline +50%
BigQuery sink delayBigQuery LOAD job duration> 10 min
Custom metric cardinalityMonitoring API> 1M time series / metric
Uptime check failuptime_check_pass= 0 for 3 consecutive
Flow Logs ingest costBilling export前日比 +50%
Network Analyzer HIGH findingfinding API新規 HIGH
Cloud Monitoring quotaAPI quota> 80%
Connectivity Tests failscheduled test API失敗時
Packet Mirroring dropコレクタ ILB の healthCheck + Backend CPUbackend CPU > 80%
Audit log retention dropLogging sink config 変更delete event

📖 Runbook: 「Cloud Logging cost が急増」

1. Cost Explorer で sku 別 cost を確認 (cloud_logging_ingestion)
2. Cloud Logging Logs Router で sink 別 ingest 量を確認
3. 急増 logName を特定 (compute.googleapis.com/vpc_flows, etc.)
4. 短期対処:
   - Exclusion filter で不要 record 除外
   - sampling rate を下げる (Flow Logs 等)
5. 中期対処:
   - BigQuery sink に切替え、Cloud Logging retention 短縮
   - Logging quota を設定 (project level)
6. Post-mortem:
   - Logging cost SLI を作成、週次レビュー
   - 新規 log source 追加時の review プロセス整備