Section 4 — 応用編：マルチリージョナル DR とゼロダウンタイム運用

🔧 対象: 中堅以上 ゴール: マルチリージョン DR、Blue-Green デプロイ、Near-Zero ダウンタイムの構築判断・実装ができる。

1. マルチリージョナル DR の選択肢

各 DB サービスの DR 構成

試験で問われる判断軸

• RPO=0 + RTO 数秒 が必要 → Spanner Multi-region / Bigtable Multi-cluster / Firestore Multi-region
• RPO 数分・RTO 数十分 で許容 → Cloud SQL/AlloyDB クロスリージョン

2. Cloud SQL のクロスリージョン DR 構築

構築手順

# 1. プライマリリージョンに HA 構成で Primary 作成
gcloud sql instances create primary \
  --region=asia-northeast1 \
  --availability-type=REGIONAL \
  ...

# 2. 別リージョンに リードレプリカ作成
gcloud sql instances create dr-replica \
  --region=us-central1 \
  --master-instance-name=primary \
  --tier=db-n1-standard-4

# 3. 災害時: リードレプリカを昇格
gcloud sql instances promote-replica dr-replica

フェイルオーバー手順（災害時）

1. プライマリリージョン障害確認
2. アプリの書き込みを停止（ダブルライト防止）
3. DR リードレプリカを Promote
4. アプリの接続文字列を DR DB に変更
5. 新規プライマリの整合性確認
6. 監視 + アラート再設定
7. プライマリリージョン復旧後、別リードレプリカ作成 → 切り戻し計画

注意点

• 手動 Promote が必要（自動ではない）
• Promote 後、逆方向のレプリケーションは自動では張られない
• 切り戻しは 新規 DMS ジョブ で計画的に実施

3. AlloyDB の Secondary Cluster

Secondary Cluster の特徴

• クロスリージョンに非同期で複製
• 読み取り可能 （DR + 読み取り分散）
• 昇格でプライマリに切替

構築

# プライマリ
gcloud alloydb clusters create primary-cluster \
  --region=asia-northeast1 ...

# Secondary (DR)
gcloud alloydb clusters create secondary-cluster \
  --region=asia-northeast2 \
  --secondary-config-primary-cluster=primary-cluster

Cloud SQL の リードレプリカ vs AlloyDB Secondary

4. Spanner Multi-region の真価

Spanner Multi-region のアーキテクチャ

┌────────────────────────────────────────────────────────┐
│  Spanner Multi-region (例: nam3 = us-central+us-east) │
│                                                        │
│   ┌─ Read-Write Region (us-central1) ──┐               │
│   │  Paxos Leader                       │               │
│   │  + Read replicas                    │               │
│   └─────────────────────────────────────┘               │
│              │ Paxos                                    │
│   ┌─ Read-Write Region (us-east1) ─────┐               │
│   │  Paxos Voter                        │               │
│   │  + Read replicas                    │               │
│   └─────────────────────────────────────┘               │
│              │                                          │
│   ┌─ Read-only Region (us-east4) ──────┐               │
│   │  Witness (タイブレーカー)            │               │
│   └─────────────────────────────────────┘               │
└────────────────────────────────────────────────────────┘

TrueTime と外部整合

• Spanner は TrueTime API を使ってグローバル整合性を実現
• 物理時計（GPS + 原子時計）+ 時刻範囲（uncertainty interval）
• これにより グローバル分散 + 外部整合（リニアライザビリティ） が成立

Spanner の SLA を最大化する設定

• Multi-region config を選ぶ (nam3, eur3, asia1, asia2 など)
• 適切なリージョンセット（地理的に分散）
• Processing Units を CPU 65% 以下に保つ
• インデックス・スキーマ設計を最適化（ホットスポット回避）

5. Bigtable Multi-cluster ルーティング

構成

[Bigtable Instance]
├── Cluster A (us-central1) — Primary 役割なし、全クラスタ等価
├── Cluster B (us-east1)
└── Cluster C (asia-northeast1)

App Profile での設定

App Profile (multi-cluster-routing)
   ├ Routing Policy: Multi-cluster routing
   ├ Cluster Group: A, B, C
   └ Allow Transactional Writes: false （シングル行のみ整合性保証）

単一クラスタ ルーティング vs マルチクラスタ ルーティング

6. Firestore Multi-region の特徴

Multi-region ロケーション

• nam5: 米国（us-central, us-east の組み合わせ）
• eur3: 欧州
• asia1: アジア (asia-northeast1 + asia-northeast2)

自動フェイルオーバー

• リージョン障害時、別リージョンが自動引継ぎ
• アプリ側の変更不要
• SLA 99.999%

コストの比較

7. Blue-Green デプロイの DB バージョン

概念

新バージョンを Blue環境 に並行構築 → アプリ側で切替 → 旧 Green は保持（ロールバック用）。

Cloud SQL Blue-Green

Green (現行 PostgreSQL 14)        Blue (新規 PostgreSQL 15)
       ↑                                 ↑
       │ アプリ接続                       │
       │                                 │
       └── DMS でデータ同期 ──────────────┘
            (Continuous モード)

[カットオーバー]
       Green (停止 or 残置)         Blue (新規プライマリ)
                                        ↑
                                        │ アプリ接続切替

メリット

• ロールバック容易（Green を残してある）
• テスト時間が十分とれる
• DMS が同期を維持 している間に検証可能

デメリット

• コスト2倍 （並行運用中）
• DMS のラグ管理が必要

8. Near-Zero ダウンタイム メンテナンス

Cloud SQL Enterprise Plus の Near-Zero Downtime

• Enterprise Plus 限定機能
• パッチ適用時の 接続切断時間を 10 秒以下 に短縮
• 通常 Enterprise は 60-120 秒のダウンタイムが発生

仕組み

• パッチ時に新しいインスタンスに シームレスに切替
• アプリ側の 接続再試行 で実質ダウンタイムなし

注意点

• Enterprise Plus でのみ利用可能
• メジャーアップグレードは対象外（マイナー・パッチのみ）

9. Pessimistic デプロイ (慎重派) の構成パターン

本番 DB の推奨デプロイ構成

[本番 DB]
├── Primary (asia-northeast1, REGIONAL HA)
├── Read Replica 1 (asia-northeast1, 読み取り用)
├── Read Replica 2 (asia-northeast1, 読み取り用)
└── Cross-region Replica (asia-northeast2, DR用)

[監視]
├── Cloud Monitoring カスタムダッシュボード
├── Alert Policy (CPU/Memory/Storage/Connections/Lag)
└── Uptime Check (外部からの接続確認)

[バックアップ]
├── 自動バックアップ (毎日 02:00)
├── PITR (35日)
├── オンデマンドバックアップ (リリース前)
└── 月次エクスポート → GCS Archive

[IAM]
├── アプリ用 SA (cloudsql.client)
├── 運用者 SA (cloudsql.editor, MFA必須)
└── 監査 SA (cloudsql.viewer)

[ネットワーク]
├── VPC + Private IP
├── Cloud SQL Auth Proxy または PSC
└── Firewall Rules (最小限)

10. プロビジョニング自動化の高度パターン

Terraform Modules でテンプレ化

module "cloud_sql_ha" {
  source = "./modules/cloud-sql-ha"

  name        = "my-app-prod"
  region      = "asia-northeast1"
  tier        = "db-custom-4-15360"
  network     = google_compute_network.main.id
  
  ha_enabled  = true
  pitr_enabled = true
  cross_region_replica = true
  replica_region = "asia-northeast2"
}

モジュール化のメリット

• 環境ごとに同じ構成 を確実に再現
• 改善が一箇所で完結
• レビュー範囲が小さくなる

CI/CD ベストプラクティス

• terraform plan を必ず PR で確認
• 本番 apply は手動承認（自動はしない）
• Workload Identity Federation で鍵レス
• State は GCS バックエンド + 排他制御

11. テストの種類とタイミング

DB に関する 4 つのテスト

Chaos Engineering（応用）

• 意図的に障害を起こして システムのレジリエンスを検証
• 例: ゾーン障害シミュレーション、ネットワーク遅延注入
• Google Cloud では 手動でリージョン障害は起こせない → 計画停止で代替

12. このセクションのチェックリスト

• 各 DB の DR 構成と RPO/RTO を即答できる
• Cloud SQL クロスリージョン DR の手動 Promote 手順を言える
• AlloyDB Secondary Cluster の特徴を説明できる
• Spanner TrueTime の役割を説明できる
• Bigtable Single vs Multi-cluster routing を区別できる
• Firestore Multi-region の SLA を覚えている
• Blue-Green デプロイ + DMS のフローを言える
• Cloud SQL Enterprise Plus Near-Zero Downtime の制約を知っている
• 本番 DB の推奨構成（HA + Replica + DR + バックアップ）を言える
• Terraform Modules でテンプレ化する利点を説明できる
• Chaos Engineering の概念を理解している