Section 4 — 基礎編：HA 構成のプロビジョニングと運用テスト

📘 対象: 全員（必読） ゴール: HA・リードレプリカ・マルチリージョン構成を gcloud / Terraform で構築でき、フェイルオーバー試験を実施できる。

1. なぜ IaC（Infrastructure as Code）か

試験では「手動で GUI 構築」よりも 再現性・自動化 を選ぶ問題が頻出。

手動構築の問題点

環境差分が出る（開発 / ステージ / 本番）
変更履歴が残らない
レビューが効かない
災害復旧時に再構築できない

IaC の利点

コードでレビュー 可能（Pull Request）
環境間の再現性 が保証される
災害復旧時に即再構築 可能
監査ログ + バージョン管理 が GitOps で実現

Google Cloud の IaC ツール

ツール	特徴	試験での扱い
Terraform	業界標準、マルチクラウド対応	★ 推奨答え
Cloud Deployment Manager	Google ネイティブ（YAML/Python）	レガシー、新規は Terraform
Config Connector	Kubernetes CRD で GCP リソース管理	GitOps + K8s 環境
Pulumi	汎用言語で IaC	サードパーティ

2. Cloud SQL HA 構成の構築

gcloud での例（MySQL HA）

gcloud sql instances create my-mysql-prod \
  --database-version=MYSQL_8_0 \
  --tier=db-n1-standard-4 \
  --region=asia-northeast1 \
  --availability-type=REGIONAL \      # ← HA を有効化
  --enable-bin-log \                  # ← PITR を有効化
  --backup-start-time=02:00 \
  --storage-type=SSD \
  --storage-size=100GB \
  --storage-auto-increase

Terraform での例（PostgreSQL HA）

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
      private_network = google_compute_network.main.id
    }

    insights_config {
      query_insights_enabled  = true
      query_string_length     = 1024
      record_application_tags = true
      record_client_address   = true
    }
  }

  deletion_protection = true
}

主要パラメータ解説

パラメータ	説明	推奨値
`availability_type`	`ZONAL`(1ゾーン) / `REGIONAL`(HA)	本番は `REGIONAL`
`tier`	マシンタイプ（vCPU/RAM）	ワークロードに応じて
`backup_configuration.enabled`	自動バックアップ	true
`point_in_time_recovery_enabled`	PITR	true
`transaction_log_retention_days`	binary log 保持	7〜35
`ip_configuration.ipv4_enabled`	Public IP	本番は false
`private_network`	Private IP の VPC	本番は VPC 指定
`deletion_protection`	誤削除防止	本番は true

3. リードレプリカの構築

gcloud での例

# 同一リージョン リードレプリカ
gcloud sql instances create my-mysql-replica1 \
  --master-instance-name=my-mysql-prod \
  --region=asia-northeast1 \
  --tier=db-n1-standard-2

# クロスリージョン リードレプリカ
gcloud sql instances create my-mysql-dr \
  --master-instance-name=my-mysql-prod \
  --region=us-central1 \
  --tier=db-n1-standard-2

Terraform での例

resource "google_sql_database_instance" "replica" {
  name                 = "my-postgres-replica1"
  database_version     = "POSTGRES_15"
  region               = "asia-northeast1"
  master_instance_name = google_sql_database_instance.main.name

  replica_configuration {
    failover_target = false   # クロスリージョン DR には不要
  }

  settings {
    tier              = "db-custom-2-7680"
    availability_type = "ZONAL"   # レプリカは ZONAL でも可（コスト削減）

    ip_configuration {
      ipv4_enabled    = false
      private_network = google_compute_network.main.id
    }
  }
}

リードレプリカの種類

種類	用途
同期スタンバイ（HA の片割れ）	Primary の自動フェイルオーバー先
同期リードレプリカ	読み取り分散、強整合
非同期リードレプリカ	読み取り分散、軽い遅延OK
クロスリージョンリードレプリカ	DR、リージョン障害対策

4. AlloyDB のデプロイ

gcloud での例

# クラスタ作成（プライマリ）
gcloud alloydb clusters create my-cluster \
  --region=asia-northeast1 \
  --network=projects/my-project/global/networks/my-vpc \
  --password=initial-password

# プライマリインスタンス作成
gcloud alloydb instances create primary \
  --cluster=my-cluster \
  --instance-type=PRIMARY \
  --cpu-count=4 \
  --region=asia-northeast1

# Read Pool 作成（読み取り専用ノード）
gcloud alloydb instances create read-pool-1 \
  --cluster=my-cluster \
  --instance-type=READ_POOL \
  --read-pool-node-count=3 \
  --cpu-count=2 \
  --region=asia-northeast1

AlloyDB Secondary Cluster（DR）

gcloud alloydb clusters create my-cluster-dr \
  --region=asia-northeast2 \
  --secondary-config-primary-cluster=projects/.../clusters/my-cluster

5. Spanner のデプロイ

gcloud での例

# Regional インスタンス
gcloud spanner instances create my-spanner \
  --config=regional-asia-northeast1 \
  --processing-units=1000 \
  --description="Production Spanner"

# Multi-regional インスタンス（5ナイン SLA）
gcloud spanner instances create my-spanner-multi \
  --config=nam3 \              # asia-northeast の場合は asia2 など
  --processing-units=1000

Spanner の主要な config

Config	範囲
`regional-asia-northeast1`	東京リージョン内
`regional-us-central1`	米国中部
`nam3`	Multi-region: 北米（複数リージョン）
`eur3`	Multi-region: ヨーロッパ
`asia1`	Multi-region: 東京 + 大阪
`asia2`	Multi-region: 東京 + 香港

Terraform での例

resource "google_spanner_instance" "main" {
  name             = "my-spanner"
  config           = "regional-asia-northeast1"
  display_name     = "Production"
  processing_units = 1000
}

resource "google_spanner_database" "main" {
  instance = google_spanner_instance.main.name
  name     = "my-db"

  ddl = [
    "CREATE TABLE Users (UserId INT64 NOT NULL, Name STRING(MAX)) PRIMARY KEY (UserId)"
  ]

  deletion_protection = true
}

6. Bigtable のデプロイ

gcloud での例

# Single-cluster
gcloud bigtable instances create my-bigtable \
  --display-name="Production Bigtable" \
  --cluster=cluster-1 \
  --cluster-zone=asia-northeast1-a \
  --cluster-num-nodes=3 \
  --cluster-storage-type=SSD

# Multi-cluster (HA + DR)
gcloud bigtable instances create my-bigtable-ha \
  --display-name="HA Bigtable" \
  --cluster=cluster-1 \
  --cluster-zone=asia-northeast1-a \
  --cluster-num-nodes=3 \
  --cluster-storage-type=SSD

gcloud bigtable clusters create cluster-2 \
  --instance=my-bigtable-ha \
  --zone=asia-northeast2-a \
  --num-nodes=3 \
  --storage-type=SSD

マルチクラスタルーティングの設定

App Profile で multi_cluster_routing を設定
アプリは透過的にクラスタを切り替え（障害時自動フェイルオーバー）

7. Firestore のデプロイ

gcloud での例

# Native モード（推奨）+ Multi-region
gcloud firestore databases create \
  --database='(default)' \
  --location=nam-eur-asia1 \      # Multi-region
  --type=firestore-native

Firestore のロケーション選定

Type	ロケーション
Regional	asia-northeast1 など単一リージョン
Multi-region	nam5 (米国)、eur3 (欧州)、asia1 (アジア)

8. フェイルオーバー試験（DR ドリル）

試験の目的

設計通りに動作するかを確認
復旧手順を関係者で再確認
想定外の問題を早期発見

Cloud SQL HA フェイルオーバー試験

# 手動フェイルオーバー
gcloud sql instances failover my-mysql-prod

# 動作確認
# 1. アプリから接続できるか
# 2. 書き込みができるか
# 3. データ整合性が保たれているか
# 4. フェイルオーバー時間（数十秒〜数分）を計測

Spanner Multi-region フェイルオーバー

自動フェイルオーバー（Paxos ベース）
試験不要（Google 側で常に動作確認済み）
アプリは透過的に動作継続

Bigtable Multi-cluster ルーティング試験

# クラスタの状態を意図的に変更
gcloud bigtable clusters update cluster-1 \
  --instance=my-bigtable-ha \
  --num-nodes=0      # ← クラスタ縮退（実質障害シミュレーション）

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

パターン 1: GitOps（Terraform + GitHub Actions）

Pull Request 作成
   ↓
GitHub Actions で terraform plan
   ↓
レビュー + 承認
   ↓
merge → terraform apply（自動）
   ↓
Cloud SQL/AlloyDB/Spanner 更新

パターン 2: Cloud Build パイプライン

git push
   ↓
Cloud Build トリガー
   ↓
terraform plan / apply
   ↓
通知（Slack）

パターン 3: Workload Identity Federation

CI/CD のサービスアカウント鍵を不要に
GitHub OIDC → Google Cloud の SA を借りる
セキュリティ強化（鍵漏洩リスクなし）

10. 監視設定の自動化

Cloud Monitoring の Alert Policy を 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 metric.type=\"cloudsql.googleapis.com/database/cpu/utilization\""
      duration        = "300s"
      comparison      = "COMPARISON_GT"
      threshold_value = 0.8

      aggregations {
        alignment_period   = "60s"
        per_series_aligner = "ALIGN_MEAN"
      }
    }
  }

  notification_channels = [google_monitoring_notification_channel.slack.id]
}

Alert Policy のベストプラクティス

環境ごとに別 Policy（dev/stg/prod）
通知チャネルを階層化（警告 → Slack、致命的 → PagerDuty）
ドキュメント URL をアラート本文に含める

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

IaC の利点を 4 つ言える
Cloud SQL の availability_type=REGIONAL の意味が分かる
gcloud で Cloud SQL HA を構築できる
Terraform で Cloud SQL/AlloyDB/Spanner を定義できる
リードレプリカの 4 種類を区別できる
AlloyDB の Read Pool の役割を説明できる
Spanner の Regional / Multi-regional config の違いが分かる
Bigtable のマルチクラスタルーティングを設定できる
Firestore の Multi-region ロケーションを言える
フェイルオーバー試験の目的と手順を説明できる
Cloud Monitoring Alert を Terraform で定義できる

Section 4 — 基礎編：HA 構成のプロビジョニングと運用テスト

1. なぜ IaC（Infrastructure as Code）か

手動構築の問題点

IaC の利点

Google Cloud の IaC ツール

2. Cloud SQL HA 構成の構築

gcloud での例（MySQL HA）

Terraform での例（PostgreSQL HA）

主要パラメータ解説

3. リードレプリカの構築

gcloud での例

Terraform での例

リードレプリカの種類

4. AlloyDB のデプロイ

gcloud での例

AlloyDB Secondary Cluster（DR）

5. Spanner のデプロイ

gcloud での例

Spanner の主要な config

Terraform での例

6. Bigtable のデプロイ

gcloud での例

マルチクラスタ ルーティングの設定

7. Firestore のデプロイ

gcloud での例

Firestore のロケーション選定

8. フェイルオーバー試験（DR ドリル）

試験の目的

Cloud SQL HA フェイルオーバー試験

Spanner Multi-region フェイルオーバー

Bigtable Multi-cluster ルーティング試験

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

パターン 1: GitOps（Terraform + GitHub Actions）

パターン 2: Cloud Build パイプライン

パターン 3: Workload Identity Federation

10. 監視設定の自動化

Cloud Monitoring の Alert Policy を Terraform で

Alert Policy のベストプラクティス

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

マルチクラスタルーティングの設定