1. Spanner を選ぶ「絶対条件」
Spanner は次の
3 つすべてを満たすときだけが正解。1 つでも欠けたら別 DB を検討。
- グローバル分散（複数リージョンで読み書きする必要がある）
- 強整合性 + ACID（金融、在庫など）
- 無制限の水平スケール（書き込み QPS が Cloud SQL 上限を超える）
2. Instance Config — 3 つの選択肢
| Config | SLA | Replica 構成 | Edition | 用途 |
|---|
| Regional |
99.99% |
3 read-write replicas (3ゾーン) |
Standard / Enterprise / Enterprise Plus |
単一地域内で水平スケール |
| Dual-region |
99.999% |
各リージョンに 2 RW + 1 Witness = 計6 |
Enterprise Plus のみ |
1国内 2リージョン構成 |
| Multi-region |
99.999% |
2 RW region + 1 Witness region |
Enterprise Plus のみ |
グローバル分散 |
主要 Multi-region Config
| Config | リージョン構成 |
|---|
nam3 | 北米：us-east4, us-east1 + 米中部 (Witness) |
nam-eur-asia1 | 3大陸：北米 + 欧州 + アジア (グローバル) |
eur3 | 欧州：europe-west1, europe-west4 + 中部 (Witness) |
asia1 | 東アジア：asia-northeast1 (東京) + asia-northeast2 (大阪) |
asia2 | asia-northeast1 (東京) + asia-east1 (台湾) |
3. Replica の種類と Paxos Quorum
Spanner は Paxos プロトコル で書き込みの合意を取る。Replica は 3 種類存在する。
Read-Write Replica
- Paxos voter
- 書き込みに参加
- 読み取り両方可
Read-Only Replica
- Paxos 非参加
- 読み取り専用
- 低レイテンシ読み取り用
Witness Replica
- Paxos voter
- データ完全保持しない
- タイブレーカー
- コスト最小
Quorum の取り方（Multi-region 例）
Multi-region (例: nam3)
┌─────────────────────────────────────────────────┐
│ Region A (default leader) │
│ ├── RW Replica 1 (voter) ← writeのリーダー候補│
│ └── RW Replica 2 (voter) │
├─────────────────────────────────────────────────┤
│ Region B │
│ ├── RW Replica 3 (voter) │
│ └── RW Replica 4 (voter) │
├─────────────────────────────────────────────────┤
│ Region C (witness only) │
│ └── Witness Replica 5 (voter, data minimal) │
└─────────────────────────────────────────────────┘
Write Quorum:
"1 leader replica + any 2 of the additional 4 voting replicas"
合計 5 voters → 3 票必要 (majority)
→ どこか 1 リージョン全滅でも write 継続可能
Write Latency: Multi-region では 最寄りの 2 voter の応答待ちが必要なため、Regional より数十 ms 遅い。読み取りは Read-Only Replica で 各リージョン内に閉じる。
4. TrueTime API — 物理時計が解く分散課題
分散システムで「どっちのトランザクションが先か」を決めるのは非常に難しい。論理時計（Vector Clock）では順序付けが「部分順序」しか取れない。Spanner は GPS + 原子時計を全データセンターに配置し、物理時刻に基づく全順序を実現。
TrueTime API: TT.now() → [earliest, latest]
例: TT.now() = [12:00:00.001, 12:00:00.007]
6 ms の不確かさ (epsilon)
Spanner はコミット時刻に「epsilon を待つ」ことで
どこのリージョンでも commit_ts より小さい時刻のクエリは
「絶対にこの commit より前」と保証できる。
これにより External Consistency (外部整合性)
= 「人間の時間感覚と一致する順序」を実現。
外部整合性 (External Consistency) = Linearizability の強化版。「先にコミットされたトランザクションは、後のすべての読み取りで先に見える」ことを世界中で保証。これが Spanner だけが提供する独自価値。
5. Splits と自動シャーディング
Spanner は テーブルを Splits（スプリット）と呼ぶ単位に自動分割する。スプリットは主キーの範囲で定義され、独立して別のサーバー（ノード）に配置される。
Users テーブル (UserId が主キー)
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ Split 1: UserId 1-1000│ │ Split 2: 1001-5000 │ │ Split 3: 5001-∞ │
│ サーバー A │ │ サーバー B │ │ サーバー C │
└────────────────────┘ └────────────────────┘ └────────────────────┘
自動分割条件:
- サイズ閾値 (例: 8 GB)
- 負荷集中 (1 split に書き込み集中)
問題: 連番主キー (Sequence / 昇順タイムスタンプ) は
常に最後の split に書き込みが集中
→ ホットスポット → 性能劣化
6. スキーマ設計 — Interleaving とホットスポット
6-1. Interleaving (親子テーブル)
Spanner では 親子関係のあるテーブルを物理的に同じスプリットに配置できる。これにより JOIN が「同一サーバー内」で完結し、超高速化。
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;
親子のキーは 子の主キーが親の主キーで始まる必要がある。(CustomerId, OrderId) のように親キー CustomerId が先頭。
6-2. ホットスポット回避
連番・昇順タイムスタンプの主キーは禁忌。書き込みが末尾スプリットに集中し、Spanner の水平スケールが効かなくなる。Cloud SQL/Postgres の常識を持ち込むと不正解。
主キー設計パターン
| パターン | 例 | 評価 |
|---|
| 連番 (BAD) | 1, 2, 3, ... | ホットスポット |
| 昇順タイムスタンプ (BAD) | 2026-05-30T10:00:01, ... | ホットスポット |
| UUID v4 (GOOD) | ランダム | 均等分散 |
| 反転タイムスタンプ (GOOD) | 9999999999 - ts | 時系列も均等分散 |
| ハッシュプレフィックス (GOOD) | shard_n# + 業務キー | 範囲スキャンしたい時 |
7. Processing Units と容量計画
サイジングの考え方
-
ベースラインの推定
最も負荷のあるユースケース（ピーク QPS）を想定し、ロードテスト
-
初期 PU 設定
テスト結果から CPU 65% 以下に収まる PU 数を設定
-
オートスケーリング有効化
spanner-autoscaler で High CPU 利用率時に自動拡張
-
監視
Latency p95/p99、Storage、High Priority CPU の 3 指標を継続監視
過小プロビジョニング: 「コスト最適化のために 100 PU から始める」というシナリオで、ピーク時に CPU 80% を超えるとレイテンシ急増。初期は余裕を持って設定、Auto-scaler で縮小も自動化。
8. Backup と PITR
| 項目 | 値 |
|---|
| PITR 最大保持期間 | 7日 |
| Backup 最大保持期間 | 1年 (365日) |
| Backup タイプ | Full backup (Spanner 内部形式) |
| Cross-region Backup コピー | 可能（Backup Schedules） |
| Restore 先 | 同インスタンス or 別インスタンス |
| Export to GCS | Avro 形式（Dataflow テンプレート） |
9. 制約 / Cloud SQL との使い分け
Spanner はオーバーキルになりやすい。「念のため Multi-region」を選ぶと、Regional の 10 倍コストになる可能性。要件を厳密に確認。
Spanner SQL は標準 SQL に近いが完全互換ではない。Stored Procedure 非対応（最近 PL/pgSQL 対応開始）、JSON 操作の方言、Foreign Key の動作差異。既存 PostgreSQL アプリの単純移行は不可。
使い分けマトリクス
| 要件 | 選択 |
|---|
| 単一リージョン + 中規模 OLTP | Cloud SQL / AlloyDB |
| 単一リージョン + 100K QPS 超 | Spanner Regional |
| グローバル + 強整合 + 99.99% | Spanner Regional 数本 + Cross-region Backup |
| グローバル + 強整合 + 99.999% | Spanner Multi-region |
| 分析 (OLAP) 中心 | BigQuery |
| PostgreSQL Stored Procedure 重依存 | AlloyDB (Spanner PG Interface でも一部可) |
試験頻出のひっかけ
「グローバル ECサイト」だけで Spanner を選ぶと罠。「強整合性」「99.999%」「水平スケール」のキーワードが揃わなければ、Cloud SQL + クロスリージョン リードレプリカでも要件を満たす場合がある（コスト差大）。