🏛 SECTION 4
Google Cloud 上でのスケーラブル・高可用 DB のデプロイ
公式試験範囲: ~20%。Terraform / IaC が標準回答。手動 GUI 構築は試験では NG。
🤖 1. なぜ IaC(Infrastructure as Code)か
試験では「手動 GUI」よりも 再現性・自動化を選ぶ問題が頻出。
手動構築の問題
- 環境差分(dev/stg/prod)が出る
- 変更履歴が残らない
- レビューが効かない
- 災害復旧時に再構築できない
IaC の利点
- コードで Pull Request レビュー
- 環境間の再現性
- 災害時の即時再構築
- 監査ログ + バージョン管理
🛠 2. Cloud SQL HA Terraform
本番推奨設定
resource "google_sql_database_instance" "main" {
name = "my-postgres-prod"
database_version = "POSTGRES_15"
region = "asia-northeast1"
settings {
tier = "db-custom-4-15360"
availability_type = "REGIONAL" # ← HA
backup_configuration {
enabled = true
start_time = "02:00"
point_in_time_recovery_enabled = true
transaction_log_retention_days = 7
}
ip_configuration {
ipv4_enabled = false # ← Public IP 無効
private_network = google_compute_network.main.id
}
insights_config {
query_insights_enabled = true
}
}
deletion_protection = true # ← 誤削除防止
}
🏗 3. 各 DB の HA 構成
Cloud SQL HA
availability_type = "REGIONAL" で別ゾーンに同期スタンバイ + 自動フェイルオーバー。
SLA 99.95%
AlloyDB HA
Primary + Read Pool(読み取り水平スケール) + Secondary Cluster(クロスリージョン DR)
SLA 99.99%
Spanner Multi-region
Paxos ベースの自動フェイルオーバー。nam3 / eur3 / asia1 / asia2 など
SLA 99.999%
Bigtable Multi-cluster
複数クラスタ別リージョン配置、App Profile で multi-cluster routing 設定
SLA 99.999%
🔄 4. リードレプリカ 4 種類
| 種類 | 用途 |
|---|---|
| 同期スタンバイ(HA の片割れ) | Primary 障害時の自動フェイルオーバー |
| 同期リードレプリカ | 読み取り分散、強整合 |
| 非同期リードレプリカ | 読み取り分散、軽い遅延 OK |
| クロスリージョン リードレプリカ | DR、リージョン障害対策(手動 Promote) |
🌐 5. Spanner Config 一覧
| Config | 範囲 |
|---|---|
| regional-asia-northeast1 | 東京リージョン内 |
| regional-us-central1 | 米国中部 |
| nam3 | Multi-region: 北米 |
| eur3 | Multi-region: 欧州 |
| asia1 | Multi-region: 東京 + 大阪 |
| asia2 | Multi-region: 東京 + 香港 |
🧪 6. フェイルオーバー試験
設計通りに動作するかを確認し、復旧手順を関係者で再確認する。月次 or 大変更後に実施。
Cloud SQL HA フェイルオーバー試験コマンド
# 手動フェイルオーバー
gcloud sql instances failover my-mysql-prod
# 動作確認
# 1. アプリから接続できるか
# 2. 書き込みができるか
# 3. データ整合性が保たれているか
# 4. フェイルオーバー時間 (数十秒〜数分) を計測
🚀 7. プロビジョニング自動化
GitOps パターン
Pull Request 作成
↓
GitHub Actions で terraform plan
↓
レビュー + 承認
↓
merge → terraform apply (自動)
↓
Cloud SQL / AlloyDB / Spanner 更新
Workload Identity Federation を使えば、CI/CD のサービスアカウント鍵は不要。GitHub OIDC → GCP SA を一時資格情報で借りる方式が推奨。
📊 8. 監視 IaC
Cloud Monitoring Alert を Terraform で
resource "google_monitoring_alert_policy" "cpu" {
display_name = "Cloud SQL CPU High"
conditions {
display_name = "CPU > 80% for 5 min"
condition_threshold {
filter = "resource.type=\"cloudsql_database\" AND ..."
duration = "300s"
comparison = "COMPARISON_GT"
threshold_value = 0.8
}
}
notification_channels = [google_monitoring_notification_channel.slack.id]
}
このセクションの要点
- 手動 GUI ではなく Terraform が標準回答
- 本番 Cloud SQL は
availability_type=REGIONAL+deletion_protection=true - Spanner Multi-region (nam3/eur3/asia1/asia2) で 99.999%
- クロスリージョン リードレプリカは 手動 Promote
- フェイルオーバー試験は月次 + 大変更後
- CI/CD は Workload Identity Federation で鍵レス