1. アーキテクチャ概観
Cloud SQL は Google Cloud のフルマネージド リレーショナル DB サービス。MySQL / PostgreSQL / SQL Server の 3 エンジンを提供。アーキテクチャ的には Compute Engine VM 上にエンジンを動かす設計だが、マネージドサービスとして VM へのアクセスは閉ざされている。
Compute
Primary Instance
- vCPU + RAM (マシンタイプ)
- Read / Write 両対応
- アプリの接続先
Storage
Regional Persistent Disk
- 2 ゾーン同期レプリ
- SSD or HDD
- 自動増加可能
Compute (HA only)
Standby Instance
Optional
Read Replica
- 非同期 (or 同期)
- 同/別リージョン
- 読み取り分散
🏗 Cloud SQL データ永続化の鍵: HA 構成では Regional Persistent Disk を使用。すべての書き込みは 2 つのゾーンの永続ディスクへ同期的に書き込まれた後で初めて commit 完了 として応答される（synchronous replication to each zone's persistent disk）。
2. HA 構成の内部メカニズム
2-1. 同期スタンバイの実態
Cloud SQL HA は マスター/スレーブのストリーム複製ではなく、ストレージ層レベルの同期複製 です。これは MySQL/PG の論理レプリではなく Regional Persistent Disk の物理書き込み複製 による実装で、データロスゼロを保証する根拠になっています。
アプリ (write クエリ)
│
▼
┌──────────────────┐
│ Primary Instance │ (zone-a)
│ PG/MySQL │
└────────┬─────────┘
│ I/O 発行
▼
┌─────────────────────┐
│ Regional Persistent │
│ Disk (zone-a + b) │ ← 2ゾーン同期書き込み完了を待って commit
└─────────────────────┘
▲
│ 障害時のみ Standby が引き継ぎ
┌────────┴─────────┐
│ Standby Instance │ (zone-b)
│ (idle, ヒート) │
└──────────────────┘
Standby に直接接続することはできない。「読み取りスケールをしたい」というシナリオで「Standby を使う」を選ぶと不正解。読み取り分散は Read Replica の役割（インスタンスが別に必要）。
2-2. ヘルスチェック
Cloud SQL は 毎秒のハートビート（heartbeat detection occurring each second）でインスタンスの健全性を監視。複数回連続でハートビートが失敗すると自動フェイルオーバーがトリガーされる。
3. フェイルオーバーのタイムライン
-
0s — 障害発生
Primary インスタンスが応答しなくなる。アプリの既存接続は徐々にタイムアウト。
-
〜数秒 — 検知
連続ハートビート失敗で Cloud SQL コントロールプレーンが障害を確定。
-
〜30s — 切替準備
Standby が Regional Persistent Disk をマウントし、PostgreSQL/MySQL を起動。クラッシュリカバリ実行。
-
〜60s — 完了
shared static IP address を Standby が引き継ぎ、アプリは同じ接続文字列で再接続可能に。RPO=0 / RTO≒60s
-
〜数分 — 新 Standby 作成
元の Primary は廃棄され、別のゾーンに新しい Standby が自動構築される。再度 HA 状態に戻る。
公式ダウンタイム目安
~60s
"about sixty seconds"
フェイルオーバーが ブロックされる 条件
- Primary が 長時間オペレーション（マイグレーション、サイズ変更）中
- Primary が 停止状態 または メンテナンス中
- Standby ゾーン自体が障害
- Standby が応答不能
試験で「Cloud SQL HA だから障害時は無条件にフェイルオーバーする」を選ぶと不正解。Standby の健全性が前提条件。アプリ側は ConnectionResetError の再試行ロジックを必ず実装すること。
4. Enterprise vs Enterprise Plus 完全比較
| 項目 | Enterprise | Enterprise Plus | 備考 |
|---|
| 最大 vCPU |
96 (N4) |
128 (N2) / 72 (C4A) |
N2 系のみ 128 まで |
| 最大 RAM |
624 GB |
864 GB |
1:8 比率 |
| Data Cache (NVMe) |
なし |
あり (最大 4倍読み取り改善) |
ローカル SSD を読み取りキャッシュとして利用 |
| Near-Zero Downtime メンテナンス |
~30秒 |
sub-second（<1秒） |
パッチ・マイナーのみ。メジャーは対象外 |
| 計画オペレーション |
数分 |
sub-second |
スケール変更・フェイルオーバーなど |
| 書き込みレイテンシ |
標準 |
2x 改善 |
Hyperdisk 技術 |
| ストレージ |
Persistent Disk |
Hyperdisk |
IOPS・スループットが個別調整可 |
| PITR トランザクションログ保持 |
最大 7日 |
最大 35日 |
⚠️公式ドキュメント記載値 |
| 価格 |
標準 |
約 1.5〜2x |
Edition による課金 |
選定ガイド：「メンテダウンタイムを 10 秒以下に抑えたい」「読み取り 4 倍速」「PITR 35 日が必要」これらいずれか 1 つでも該当すれば Enterprise Plus。それ以外は Enterprise でコスト最適化。
PITR 35日は Enterprise Plus 限定。Enterprise の最大は 7日。試験で「Enterprise で 30 日 PITR」が選択肢にあったら 除外。
5. PITR と Binary Log の仕組み
Point-in-Time Recovery は 「直近フルバックアップ + その後のトランザクションログ」 の組み合わせで実現される。任意の時点（秒単位）まで巻き戻し可能。
時系列 →
日次バックアップ (T0)
│
▼
┌─────────┐ binary log / WAL を継続記録
│ baseline│ ───────────────────────────────────► 現在
└─────────┘ ↑ ↑ ↑
T1 T2 T3
（任意の時点に巻き戻し可能）
リストア手順：
1. ベースバックアップを別インスタンスに復元
2. T1 までの binary log/WAL を再生 → T1 時点の状態
PITR 有効化 → MySQL の場合 binary log を ON（PostgreSQL は WAL Archiving）。binary log は時間とともに容量が増えるため、保持期間 = ストレージコスト。
| DB | PITR 最大保持 | バックアップ最大保持 | 備考 |
|---|
| Cloud SQL Enterprise | 7 日 | 365 日 | デフォルト 7 日自動バックアップ |
| Cloud SQL Enterprise Plus | 35 日 | 365 日 | 長期 PITR が必要なら Plus |
| AlloyDB | 35 日 (Continuous Backup) | 365 日 | 連続バックアップ標準装備 |
| Spanner | 7 日 | 365 日 | Backup は別途 |
| Firestore | 7 日 | — | Native モード |
「バックアップから PITR で復元」と聞かれた時に注意：PITR は元のインスタンスへの上書きではなく、新しいインスタンスとして復元される。アプリの接続文字列を切り替える必要があるため、運用手順に組み込む。
6. 接続方式の選定マトリクス
| 方式 | 暗号化 | IAM | VPC | 用途 |
|---|
| Public IP 直接 |
手動 TLS |
なし |
不要 |
開発・PoC |
| Public IP + Auth Proxy |
自動 TLS |
あり |
不要 |
開発・サーバーレス |
| Private IP |
自動 TLS |
DB ロール |
必要 (Peering) |
本番標準 |
| Private IP + Auth Proxy |
自動 TLS |
あり |
必要 |
本番 + IAM 認証 |
| Private Service Connect (PSC) |
自動 TLS |
あり |
VPC エンドポイント |
マルチ VPC, IP 重複耐性 |
2026年現在の推奨は PSC + IAM DB認証。VPC ピアリングよりも IP 重複耐性が高く、推移的接続不可問題も解決。複数の顧客 VPC からアクセスする SaaS には必須。
7. スケーリングの限界と移行判断
Cloud SQL は 垂直スケール（マシンタイプアップ）が基本。水平スケールは リードレプリカ追加のみで、書き込みは Primary 1台に集中する。
Cloud SQL の物理的な上限: vCPU 128（Enterprise Plus）、RAM 864GB、ストレージ 64TB（PostgreSQL/MySQL）。これを超える要件は Cloud SQL では対応不可。
「Cloud SQL → 別 DB」への移行判断シグナル
- 書き込み QPS が 30K を超えてくる → Spanner 検討
- OLTP + 同 DB で分析（OLAP）も実行したい → AlloyDB
- グローバル分散 + 強整合が必要 → Spanner Multi-region
- キャッシュレイヤーが必要 → Memorystore を前段に
8. 試験で問われる落とし穴 / リスク TOP 10
- Storage Auto-Increase は縮小不可。一度増えたら別インスタンスへの移行が必要。
- メジャーバージョンアップのインプレースはロールバック不可。Blue-Green + DMS が安全。
- Cross-region Read Replica の Promote は手動のみ。自動フェイルオーバーは同一リージョン内（HA）のみ。
- CMEK 鍵を無効化するとインスタンス停止。鍵削除には待機期間あり（KMS の destroy schedule）。
- Standby インスタンスへの直接接続不可。読み取り分散には別途 Read Replica が必要。
- Cloud SQL は CSEK 非対応。顧客鍵管理は CMEK のみ。
- Cross-region Replica の昇格後、旧 Primary はレプリカに戻らない。手動で再構築。
- Auto Storage Increase 無効 + ストレージ満杯 → DB ダウン。本番では必ず有効化。
- サーバーレスからの大量接続は枯渇する。Cloud Run/CF + PgBouncer or Auth Proxy 必須。
- SQL Server は BYOL 対応（既存ライセンス持ち込み可）。試験で「license-included のみ」は罠。