1. 各 DB の課金モデル
| サービス | 主な課金軸 | 従量 / 固定 | CUD 対応 |
|---|
| Cloud SQL |
vCPU/RAM 時間単価 + ストレージGB/月 + Network egress |
固定 |
対応 (1y / 3y) |
| AlloyDB |
vCPU 時間 + ストレージGB/月 + バックアップ容量 |
固定 |
対応 |
| Spanner |
PU/Node 時間単価 + ストレージGB/月 |
固定 |
対応 |
| Bigtable |
Node 時間単価 + ストレージGB/月 (SSD/HDD) |
固定 |
対応 (Node のみ) |
| Firestore |
Read/Write/Delete 数 + ストレージGB |
従量 |
非対応 |
| Memorystore (Redis) |
メモリ GB/時間 |
固定 |
対応 |
| BigQuery |
クエリ TB / ストレージGB |
従量 (or Editions 固定) |
対応 |
| Datastream |
処理 GB |
従量 |
非対応 |
| DMS |
無料 (ターゲット DB のみ課金) |
— |
— |
従量課金の DB は予測しにくい。Firestore / BigQuery / Datastream は必ず Budget Alertを設定し、急増を検知できるようにする。
2. Committed Use Discount (CUD) 活用
2-1. CUD の仕組み
1 年または 3 年の利用を事前にコミットする代わりに、20〜60% の割引が適用される。Cloud SQL / AlloyDB / Spanner / BigQuery などが対応。
| 期間 | 典型割引 | 柔軟性 |
|---|
| 1 年 CUD | 20〜30% | 中 |
| 3 年 CUD | 40〜60% | 低 (固定) |
| Spot/Flex | 5〜10% | 高 (いつでも解約) |
2-2. CUD 戦略
推奨アプローチ:
- 本番のベースライン使用量を 1 年 CUD
- 確実な部分のみ 3 年 CUD で長期割引
- 変動 + ピーク分は オンデマンドでコスト最適化
- 未消化 CUD は他プロジェクトと共有可（Org level CUD）
CUD の罠: 3 年契約後にワークロードが減ったり、別 DB に移行することになると、未消化分の CUD はそのまま課金される。慎重に判断。
3. 適正サイズ化 (Right-sizing)
3-1. オーバープロビジョニングの検出
指標: CPU 平均利用率 30% 未満が 7 日継続
└─ Down-size 候補
指標: ストレージ実使用率 50% 未満
└─ プロビジョニング過剰
指標: 接続数 max の 30% 未満
└─ max_connections 設定見直し
指標: リードレプリカの CPU 10% 未満
└─ レプリカ削減
3-2. Active Assist による自動推薦
Google Cloud Recommender (旧 Active Assist) はCloud SQL のサイズ過剰を自動検出して推薦する。実装も自動適用可能。
Cloud SQL Idle Instances Recommender:
過去 14 日間アクセスのないインスタンスを検出 → 削除推奨
Cloud SQL Over-provisioned Recommender:
CPU / RAM の利用率が低いインスタンスを検出 → ダウンサイズ推奨
4. ネットワークコストの罠
4-1. リージョン間 Egress の罠
本番 DB と分析環境を別リージョンに配置していると、リージョン間 Egress 料金が膨らむ。1 TB 転送 = 約 $100。
4-2. 同一リージョン化のメリット
| ネットワーク経路 | 料金 | レイテンシ |
|---|
| 同ゾーン (内部) | 無料 | 最小 |
| 同リージョン異ゾーン | 低額 ($0.01/GB) | 低 |
| 異リージョン (大陸内) | $0.08-0.12/GB | 中 |
| 異大陸 | $0.08-0.15/GB | 高 |
| インターネット出 | $0.12/GB | 変動 |
4-3. ネットワーク最適化テクニック
- DB とアプリは同リージョン同ゾーンに配置
- クロスリージョン Replica は必要な場合のみ（DR / コンプライアンス）
- 大量データ転送は Private Google Accessを使用（インターネット出口経由しない）
- Cloud Interconnect でオンプレ ⇄ GCP の Egress を低減
5. ストレージコストの最適化
5-1. ストレージタイプ選択
| サービス | 選択肢 | 用途 |
|---|
| Cloud SQL |
SSD (標準) / HDD (低速) |
本番は SSD、開発は HDD でコスト削減 |
| Bigtable |
SSD / HDD |
HDD は SSD の 1/4 価格、低頻度アクセスに |
| Spanner |
SSD のみ |
選択肢なし |
5-2. バックアップストレージの圧縮
- PITR 保持期間を業務要件に絞る（7日で十分なら 35日にしない）
- 不要な過去バックアップを定期削除
- 長期保管が必要なら GCS Archive クラスへエクスポート（DB バックアップより安価）
- 古いインスタンスは月次でレビューし、不要なら削除
5-3. データのアーカイブ戦略
本番 DB (Cloud SQL): 直近 3 ヶ月分
↓ 月次ジョブ
BigQuery: 3〜12 ヶ月分 (分析用、圧縮効率良)
↓ 年次ジョブ
GCS Archive: 1 年以上 (コスト最低)
メリット:
- Cloud SQL のストレージ料金最小化
- 分析は BigQuery で実行 (DB に負荷なし)
- 古いデータも法令対応で保持可能
6. 非本番環境のコスト圧縮
6-1. 開発環境の標準構成
| 環境 | Cloud SQL 構成 | 削減効果 |
|---|
| 本番 | Regional HA + リードレプリカ × 2 | — |
| ステージング | Regional HA | 30% |
| 開発 | Zonal (HAなし) | 50% |
| 個人開発 | db-f1-micro (最小) | 80% |
6-2. 開発環境の自動停止
Cloud SQL は停止状態でもストレージ料金は発生するが、インスタンスは止まる。夜間・週末は自動停止で月額を大幅削減。
Cloud Scheduler (cron: 0 19 * * MON-FRI)
↓
Cloud Functions
↓ gcloud sql instances patch --activation-policy=NEVER
Cloud SQL 停止
Cloud Scheduler (cron: 0 8 * * MON-FRI)
↓ gcloud sql instances patch --activation-policy=ALWAYS
Cloud SQL 起動
効果: 13h/24h × 5/7 day = 約 39% の稼働削減
7. Budget Alert と予算管理
7-1. Budget Alert の設定
推奨設定:
- Budget Alert をプロジェクト毎に設定（共有プロジェクトは要注意）
- 50%, 80%, 100%, 120% の4 段階閾値
- 50% で「予測支出」での通知（実支出ではない）
- 通知は Slack + Email + PagerDuty（重要度別）
- Budget は月次でレビュー、ビジネスの成長で見直し
7-2. プロジェクト分離戦略
プロジェクトをコスト粒度で分離する。
- 環境別:
prod-db / stg-db / dev-db
- サービス別:
service-a-db / service-b-db
- チーム別: 各チームに独立した予算
メリット: コストの所有者が明確、Budget Alert も独立、IAM 分離もしやすい
8. コスト可視化 (Billing Export → BigQuery)
8-1. Billing Export のセットアップ
Cloud Billing
↓ 自動エクスポート (1日数回)
BigQuery (gcp_billing_export_v1_xxx)
↓ SQL クエリ
Looker / Looker Studio ダッシュボード
8-2. よく使うクエリ例
サービス別月額
SELECT
service.description AS service,
ROUND(SUM(cost), 2) AS total_cost,
ROUND(SUM(CAST(c.amount AS NUMERIC)), 2) AS credits
FROM `project.dataset.gcp_billing_export_v1_XXX`,
UNNEST(credits) AS c
WHERE DATE(_PARTITIONTIME) BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY service
ORDER BY total_cost DESC
Cloud SQL インスタンス別コスト
SELECT
resource.name AS instance,
service.description AS service,
ROUND(SUM(cost), 2) AS total_cost
FROM `project.dataset.gcp_billing_export_v1_XXX`
WHERE service.description = 'Cloud SQL'
AND DATE(_PARTITIONTIME) BETWEEN '2026-05-01' AND '2026-05-31'
GROUP BY instance, service
ORDER BY total_cost DESC
8-3. ダッシュボード設計
必須のダッシュボード:
- 当月予測 vs 予算 (今月の着地予測)
- 前月比トレンド（サービス別、リソース別）
- 異常検出（前日比 +50% などの急増）
- CUD 消化率（未消化があれば警告）
- 無料枠の活用状況（Firestore など）
9. サービス別 削減パターン
Cloud SQL
- 1 年 CUD で 25% 削減（本番ベースライン）
- 開発環境を Zonal にして 30% 削減
- 未使用 リードレプリカを月次レビューで削除
- Idle Instances Recommender で停止候補を検出
- 不要 binlog 削減（PITR 保持期間最適化）
AlloyDB
- Read Pool ノード数を負荷に応じて削減
- Continuous Backup 保持期間を業務要件に合わせて短縮
- 1 年 CUD 活用
Spanner
- PU 数を Autoscaler で自動調整
- Strong Read を必要箇所のみに（Stale Read は安価）
- 未使用 Read-only Replica の削減
- 3 年 CUD で大幅削減
Bigtable
- 低頻度データは HDD クラスタへ（1/4 価格）
- Autoscaling でノード数を動的調整
- Garbage Collection で古いセル削除
- 不要なマルチクラスタを統合
Firestore
- クエリ最適化が最重要（read 数削減）
- Real-time listener の見直し
- 無料枠 (1GB ストレージ + 5万 read/日) の活用
- 多次元集計はクライアントキャッシュで read 削減
Memorystore
- 適切なメモリサイズ（過剰プロビ NG）
- 開発環境は Basic Tier で削減
- 使われないキーを LRU で自動削除
BigQuery
- クエリの partition + cluster でスキャン量削減
- 頻繁にクエリされるなら Editions (固定料金)
- 長期保管データの料金最適化（90日後に自動移行）
- マテリアライズドビューでクエリ削減
10. 試験シナリオ別 最適解
| シナリオ | 最適解 |
|---|
| 「コスト削減したい」+「ベースライン安定」 |
CUD 1 年 |
| 「開発環境のコスト最小化」 |
Zonal + 夜間停止 |
| 「Cloud SQL のストレージ料金高い」 |
古いデータを GCS Archive へ |
| 「Firestore の課金爆発」 |
クエリ最適化 + Budget Alert |
| 「BigQuery のクエリコスト高い」 |
partition + cluster + Editions 検討 |
| 「Spanner Multi-region 高い」 |
Regional + Cross-region Backup で代替検討 |
| 「データを長期保管したい (7年)」 |
月次エクスポート → GCS Archive |
| 「未使用リソースの自動検出」 |
Active Assist / Recommender |
FinOps 文化:
コスト最適化は開発 / 運用 / 経営の三位一体。SRE が「コストを所有」し、技術的選択がビジネスに与える影響を理解する。マネージドだから安全という発想を捨て、定期的なコストレビューを習慣化する。