1. リソース階層
AlloyDB は 3 階層構造でリソースを管理する。Cloud SQL の「インスタンス」単一階層とは大きく異なる。
┌────────────────────────────────────────────────────────────┐
│ Cluster (リージョン単位) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Primary Instance ─ Node A1 (read/write) ││
│ │ Node A2 (HA standby, 同期) ││
│ └─────────────────────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Read Pool Instance 1 ─ Node B1, B2, B3 ... BN ││
│ │ (読み取り専用、自動ロードバランス) ││
│ └─────────────────────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Read Pool Instance 2 ─ Node C1, C2 ... ││
│ │ (別 Read Pool。アプリ毎に分離可能) ││
│ └─────────────────────────────────────────────────────────┘│
│ ↕↕↕ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Distributed Storage Layer (共有) ││
│ │ Continuous Backup + PITR ││
│ └─────────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────────┘
↓ 非同期レプリ (クロスリージョン)
┌────────────────────────────────────────────────────────────┐
│ Secondary Cluster (別リージョン、DR + 読み取り) │
└────────────────────────────────────────────────────────────┘
Cluster = top-level logical container（リージョン単位）
Instance = connection point with static private IP（primary or read pool）
Node = virtual machine running the database engine（実際のコンピュート）
公式: AlloyDB Overview
2. Disaggregated Storage — Cloud SQL との根本的違い
AlloyDB の最大の特徴は コンピュートとストレージの完全分離。これにより以下が実現される。
Compute Layer
- クエリ処理 VM
- マシンタイプを自由に変更可能
- HA, Read Pool は独立スケール
Distributed Storage
- 複数 AZ にまたがる分散層
- Log-structured, Append-only
- WAL を 4 つのコピーで保管
Block Cache
- Ultra-fast cache (PG buffer)
- Compute Node 内に確保
- 頻繁アクセスデータの高速化
Cloud SQL との本質的な違い: Cloud SQL は マスター・スレーブ構成 + Persistent Disk。AlloyDB は 分散ストレージ + 計算層独立スケール。これによりRead Pool 追加でコンピュートだけ水平スケールできる。
性能向上の根拠（公式）
トランザクション処理
4x
vs 標準 PostgreSQL
分析クエリ
100x
Columnar Engine 有効時
メンテダウンタイム
<1s
Primary instance
3. Columnar Engine の仕組み
通常の PostgreSQL は 行指向（row-store）。これは OLTP（小さな読み書きが多い）に最適だが、集計クエリ（SUM, AVG, COUNT のように特定列を全件スキャン）は遅い。Columnar Engine は 同じデータを列指向（column-store）で保管し、自動的に分析クエリへ列指向の結果を返す。
通常 PostgreSQL (Row Store)
┌──────────────────────────────┐
│ Row1: id=1, name=Alice, age=30 │ 集計クエリでも
│ Row2: id=2, name=Bob, age=25 │ 全行スキャン要 (遅い)
│ Row3: id=3, name=Carol, age=28 │
└──────────────────────────────┘
↓ AlloyDB 自動追加
Columnar Engine (Column Store, In-memory)
┌──────────────────────────────┐
│ Col(id): [1, 2, 3] │ 集計クエリは
│ Col(name): [Alice, Bob, Carol] │ 列単位スキャン (100倍高速)
│ Col(age): [30, 25, 28] │
└──────────────────────────────┘
仕組み:
- 行指向の原本は常に保持 (OLTP 用)
- AlloyDB が自動で「分析に使われる列」を検知
- In-memory に列ストア形式で複製
- クエリプランナが自動的に列ストアを利用
有効化方法: google_columnar_engine.enabled = on + Recommended Tables 機能で自動推薦。Cloud SQL for PostgreSQL では使えない、AlloyDB 専用機能。
4. AlloyDB AI — RAG のためのフルスタック
公式ドキュメントが明示する AI/ML 拡張は 4 つ。
| 拡張 | 機能 | 用途 |
|---|
vector |
埋め込みベクトル型 + 距離関数 |
セマンティック検索の土台 (pgvector 互換) |
alloydb_scann |
高速 ANN インデックス (Tree-AH) |
大規模ベクトル検索 (pgvector の HNSW より高速) |
google_ml_integration |
Vertex AI モデル呼び出し SQL 関数 |
SELECT 内で Gemini/Embeddings を直接呼ぶ |
alloydb_ai_nl |
自然言語 → SQL 変換 |
「先月の売上 TOP10」を SQL に |
RAG パイプライン例（AlloyDB 完結）
① ユーザー質問（テキスト）
│
▼ SELECT embedding('text-embedding-005', '質問文') -- google_ml_integration
[Vertex AI Embeddings] ───────► [質問ベクトル]
│
▼ SELECT ... ORDER BY vec <-> $1 LIMIT 5
[AlloyDB + scann index]
類似文書 TOP5 を返却
│
▼ SELECT google_ml.predict_row(...)
[Vertex AI Gemini]
コンテキスト + 質問 → 回答生成
│
▼
ユーザーへ
試験で問われやすいシナリオ: 「PostgreSQL 互換のままベクトル検索を低レイテンシで」 → AlloyDB + scann。「1 億超の超大規模」 → Vertex AI Vector Search に外出し。
5. Read Pool による水平読み取りスケール
Read Pool Instance は 1 つの論理エンドポイントに複数 Node を割り当てる構成。アプリは Read Pool の Private IP に接続するだけで AlloyDB が自動でロードバランスする。
Cloud SQL のリードレプリカとの違い: Cloud SQL Read Replica は インスタンス単位で別 IP・別接続文字列。Read Pool は 1 つの IP に複数 Node 集約でクライアント側のロードバランス実装不要。
Cloud SQL Read Replica
- 別インスタンス・別 IP
- クライアントが自前で振り分け
- 各レプリカで遅延が異なる
AlloyDB Read Pool
- 論理エンドポイント 1 つ
- 自動ロードバランス
- Node 数を Web GUI で増減
6. Secondary Cluster — クロスリージョン DR
Secondary Cluster は 別リージョンに非同期で複製される読み取り可能なクラスタ。災害時に Switchover で Primary に昇格する。
| 機能 | Cloud SQL Cross-region Replica | AlloyDB Secondary Cluster |
|---|
| 複製単位 | インスタンス | クラスタ全体（複数インスタンス） |
| 読み取り | Replica に直接接続 | Secondary Primary + Read Pool 全部使える |
| 昇格 | Promote（手動） | Switchover（手動、整合性確認込み） |
| 使えるリージョン | 同 DB エンジン対応 | AlloyDB 利用可能リージョン |
7. Index Advisor / Adaptive Autovacuum
Index Advisor は AlloyDB がワークロードを継続的に観測し、不足しているインデックスを CREATE INDEX 文として推薦する機能。クエリ実行時間・スキャン量・WHERE 句のパターンから自動分析。
使い方: AlloyDB Console の「Insights」→「Index Advisor」で推薦 SQL をコピー → 開発環境で検証 → 本番適用。
注意: 提示されたインデックスをすべて作ると書き込みが遅くなる。利用頻度の高いクエリを優先。
Adaptive Autovacuum
標準 PostgreSQL の autovacuum は固定パラメータで動作するが、AlloyDB は テーブルサイズと書き込みパターンに応じて autovacuum パラメータを自動調整。大規模テーブルの肥大化を予防。
8. Continuous Backup と PITR
Continuous Backup
35日
最大保持期間
スケジュール Backup
あり
日次/週次設定可
Continuous Backup は WAL を分散ストレージ層に継続保管することで実現。PITR で「3 時間 27 分前の状態に戻す」のような秒単位指定が可能。
9. 制約と注意点
AlloyDB は PostgreSQL 完全互換ではない。一部の PostgreSQL 拡張（pg_partman, pg_repack 等）は未対応のものがある。事前に Supported extensions ドキュメントで確認必須。
Cloud SQL より高コスト。Cloud SQL for PostgreSQL の約 1.5〜2 倍の月額が目安。「PostgreSQL なら何でも AlloyDB」ではない。
Read Pool は Primary と完全に同じデータをリアルタイムで読めるわけではない。WAL 適用ラグがあるため、厳密にリアルタイム整合性が必要なクエリは Primary へ。
Secondary Cluster への Switchover は手動操作。Spanner Multi-region のような自動フェイルオーバーではない。RTO は手動操作時間 + 数十秒。
試験頻出のひっかけパターン
| 問題文 | NG 回答 | 正解 |
|---|
| PostgreSQL 互換 + グローバル分散 + 強整合 |
AlloyDB |
Spanner PostgreSQL Interface |
| PostgreSQL + コスト最小 |
AlloyDB |
Cloud SQL for PostgreSQL |
| PostgreSQL + 同 DB で分析統合 |
Cloud SQL Enterprise Plus |
AlloyDB (Columnar Engine) |
| PostgreSQL + 10億ベクトル超 |
AlloyDB + scann |
Vertex AI Vector Search |