Section 1 — 応用編：意思決定とトレードオフ
🔧 対象: 中堅以上（基礎が頭に入っている前提）
ゴール: シナリオから 最適な DB と構成を選定 し、コスト・性能・可用性のトレードオフを説明できる。
1. 完全版 DB 意思決定ツリー
試験で最も問われるのが「シナリオ → DB 選択」。次のツリーを丸暗記して、シナリオに当てはめる。
スタート: アプリの要件は?
│
├─ Q1: トランザクション (ACID) が必要?
│ │
│ YES（OLTP系）─────────────────────────────────────────────
│ │
│ ├─ Q2: グローバル分散 + 強整合 が必要?
│ │ YES → 【Spanner】
│ │ ├─ PostgreSQL アプリ → Spanner PostgreSQL Interface
│ │ └─ 新規開発 → Spanner Native (GoogleSQL)
│ │
│ ├─ Q3: PostgreSQL 互換 + HTAP/AI が必要?
│ │ YES → 【AlloyDB for PostgreSQL】
│ │ ├─ ColumnarEngine（分析高速化）
│ │ ├─ Vector Search（pgvector + ScaNN）
│ │ └─ Index Advisor（自動推奨）
│ │
│ ├─ Q4: Oracle / SAP HANA など物理 DB ?
│ │ YES → 【Bare Metal Solution】
│ │ ├─ Oracle Exadata 互換
│ │ └─ SAP HANA 認定
│ │
│ └─ それ以外（標準 OLTP）→ 【Cloud SQL】
│ ├─ MySQL → Cloud SQL for MySQL
│ ├─ PostgreSQL → Cloud SQL for PostgreSQL
│ └─ SQL Server → Cloud SQL for SQL Server
│
└─ NO（NoSQL系）─────────────────────────────────────────────
│
├─ Q5: データ量 > 1TB + 高 QPS + 時系列/IoT ?
│ YES → 【Bigtable】
│ ├─ HDD: バックアップ・低頻度アクセス
│ ├─ SSD: 通常運用（試験ではほぼこれ）
│ └─ マルチクラスタ ルーティング: HA 構成
│
├─ Q6: モバイル/Web + リアルタイム同期?
│ YES → 【Firestore】
│ ├─ Native モード: 新規アプリ
│ ├─ Datastore モード: レガシー互換
│ └─ MongoDB-compatible: MongoDB アプリ移行
│
├─ Q7: キャッシュ / セッション / リーダーボード?
│ YES → 【Memorystore】
│ ├─ Redis: 多機能、永続化、Pub/Sub
│ ├─ Memcached: シンプルなキャッシュ
│ └─ Valkey: 新世代 OSS Redis 互換
│
└─ Q8: 分析・DWH?
YES → 【BigQuery】
├─ Federated Query: 外部DB をリアルタイム参照
└─ BigQuery ML: SQL でML
2. 「Cloud SQL Enterprise vs Enterprise Plus」の判断
Cloud SQL は 2 つの Edition があります。試験で頻出。
| 観点 |
Enterprise |
Enterprise Plus |
| 最大 vCPU |
96 |
128 |
| 最大 RAM |
624 GB |
864 GB |
| Data Cache |
なし |
あり（NVMe） |
| Near-Zero Downtime メンテナンス |
なし |
あり |
| ローカル SSD |
なし |
あり |
| バックアップ高速化 |
普通 |
増分高速化 |
| 価格 |
標準 |
約 1.5-2 倍 |
| 推奨ワークロード |
通常 OLTP |
高 QPS / 低レイテンシ要求 / 厳しいダウンタイム要件 |
判断軸
- 「高性能を最大限引き出したい」 → Enterprise Plus
- 「メンテナンスダウンタイムを限りなくゼロにしたい」 → Enterprise Plus
- 「コスト効率重視」 → Enterprise
- 「シングルインスタンス開発環境」 → Enterprise
3. AlloyDB の特徴と選定基準
AlloyDB が選ばれるシナリオ
| シナリオ |
なぜ AlloyDB? |
| 既存 PostgreSQL を移行したい + 性能を上げたい |
PostgreSQL 互換 + 4倍速 |
| 同じ DB で OLTP + 分析（HTAP）したい |
ColumnarEngine で分析高速化 |
| AI/LLM の RAG パイプラインで使う |
pgvector + ScaNN インデックス |
| 自動チューニングしたい |
Index Advisor, Auto Vacuum 改善 |
| マネージドで完全分離コンピュートを使いたい |
Read Pool（読み取り専用ノード） |
AlloyDB のアーキテクチャ
┌─ Region: asia-northeast1 ─────────────────────────────────┐
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Primary Instance (Writer + Read) │ │
│ │ ColumnarEngine (column store) │ │
│ └────────────────────────────────────────────────────┘ │
│ ↓ ログレプリ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Read Pool (1〜N nodes, 読み取り専用) │ │
│ │ Standby │ │
│ └────────────────────────────────────────────────────┘ │
│ ↓ 共有ストレージ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Cluster Storage（Continuous backup, PITR） │ │
│ └────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────┘
↓ クロスリージョン
┌─ Region: asia-northeast2 (DR用) ──────────────────────────┐
│ Secondary Cluster（読み取り + DR） │
└────────────────────────────────────────────────────────────┘
AlloyDB vs Cloud SQL の使い分け
| シナリオ |
推奨 |
| PostgreSQL + 標準ワークロード + コスト重視 |
Cloud SQL for PostgreSQL |
| PostgreSQL + 高性能 + HTAP + AI |
AlloyDB |
| MySQL / SQL Server |
Cloud SQL のみ |
4. Spanner の特徴と選定基準
Spanner が選ばれる絶対条件
- グローバル分散 + 強整合 + 無制限の水平スケール を全部満たすのは Spanner だけ
Spanner サイジング: Processing Units (PU)
- 100 PU = 1/10 ノード ≒ 約 10,000 QPS
- 最小 100 PU から 100 PU 刻みで増減
- 1000 PU 以上で 1ノード相当（運用上はノード単位の上限なし）
スキーマ設計のキーポイント
1. Interleaving（親子テーブル）
- 親レコードと子レコードを 物理的に同じスプリット に配置 → JOIN が高速
- 例:
Customer と Order、Order と OrderItem
CREATE TABLE Customer (
CustomerId INT64 NOT NULL,
Name STRING(MAX)
) PRIMARY KEY (CustomerId);
CREATE TABLE Order (
CustomerId INT64 NOT NULL,
OrderId INT64 NOT NULL,
Total NUMERIC
) PRIMARY KEY (CustomerId, OrderId),
INTERLEAVE IN PARENT Customer ON DELETE CASCADE;
2. ホットスポット回避
- 連番（タイムスタンプ、シーケンス）の主キー → 末尾スプリットに集中 → 性能劣化
- 解決: UUID または タイムスタンプ反転（
9999999999 - ts）
Spanner の SLA
- Regional: 99.99%
- Multi-regional: 99.999%（5ナイン）
5. Bigtable のスキーマ設計
行キー設計が 100% を決める
NG パターン
行キー: sensor1_2026-05-29-12:00:00
sensor1_2026-05-29-12:00:01
sensor1_2026-05-29-12:00:02
→ 同一センサーの書き込みが順次同じ行範囲に集中 → ホットスポット
OK パターン
行キー: 2026-05-29-12:00:00_sensor1
2026-05-29-12:00:00_sensor2
2026-05-29-12:00:00_sensor3
→ 異なるセンサーが同時刻でも別の行範囲に分散
より良いパターン（高 QPS）
行キー: 1#2026-05-29-12:00:00 ← ハッシュプレフィックス（0-N）
2#2026-05-29-12:00:00
...
→ 書き込みが N 個の行範囲に均等分散
HDD vs SSD
| 用途 |
選定 |
| バックアップ / アーカイブ / 低レイテンシ不要 |
HDD（コスト 1/4） |
| 通常のOLAP / リアルタイム参照 |
SSD |
マルチクラスタ ルーティング
- 別リージョン/ゾーンに複数クラスタを配置 → ルーティングで HA + 低レイテンシ
- Single-cluster routing: 障害時は手動切り替え
- Multi-cluster routing: 自動フェイルオーバー（SLA 99.999%）
6. Firestore Native vs Datastore vs MongoDB
Firestore の 3 つの「モード」
| モード |
用途 |
API |
リアルタイム同期 |
| Native |
新規アプリ |
Firestore SDK |
あり（Web/モバイル） |
| Datastore |
レガシー互換 |
Datastore API |
なし |
| MongoDB-compatible |
MongoDB 互換 |
MongoDB Wire Protocol |
あり |
試験ポイント
- 新規 → Native
- MongoDB アプリ移行 → MongoDB-compatible
- 既存 Datastore → Datastore モード
Firestore の SLA
- Multi-region: 99.999%（5ナイン）
7. Memorystore の使い分け
3 種類
| エンジン |
特徴 |
推奨用途 |
| Redis |
永続化、データ構造（List/Set/Hash/Sorted Set）、Pub/Sub、Lua |
キャッシュ + リーダーボード + Pub/Sub軽量 |
| Memcached |
シンプル KV、永続化なし |
純粋なキャッシュ |
| Valkey |
Redis フォーク（OSS）、Redis 互換 |
新規 OSS 戦略 |
Tier (Redis のみ)
| Tier |
用途 |
SLA |
| Basic |
キャッシュのみ（再起動でデータ消失） |
なし |
| Standard |
リードレプリカ付き、HA |
99.9% |
| Cluster |
Cluster モード、シャーディング |
99.9% |
8. Bare Metal Solution (BMS)
いつ使うか
- Oracle DB を移行したい + 互換性100%が必要
- SAP HANA の認定構成が必要
- 物理ハードウェア + 専用ライセンスが必要
- マネージド DB へのリフトアンドシフトが困難
構造
- Google のデータセンター内に 物理サーバー を配置
- VPC との 専用低レイテンシ接続（〜2ms）
- マネージドではないが、ハードウェア管理は Google 側
注意
- マネージド DB ではない → OS, DB のパッチ・バックアップは顧客責任
- Cloud SQL や AlloyDB と異なり、PITR や自動バックアップなし
9. パートナー DB
よく問われるパートナー DB
| パートナー |
用途 |
| MongoDB Atlas on Google Cloud |
フルマネージド MongoDB |
| DataStax Astra DB |
フルマネージド Cassandra |
| Neo4j Aura |
グラフ DB |
| Redis Enterprise |
エンタープライズ向け Redis |
| InfluxDB Cloud |
時系列 DB |
試験での扱い
- パートナー DB の詳細は深く問われない
- ただし「ある特定の DB エンジンが必要」と言われたら、ネイティブ機能 + パートナーオプション を比較できることが重要
10. 接続方式の応用：Private Service Connect (PSC)
PSC が解決する問題
- VPC ピアリングは IP アドレスの重複 に弱い、推移的ピアリング不可
- PSC は エンドポイント（IP アドレス）として消費 → 重複しない、推移的可能
Cloud SQL での PSC
[Service Producer VPC] [Service Consumer VPC（顧客）]
┌─────────────────┐ ┌─────────────────┐
│ Cloud SQL │ <── PSC ──── 仮想IP（10.x.x.x） │
│ インスタンス │ │ App │
└─────────────────┘ └─────────────────┘
PSC vs Private IP vs Auth Proxy
| 方式 |
VPC ピアリング |
IP 重複耐性 |
推奨度 |
| Private IP |
必要 |
弱い |
○ |
| PSC |
不要 |
強い |
◎ |
| Auth Proxy |
不要（Public IP 使用） |
- |
△ |
試験パターン
- 「複数 VPC にまたがる接続 + IP 重複の可能性」 → PSC
- 「単純な VPC 内接続」 → Private IP
- 「サーバーレス（Cloud Run, Cloud Functions）から接続」 → Cloud SQL Auth Proxy または Serverless VPC Access + Private IP
11. 規制・コンプライアンス対応
試験で問われる典型要件
| 要件 |
対応 |
| データレジデンシー（特定地域に保管） |
リージョン指定 + 組織ポリシー（gcp.resourceLocations） |
| 暗号化キーを顧客管理 |
CMEK（Cloud KMS） |
| アクセス監査 |
Cloud Audit Logs（Admin Activity + Data Access） |
| PII マスキング |
Cloud DLP（Sensitive Data Protection） |
| ネットワーク隔離 |
VPC Service Controls |
| HIPAA / PCI-DSS |
コンプライアンス対応サービスを選定（多くは対応済み） |
データレジデンシーの落とし穴
- マルチリージョン は 複数リージョンにデータが分散 → データレジデンシー要件と矛盾する場合あり
- 解決: Regional に変更 + 組織ポリシーで他リージョンへの作成を禁止
12. AI / LLM ユースケースへの対応
よく問われるパターン
パターン1: RAG（検索拡張生成）
[ユーザー質問]
↓
[Vertex AI Embeddings API]（質問をベクトル化）
↓
[AlloyDB + pgvector]（類似ベクトル検索）
↓
[Vertex AI Gemini]（コンテキスト + 質問でレスポンス生成）
↓
[ユーザーへ回答]
パターン2: ベクトル DB 選択
| 選択肢 |
推奨シナリオ |
| AlloyDB + pgvector |
既存 PostgreSQL アプリ、SQL でクエリしたい |
| Cloud SQL for PostgreSQL + pgvector |
小〜中規模、コスト重視 |
| Vertex AI Vector Search |
専用 ANN サービス、超高速・大規模 |
| BigQuery + ML.GENERATE_EMBEDDING |
分析統合、BigQuery 内で完結 |
| Spanner + Vector Index |
グローバル分散 + ベクトル |
13. このセクションのチェックリスト