💰 FinOps とコスト最適化徹底深掘り

1. FinOps の哲学とサイクル

FinOps は FinOps Foundation が提唱する「クラウドのコストを エンジニア・財務・経営 の三位一体で継続最適化する」運営フレームワーク。Inform → Optimize → Operate の 3 フェーズを反復する。

📖 Google 公式：Cost optimization pillar — Google Cloud Architecture Framework

1.1 ShowBack vs ChargeBack

1.2 Billing Export と Unit Economics

BigQuery Billing Export（Standard / Detailed / Pricing）を設定し、Looker Studio で可視化するのが Google 推奨パス。

-- Detailed Billing Export からチーム別コスト集計
SELECT
  invoice.month,
  labels.value AS team,
  SUM(cost) - SUM(IFNULL((SELECT SUM(amount) FROM UNNEST(credits)), 0)) AS net_cost
FROM `billing_project.billing_export.gcp_billing_export_resource_v1_XXXXXX`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY 1, 2
ORDER BY 1 DESC, net_cost DESC;

Unit Economics：リクエスト 1 件あたりのコスト、ユーザ MAU あたりのコストを定義し、スケールしたときの収益性を予測。SaaS では必須指標。

1.3 GKE Cost Allocation

GKE クラスタで --enable-cost-allocation を有効化すると、Namespace / Workload 単位の CPU/Memory 使用量を Billing Export に注入してくれる。

gcloud container clusters update CLUSTER_NAME \
  --enable-cost-allocation \
  --location=REGION

📖 公式：View cluster cost allocation data — GKE Docs

1.4 Budget Alert の正しい設計

# Budget の threshold rules 例（gcloud or Terraform）
budget_filter:
  projects: ["projects/PROD_PROJECT"]
amount:
  specified_amount:
    currency_code: JPY
    units: 5000000  # 月 500 万円
threshold_rules:
  - threshold_percent: 0.5
  - threshold_percent: 0.75
  - threshold_percent: 0.9
  - threshold_percent: 1.0
  - threshold_percent: 1.0
    spend_basis: FORECASTED_SPEND  # 予測ベース

2. Spot VM 徹底解剖

📖 公式：Spot VMs — Compute Engine Docs

2.1 Spot VM ライフサイクル

2.2 Spot VM vs Preemptible（廃止予定）

新規ワークロードは Spot 一択。Preemptible はレガシー互換目的で残存。

2.3 30 秒 grace period のハンドリング

#!/bin/bash
# /etc/preempt-shutdown.sh
# Spot preemption 通知を受け取った時の優雅な停止

# 1) アプリに SIGTERM 送出（10 秒以内）
systemctl stop my-worker

# 2) 進行中バッチを cancel API で外部に通知（5 秒以内）
curl -X POST https://api.example.com/cancel \
     -H "Authorization: Bearer $TOKEN" \
     --max-time 5

# 3) ローカル WAL を GCS にアップロード（残り 10 秒）
gsutil -q cp /var/lib/myapp/wal-* gs://drain-bucket/$(hostname)/

# 4) sync して終了
sync

shutdown script は --metadata shutdown-script=... または --metadata-from-file shutdown-script=... で設定。Cloud Logging には自動転送される。

2.4 GKE Spot ノードプール

gcloud container node-pools create spot-workers \
  --cluster=my-cluster \
  --location=asia-northeast1 \
  --spot \
  --enable-autoscaling --min-nodes=0 --max-nodes=100 \
  --machine-type=n2-standard-8 \
  --node-taints=cloud.google.com/gke-spot=true:NoSchedule

Pod 側で toleration と nodeSelector を指定：

spec:
  tolerations:
    - key: cloud.google.com/gke-spot
      operator: Equal
      value: "true"
      effect: NoSchedule
  nodeSelector:
    cloud.google.com/gke-spot: "true"
  terminationGracePeriodSeconds: 25  # 30 秒以内に終了完了

2.5 ハイブリッド node pool 設計

2.6 Spot で動かしてよい / ダメ

2.7 Spot 事故ケース

3. CUD（Committed Use Discounts）完全理解

📖 公式：Committed use discounts — Compute Engine Docs

3.1 CUD の 2 種類

3.2 割引率の具体値（リージョン・マシンファミリー別）

3.3 CUD 自動適用の階層

3.4 CUD Recommender

Recommender API は過去 30 日の使用量を分析し、購入推奨 CUD を提示。Console から確認可能。

gcloud recommender recommendations list \
  --project=$PROJECT_ID \
  --location=global \
  --recommender=google.compute.commitment.UsageCommitmentRecommender

3.5 CUD 購入タイミング戦略

3.6 CUD 事故ケース

4. SUD（Sustained Use Discounts）詳細

📖 公式：Sustained use discounts — Compute Engine Docs

4.1 SUD の自動適用条件

SUD は 申請不要・自動適用。月間で N1/N2/N2D/E2/C2/M1 の vCPU と RAM を一定割合以上稼働した分について段階的に割引。

※ N1 と他の 2nd-gen 系で正確な階段の刻みが異なる。最新の数値は公式 docsで確認。

4.2 inferred instance（推論インスタンス）

SUD は個別 VM の稼働時間ではなく、同マシンタイプの合計 vCPU・メモリ時間 を合算した「推論インスタンス」単位で計算する。

4.3 CUD との併用ロジック

CUD と SUD は重複ではなく順次適用。CUD を多く購入していれば SUD の効きどころは限定的。

4.4 SUD 事故ケース

5. Network Tiers と Egress コスト

📖 公式：Network Service Tiers overview

5.1 Premium Tier vs Standard Tier

5.2 Egress 料金体系

5.3 Cross-Cloud Interconnect

AWS / Azure / OCI / Alibaba との専用線接続。Egress は Cross-Cloud Interconnect 料金（公衆インターネット egress より安い）。

5.4 Network Tier 事故ケース

6. Recommender / Active Assist

📖 公式：Recommender overview

6.1 Active Assist 全体像

6.2 Recommender 5 カテゴリ詳細

6.3 Recommender 自動化（GitOps PR 生成パターン）

# Recommender 取得例
gcloud recommender recommendations list \
  --project=$PROJECT_ID \
  --location=global \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format=json

6.4 Recommender 事故ケース

7. ワークロード別コスト最適化

7.1 GKE 最適化

Bin Packing 最適化：CA の --autoscaling-profile=optimize-utilization + Pod の reasonable な requests 設定で、node 利用率を 80%+ まで上げる。

7.2 Cloud Run 最適化

7.3 Compute Engine 最適化

• Right sizing：Recommender + 観測 30 日以上
• Custom machine type：vCPU/RAM 比率を workload に合わせる（GCE のみ、N1/N2 系で利用可）
• Sole-tenant Node：BYOL や license compliance に必要なら（コストは高い）
• PD タイプ選定：
  ・Standard（HDD）：低速・安価、バックアップ向け
  ・Balanced：SSD でコスト 70%、汎用
  ・SSD：低レイテンシが必要な DB
  ・Extreme：> 100K IOPS が必要な特殊用途のみ
• Snapshot lifecycle policy：日次 7 days + 週次 4 weeks + 月次 12 months で自動削除

7.4 観測可能性自体のコスト削減

7.5 ワークロード別事故ケース

8. 事故ケース総集編 / 即答パターン

8.1 全事故ケース一覧（31 件）

8.2 即答すべき選択肢マトリクス

8.3 Carbon Footprint と Sustainability

Well-Architected の Sustainability 柱に対応。Cloud Carbon Footprint で project / region / service 別の CO₂ 排出量を可視化。

• 低炭素リージョン選定：europe-north1 (Finland), us-central1 (Iowa), europe-west1 (Belgium) など。公式 region carbon data ↗
• Scope 1 / 2 / 3 の区別：GCP の電力使用は Scope 2。GHG プロトコル準拠
• Sustainability vs Cost vs Performance の 3 軸トレードオフ：低炭素リージョンが遠ければレイテンシ悪化

8.4 最終チェックリスト

9. GKE 運用深掘り：事故・コスト・肥大化対策

Section 2 / 7 では Spot や Autopilot vs Standard の入口を扱いましたが、本章では「現場で実際に燃えた事故」「請求書がなぜ跳ねたか」「どう抑え込んだか」に絞り、より実務寄りで深掘りします。事故ケースは Section 2.7 / 7.5 との重複を避け、Control Plane / Autoscaling / Workload Identity / Ingress / Logging など運用層の罠を集めています。

「Autopilot is a mode of operation in GKE in which Google manages your cluster configuration, including your nodes, scaling, security, and other preconfigured settings.」 — GKE Autopilot overview

9.1 重大事故ケース 10 件（実務深掘り版）

各ケースは 症状 / 原因 / 処置 / 教訓 / 検知 metric の 5 行で構成。Section 2 / 7 と重複しないように、Autopilot 制約・Cluster Autoscaler 挙動・Control Plane upgrade・Workload Identity・Ingress Health Check・Logging quota を中心に選定しています。

9.2 GKE コスト構造の解剖（Standard vs Autopilot）

GKE の請求書は「cluster 管理料 + compute 料 + storage 料 + network 料」の 4 階層で構成されます。Standard と Autopilot でcompute 課金単位が決定的に異なるため、ワークロード特性により最適解が変わります。

9.2.1 主要コンポーネント別の課金（2026 年時点）

「Autopilot mode bills you for the CPU, memory, and ephemeral storage that your Pods request while they are running.」 — GKE pricing — Autopilot mode

9.2.2 Autopilot の Pod 単価（General-purpose, us-central1）

9.2.3 Standard の Node 単価（参考、n2-standard-4 = 4 vCPU/16 GiB, us-central1）

9.2.4 Autopilot vs Standard 単価の損益分岐点

9.3 コスト肥大化の典型パターン 6 件

9.4 最適化テクニック 10 個

1. Autopilot vs Standard の判断軸：
   ・Autopilot 有利：小規模（< 30 Pod）、運用工数最小化、SRE 不在、初学者
   ・Standard 有利：大量 Pod（> 50）、特殊 DaemonSet、bin packing 80%+、GPU、特殊 networking
2. Cluster Autoscaler の optimize-utilization profile：--autoscaling-profile=optimize-utilization でscaleDown を積極化、node 利用率 80%+ を目指す。デフォルト balanced は availability 優先。
3. Bin packing 最適化（適切な resources.requests）：VPA Recommendation mode で過去 30 日の実測 → requests = p95 × 1.2 を PR 化。requests 適正化が単一最大のコスト削減手段。
4. Spot node pool の活用：stateless / バッチ / dev は Spot で 60-91% 削減。production はmulti-zone Spot + on-demand fallback + PDB + preStop の 4 点セット。
5. Node Auto-Provisioning（NAP）+ 上限設定：NAP は新規 machine type を自動選定し bin packing 効率化。必ず --autoprovisioning-max-cpu / --max-memory で上限を設定。
6. Vertical Pod Autoscaler in Recommendation mode：Auto モードは HPA 競合・restart 多発のため本番禁止。Recommendation mode で値だけ取得し人間レビュー。
7. GKE Cost Allocation + Cost Insight：cluster 単位で billing-export を namespace / label 別に按分可能。BigQuery + Looker Studio で部門別 dashboard。
8. Multi-tenant cluster（namespace 分離）：cluster 数を圧縮し管理料・base capacity を節約。ResourceQuota + LimitRange + NetworkPolicy + Hierarchical Namespaces (HNS) でテナント分離。
9. Pod Disruption Budget の適切な設定：production は必ず PDB。minAvailable: 50% 推奨。Org Policy / Policy Controller で必須化。
10. Regional vs Zonal の trade-off：
    ・Regional：control plane 冗長、upgrade zero downtime、node も multi-zone で配置可、cluster 管理料は zonal と同額（2024 以降）
    ・Zonal：単一 zone のみ、upgrade 中 API 停止、dev / 学習用
    → production は Regional 一択

9.5 監視・アラート設計（GKE 特有）

9.5.1 監視すべき主要 metric

9.5.2 GKE 特有の SLO 設計

9.5.3 コスト・容量アラート

9.6 試験ポイント（Section 9 要点）

10. Cloud Run 運用深掘り：事故・コスト・肥大化対策

Cloud Run は「リクエストベースの完全サーバレス compute」として運用工数最小ですが、concurrency / cpu-allocation / min-instances の 3 つの設定を理解しないと、請求書が想定の数十倍になることがあります。本章では Section 2.7 / 7.5 の Cloud Run 事故を発展させ、Worker Pool・Cloud Run Jobs・gen1↔gen2・VPC Connector・Secret 連携などの深部を扱います。

「By default, a container instance is allocated CPU only during request processing. You can configure your service to always allocate CPU to container instances.」 — Cloud Run CPU allocation

10.1 重大事故ケース 10 件（実務深掘り版）

各ケースは 症状 / 原因 / 処置 / 教訓 / 検知 metric の 5 行で構成。Section 7.5 の事故と重複しないように、Worker Pool・Jobs・Secret・gen 切替・size limit・VPC Connector・Cloud Run Functions 等の深部を扱います。

10.2 Cloud Run コスト構造の解剖

Cloud Run の請求は「vCPU 秒 + Memory 秒 + Request 数 + Network egress」の 4 軸で構成され、さらに「CPU allocation モード」と「min-instances」で課金挙動が大きく変わります。理解の鍵は「いつ vCPU/Memory が課金されるか」です。

10.2.1 主要コンポーネント別の課金（2026 年時点、Tier 1 region）

「With CPU always allocated, your container instances always have CPU allocated. This is useful for background tasks or for services that have an active connection to a client.」 — Cloud Run CPU allocation

10.2.2 CPU allocation モードの違い（最重要）

10.2.3 Free tier の正確な仕様

10.2.4 試算例：3 つの典型ワークロード

10.3 コスト肥大化の典型パターン 6 件

10.4 最適化テクニック 10 個

1. concurrency 設定の負荷試験：1 / 8 / 32 / 80 で実機計測。レイテンシ劣化が許容範囲内の最大値を採用。I/O bound = 80、CPU bound = 8-16。
2. CPU always allocated は必要時のみ：WebSocket / SSE / 背景処理 / 長時間 streaming の4 ユースケース限定。それ以外は throttled（デフォルト）。
3. min-instances は SLO 要件 vs cold start トレードオフで決定：SLO 厳しい (p99 < 1s) なら 1-2、それ以外は 0。「全 service で min=2」は禁忌。
4. CPU boost で cold start 短縮（gen2）：--cpu-boost で起動時 CPU 倍増、cold start 50% 短縮。コスト影響は startup 数秒のみ。
5. Direct VPC egress（gen2）で Connector コスト削減：Serverless VPC Connector の min instance 2 + データ処理料を回避。公式 ↗
6. Cloud Run Functions vs service の使い分け：
   ・Functions：Pub/Sub trigger、Storage trigger、HTTP の短時間関数、簡易デプロイ
   ・service：細かい設定が必要、複雑なルーティング、長時間処理、自前 Dockerfile
7. Always-on CPU vs request-based の判断軸：
   ・request-based：stateless API、サンプル数 90% 以上のユースケース
   ・always-on：WebSocket / SSE / background processing（明確な要件があるときのみ）
8. revision tag で blue-green deploy：gcloud run deploy --tag=blue --no-traffic で新 revision を tag 経由でテスト可、本番 traffic は 0% のまま検証。
9. traffic splitting で canary release：--to-revisions=blue=10,green=90 で段階的に traffic 移行。エラー率を見ながら 10 → 50 → 100%。
10. Cloud Run Jobs のリソース最適化：
    ・--cpu / --memory を実測ベースで設定（過剰スペック禁止）
    ・--parallelism で並列度調整（高すぎると DB 負荷、低すぎると総時間長期化）
    ・冪等性 + --max-retries=3 で flaky 対策
    ・--task-timeout を p99 × 1.5 で設定

10.5 監視・アラート設計（Cloud Run 特有）

10.5.1 監視すべき主要 metric

10.5.2 Cloud Run 特有の SLO 設計

10.5.3 コスト・容量アラート

10.6 試験ポイント（Section 10 要点）