AlloyDB / Cloud Spanner

解決する課題

標準の Cloud SQL（マネージドPostgreSQL/MySQL）より、高い可用性・性能・スケールが欲しいときに使います。

標準のマネージドDBより速く・落ちにくいPostgreSQLが欲しい（→ AlloyDB）
トランザクション処理と分析（HTAP）を1つのDBでこなしたい（→ AlloyDB の列指向エンジン）
単一ノードの上限を超えて書き込みを水平スケールしたい（→ Cloud Spanner）
リージョンをまたいで強整合のグローバルDBを運用したい（→ Cloud Spanner マルチリージョン）

主要概念と用語

クラスタ / インスタンス（AlloyDB）: クラスタが共有ストレージと設定の単位。その中にプライマリインスタンス（書込）とリードプールインスタンス（読込スケール）を置く
リードプール: 読み取り専用ノードの集合。ノードを増やして読み取りをスケール（Aurora レプリカ相当）
列指向エンジン（Columnar Engine）: AlloyDB がメモリ上に列形式のキャッシュを持ち、分析クエリを高速化する仕組み
ストレージ層の分離: ログ処理・ストレージを計算ノードから切り離した分散アーキテクチャ
AlloyDB Omni: 同じエンジンを自前環境やオンプレ、他クラウドで動かせるダウンロード版
Cloud Spanner: 別サービス。ノード／プロセッシングユニット(PU) 単位でスケールし、TrueTime により外部整合性（グローバル強整合）を提供する分散RDB

仕様・制限・クォータ

AlloyDB: PostgreSQL 互換（拡張機能の多くに対応）。ストレージは自動拡張、リージョン内の複数ゾーンに自動冗長化
AlloyDB のリードプールはノードを追加して読み取りをスケール（同一クラスタの共有ストレージを参照するため低遅延）
Cloud Spanner: 1ノード ≒ 1,000 PU。スループットに応じてノード/PUを増減し、ストレージは自動でシャーディング（スプリット）
Spanner はグローバルセカンダリインデックスやインターリーブ等、独自のスキーマ概念を持つ
クォータ（インスタンス数・vCPU 等）はプロジェクト/リージョン単位。引き上げ申請が可能

内部の仕組み

AlloyDB は、PostgreSQL のクエリ層とGoogle製の分散ストレージ層を分離した構成です。書き込みは WAL（ログ）としてストレージ層へ渡り、ログ処理サービスがブロックを生成・複製します。計算ノードはこの共有ストレージを参照するため、リードプールのノードを増やすだけで読み取りがスケールし、レプリケーション遅延も小さく保たれます。さらに列指向エンジンが頻繁にスキャンされる列をメモリ上に列形式でキャッシュし、分析系クエリを大幅に高速化します（HTAP）。

Cloud Spanner はこれとは別系統で、データをスプリットという単位に分割し複数ノードへ分散。各書き込みを Paxos で複数レプリカに合意させ、TrueTime（GPS と原子時計に基づく時刻 API）を使って**外部整合性（強整合）**を保ったまま水平スケールします。

Cloud SQL との違い

Cloud SQL（標準マネージド）は単一プライマリ＋リードレプリカが基本。AlloyDB はストレージ分離＋リードプール＋列指向エンジンで、可用性・読み取りスケール・分析性能を一段引き上げます。「もっと速い PostgreSQL」が要件なら AlloyDB、「PostgreSQL/MySQL が手軽に欲しい」なら Cloud SQL です。

設計パターン / ベストプラクティス

読み取りはリードプールに逃がし、プライマリは書き込みに集中させる
OLTP と分析を同居させたい場合は列指向エンジンを有効化（対象列を指定）
単一インスタンスの限界を超える書き込みスケールや、グローバル強整合が要件なら Cloud Spanner を選ぶ
他クラウド/オンプレと同一エンジンで動かしたい開発・検証は AlloyDB Omni を活用

運用・監視

Cloud Monitoring / Cloud Logging で CPU・接続数・レプリケーション遅延・列指向ヒット率を可視化
System Insights / Query Insights でスロークエリやボトルネックを特定
自動バックアップと PITR（ポイントインタイムリカバリ） を構成。フェイルオーバーはマネージドで実施
Spanner は CPU 使用率を見ながらノード/PU をスケールし、ホットスポット回避のためキー設計を監視

コスト

AlloyDB は「vCPU・メモリ＋ストレージ＋バックアップ」、Spanner は「ノード/PU＋ストレージ」が基本です。読み取りスケールはノード追加で調整します。

サービス / 課金軸	課金の中身	向いている用途
AlloyDB プライマリ	vCPU・メモリ時間 + ストレージ	高性能な本番 PostgreSQL
AlloyDB リードプール	ノード（vCPU/メモリ）時間	読み取りスケール・分析オフロード
AlloyDB バックアップ	保存容量 + PITR ログ	DR・復旧要件
Cloud Spanner	ノード or PU + ストレージ + ネットワーク	水平スケール・グローバル強整合
Spanner マルチリージョン	リージョン数分のノード課金	多リージョン冗長・低遅延読み取り

セキュリティ

保存データは既定で暗号化。鍵は Cloud KMS（CMEK） で自前管理が可能
プライベートIP（VPC） 配置と Authorized networks／IAM によるアクセス制御
DB認証は IAM データベース認証 を利用でき、パスワードのハードコードを回避できる
機微情報は Secret Manager で管理し、アプリにはコード外から注入する

アンチパターン

DBの接続情報（ユーザー/パスワード）をアプリのコードや環境設定に直書きするのはNG。IAM データベース認証や Secret Manager を使い、資格情報の漏洩・ローテーション漏れリスクを排除しましょう。

観点	AlloyDB / Cloud Spanner（GCP）	Amazon Aurora（AWS）
位置づけ	高性能 PostgreSQL / 分散RDB	高性能 MySQL・PostgreSQL互換RDB
互換性	AlloyDB=PostgreSQL互換 / Spanner=独自+GoogleSQL/PG方言	MySQL・PostgreSQL互換
読み取りスケール	AlloyDB リードプール / Spanner ノード追加	Aurora レプリカ（最大15）
水平書き込みスケール	Cloud Spanner（無限水平分割）	（基本は単一ライター）
分析(HTAP)	AlloyDB 列指向エンジン	（別途分析基盤）
権限付与	IAM / IAM DB認証	IAM 認証

ハンズオン / CLI例

# AlloyDB クラスタを作成（リージョン内で冗長化）
gcloud alloydb clusters create my-alloydb-cluster \
  --region=asia-northeast1 \
  --password=CHANGE_ME

# プライマリインスタンス（書き込み用）を作成
gcloud alloydb instances create my-primary \
  --cluster=my-alloydb-cluster \
  --region=asia-northeast1 \
  --instance-type=PRIMARY \
  --cpu-count=4

# リードプール（読み取りスケール）を追加
gcloud alloydb instances create my-readpool \
  --cluster=my-alloydb-cluster \
  --region=asia-northeast1 \
  --instance-type=READ_POOL \
  --read-pool-node-count=2 \
  --cpu-count=4

# 参考: Cloud Spanner のインスタンスを作成する場合
gcloud spanner instances create my-spanner \
  --config=regional-asia-northeast1 \
  --description="demo" \
  --nodes=1