Section 1 — 基礎編：クラウドDBソリューションの設計
📘 対象: 新人〜全レベル（必読）
ゴール: GCP の DB サービス11種類の 役割と使い分け を即答できるようになる。
1. GCP データベースサービス全体図
GCP の DB サービスは「型」と「ワークロード」で分類できます。試験では最初にこの分類が頭に入っているかが鍵。
┌─────────────────────────────────────────────────────────────┐
│ トランザクション系（OLTP） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Cloud SQL │ │ AlloyDB │ │ Spanner │ │
│ │ MySQL/PG/ │ │ PostgreSQL │ │ グローバル分散 │ │
│ │ SQL Server │ │ 互換 + AI/ML │ │ 強整合 + 水平 │ │
│ └──────────────┘ └──────────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ NoSQL │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Bigtable │ │ Firestore │ │ Memorystore │ │
│ │ KV/時系列 │ │ ドキュメント │ │ キャッシュ │ │
│ │ >1TB │ │ リアルタイム │ │ Redis/Memcache │ │
│ └──────────────┘ └──────────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 分析系（OLAP） │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ BigQuery │ │
│ │ サーバーレス DWH、ペタバイトスケール、SQL │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ レガシー/特殊 │
│ ┌──────────────────────────┐ ┌──────────────────────┐ │
│ │ Bare Metal Solution │ │ Partner DB │ │
│ │ Oracle/SAP HANA 互換 │ │ MongoDB Atlas / │ │
│ │ 物理サーバー、専用線 │ │ DataStax Astra / 他 │ │
│ └──────────────────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
サービス一覧（早見表）
| サービス |
タイプ |
データモデル |
主用途 |
| Cloud SQL |
リレーショナル |
MySQL / PostgreSQL / SQL Server |
中小規模 OLTP、レガシーアプリ移行 |
| AlloyDB |
リレーショナル |
PostgreSQL 互換 |
高速 PostgreSQL、HTAP、AI/ML、ベクトル検索 |
| Spanner |
リレーショナル |
独自 SQL + PostgreSQL Interface |
グローバル分散 OLTP、強整合、無制限スケール |
| Bigtable |
NoSQL |
ワイドカラム（HBase 互換） |
時系列、IoT、>1TB、低レイテンシ |
| Firestore (Native) |
NoSQL |
ドキュメント |
モバイル/Web、リアルタイム同期 |
| Firestore (MongoDB) |
NoSQL |
ドキュメント（MongoDB API 互換） |
MongoDB 互換が必要なケース |
| Memorystore for Redis |
KV |
Redis |
キャッシュ、セッション、Pub/Sub軽量 |
| Memorystore for Memcached |
KV |
Memcached |
シンプルなキャッシュ |
| Memorystore for Valkey |
KV |
Valkey (Redis フォーク) |
新世代の OSS Redis 互換 |
| BigQuery |
OLAP |
カラムナ SQL |
DWH、分析、ML 連携 |
| Bare Metal Solution |
物理 |
Oracle DB / SAP HANA |
レガシー移行、専用ライセンス |
2. SQL vs NoSQL の使い分け
試験で最も多いのが「SQL か NoSQL か」「どの SQL か」「どの NoSQL か」の判断問題。
SQL を選ぶ条件
- ACID トランザクション が必須（金融、在庫、注文）
- 複雑な JOIN が必要（リレーションが多い）
- 既存アプリが SQL を前提
- 既存スキーマ がリレーショナル
- 強い整合性 が必須
NoSQL を選ぶ条件
- 大量データ（>1TB or 高 QPS）
- スキーマ柔軟性（JSON、半構造化）
- 水平スケール が必要
- 結果整合性で OK
- アクセスパターンが単純（キーで引く、範囲スキャン）
SQL の中の使い分け
| 要件 |
答え |
| 単一リージョン、小〜中規模、MySQL/PG/SQL Server |
Cloud SQL |
| PostgreSQL 互換 + 高速 + AI/ベクトル |
AlloyDB |
| グローバル分散 + 強整合 + 水平スケール |
Spanner |
| Oracle 互換が必須 |
Bare Metal Solution |
NoSQL の中の使い分け
| 要件 |
答え |
| 時系列、IoT、>1TB、KV 高速書き込み |
Bigtable |
| モバイル、リアルタイム同期、オフライン |
Firestore (Native) |
| MongoDB 互換 |
Firestore (MongoDB-compatible) |
| キャッシュ、セッション、リーダーボード |
Memorystore |
3. 高可用性 (HA) の基本概念
用語
- ゾーン (Zone): 1つのデータセンター（実際は複数の建物 1セット）。同一リージョン内に通常 3+ ゾーン
- リージョン (Region): 地理的な拠点（東京、大阪、台湾など）。複数ゾーンの集合
- マルチリージョン: 複数のリージョンにまたがる構成（例: 日本 + 台湾）
- 可用性 SLA: サービスの稼働率の保証（99.95% = 月間ダウンタイム約 22 分）
デプロイ戦略の3段階
| 戦略 |
構成 |
障害許容度 |
SLA 例 |
| Zonal |
単一ゾーン |
ハードウェア障害のみ耐性 |
99.5% |
| Regional (HA) |
同期スタンバイ on 別ゾーン |
ゾーン障害に耐性 |
99.95% |
| Multi-regional |
別リージョンにレプリカ |
リージョン障害に耐性 |
99.99% / 99.999% |
例: Cloud SQL の HA
┌─ Region: asia-northeast1 (東京) ──────────────────┐
│ │
│ Primary (asia-northeast1-a) ──同期──> Standby │
│ ↑ (asia-northeast1-b)│
│ │ │
│ (App) アプリ接続 │
│ │
│ ※ Standby は読み取りも不可（直接接続できない） │
│ ※ プライマリ障害時、自動フェイルオーバー │
└───────────────────────────────────────────────────┘
↓ クロスリージョン リードレプリカ（読み取り専用）
┌─ Region: us-central1 (米国中部) ──────────────────┐
│ Read Replica │
│ ※ 障害時は手動昇格（プロモート）が必要 │
└───────────────────────────────────────────────────┘
4. 災害復旧 (DR) の基本概念
RPO / RTO
- RPO (Recovery Point Objective): 災害発生時、どこまで前のデータに戻ることを許容するか
- RPO = 0 → データロスゼロ（同期レプリ）
- RPO = 1時間 → 直近1時間分のデータ喪失は許容
- RTO (Recovery Time Objective): 災害発生から復旧までの目標時間
- RTO = 数十秒 → 自動フェイルオーバー
- RTO = 数時間 → バックアップからのリストア
PITR (Point-in-Time Recovery)
- 任意の時点（例：3時間前 10:23）に DB の状態を巻き戻す機能
- 仕組み: 直近のフルバックアップ + その後のトランザクションログを適用
- Cloud SQL: 最大 35 日
- Spanner: 最大 7 日（バックアップ自体は 1 年）
5. アプリケーション ⇄ DB 接続の基本
接続方式 4 種類
| 方式 |
経路 |
暗号化 |
推奨度 |
| Public IP + 直接 |
インターネット経由 |
TLS 必須 |
△（開発のみ） |
| Public IP + Auth Proxy |
Auth Proxy 経由 |
自動 TLS + IAM |
○ |
| Private IP |
VPC 内 |
TLS |
◎ |
| Private Service Connect (PSC) |
VPC エンドポイント |
TLS |
◎ |
Cloud SQL Auth Proxy の役割
- TLS 接続を自動で確立
- IAM ベースの認証（証明書管理不要）
- 短命トークン使用
コネクションプーラー
- 大量の短命接続（サーバーレスから）→ DB が枯渇
- 解決: PgBouncer（Postgres）/ ProxySQL（MySQL）/ AlloyDB 組み込みプーラー
- AlloyDB は PgBouncer 相当のプーラーが組み込み
6. IAM の基本構造（DB エンジニア視点）
Cloud IAM の3要素
- Principal（プリンシパル）: ユーザー、グループ、サービスアカウント
- Role（ロール）: 権限の集合（例: roles/cloudsql.admin）
- Resource（リソース）: 適用対象（プロジェクト、インスタンス）
DB エンジニアが使う主要ロール
| ロール |
権限内容 |
roles/cloudsql.admin |
Cloud SQL 完全管理 |
roles/cloudsql.editor |
インスタンス操作（削除不可） |
roles/cloudsql.client |
DB クライアント接続のみ |
roles/cloudsql.instanceUser |
IAM DB認証ユーザー |
roles/spanner.admin |
Spanner 完全管理 |
roles/spanner.databaseUser |
データ読み書き |
roles/bigtable.admin |
Bigtable 完全管理 |
roles/bigtable.user |
読み書きのみ |
IAM DB 認証（Cloud SQL / AlloyDB）
- ユーザー名 = IAM プリンシパル（メールアドレスまたは SA）
- パスワード = 短命トークン（自動取得）
- パスワード管理不要、監査ログ統合、ローテーション不要
7. 暗号化の基本
保管時の暗号化（at rest）
- デフォルト: Google 管理の鍵で常時暗号化（Google-managed encryption keys: GMEK）
- CMEK (Customer-Managed Encryption Keys): 顧客が Cloud KMS で管理する鍵
- メリット: 鍵のローテーション、無効化、削除を顧客側で制御可能
- 監査ログに鍵の使用履歴が記録
- CSEK (Customer-Supplied Encryption Keys): 顧客が鍵自体を提供（GCP 側に保管しない）
- Cloud SQL は CSEK 非対応（CMEK のみ）
転送中の暗号化（in transit）
- すべて TLS で自動暗号化（Auth Proxy 経由含む）
- Private IP でも VPC 内通信は暗号化
8. このセクションのチェックリスト