Cloud Spannerの「グローバル強整合性」を疑え —— 伝説のアーキテクトが語る、真実の分散トランザクション設計
Cloud Spannerを単なる「SQLが書けるNoSQL」だと思っているなら、今すぐその認識を捨てろ。
Spannerの真価は、CAP定理の呪縛を解き放ち、「グローバルな規模」と「ACIDの完全性」を両立させた唯一無二のアーキテクチャにある。だが、多くのエンジニアは「強整合性だから安心」と油断し、パフォーマンスの墓穴を掘る。
今日は、この「最強の武器」を使いこなし、システムを崩壊させないための「極限の知見」を授ける。
—
1. TrueTimeという「物理的な奇跡」を理解せよ
Spannerの強整合性は、魔法ではない。Googleがデータセンターに張り巡らせた原子時計とGPS受信機によるTrueTimeという極めて精緻な時間管理システムの上に成り立っている。
- 何が起きているか: 全てのノードは時刻の「不確実性（Error Bound）」を認識している。
- 実務上の意味: 「コミットした順序」が世界中で物理的に保証される。これがなければ、分散システムにおける「最新の読み取り（Linearizability）」は不可能だ。
設計の鉄則:
TrueTimeに依存しているからといって、アプリケーション側で「時刻」をID生成のキーにするのは愚策だ。クライアントの時計は常に狂っている。Spannerに書き込む際は、ID生成には常にUUIDやSpannerの`GENERATE_UUID()`、あるいは単調増加する整数を使用せよ。
—
2. 強整合性の代償：レイテンシの正体
「強整合性」は、Paxosプロトコルによる過半数の合意形成を伴う。つまり、書き込みのたびに物理的な距離を越えて通信が発生する。
注意すべきパフォーマンスの罠：
- マルチリージョン構成での書き込み: 東京から書き込みを投げ、リーダーが米国にいる場合、往復の物理的距離（光速の壁）がそのままトランザクション遅延になる。
- ホットスポット: 連続したIDの挿入は、特定のノード（スプリット）に負荷を集中させる。
— よくあるアンチパターン：単調増加する主キー
— これをプライマリキーの先頭にすると、特定ノードに負荷が集中し
— Spannerの分散特性が死ぬ。
CREATE TABLE Orders (
OrderId INT64 NOT NULL, — 連続した数値は最悪のキー設計
…
) PRIMARY KEY (OrderId);
— 推奨：ビット反転やUUIDによる分散
— これにより、書き込み負荷がクラスター全体に均等に分散される
CREATE TABLE Orders (
OrderId STRING(36) NOT NULL,
…
) PRIMARY KEY (OrderId);
—
3. 「Stale Read」という最適化の切り札
全てのクエリで「強整合性」を要求する必要はない。読み取り専用のトランザクションであれば、Stale Read（読み取り専用の過去のデータ読み取り）を活用すべきだ。
強整合性を外すことで、ローカルのレプリカから読み取りが可能になり、Paxosの合意形成をスキップできる。これで読み取りレイテンシは劇的に改善する。
— 読み取り専用トランザクションの例
— 15秒前のデータで許容できるなら、強整合性を捨てて高速化する
— これにより、グローバルな通信コストを回避できる
SELECT FROM Orders@{FORCE_STALENESS=t15s} WHERE UserId = ‘user_123’;
設計の洞察:
レポート系クエリ、ダッシュボード、あるいは「数秒前のデータでもユーザー体験を損なわない」箇所は、全てStale Readに倒せ。強整合性は「決済」や「在庫管理」のような、本当に必要な場所にのみ限定して使うのがプロの設計だ。
—
4. 堅牢な設計パターン：トランザクションサイズを絞る
Spannerのトランザクションは「短く、小さく」が鉄則だ。
- 長すぎるトランザクション: 競合が発生し、リトライが頻発してスループットが低下する。
- 読み取りと書き込みの分離: 読み取りをトランザクション外（あるいは`ReadOnly`トランザクション）で行い、書き込みだけを`ReadWrite`トランザクションに押し込め。
// 悪い例：読み取りから書き込みまで全て同じトランザクションで行う
// ロジックが長いと、その間ロックを保持し続け、並列性を著しく低下させる
// 良い例：
// 1. 必要なデータをReadOnlyトランザクションで取得
// 2. アプリケーション側で計算
// 3. 確定分のみをReadWriteトランザクションで更新（ミューテーション）
—
最後に：エンジニアへ告ぐ
Cloud Spannerは、現代の分散システムが辿り着いたひとつの頂点だ。しかし、道具が強力だからといって、設計をサボっていい理由にはならない。
1. 書き込みの分散を意識せよ（キー設計）。
2. 強整合性の必要性を精査せよ（Stale Readの活用）。
3. トランザクションを極限まで短く保て（ロック時間の最小化）。
この3つを徹底するだけで、君のシステムは世界規模のトラフィックを、まるでローカルデータベースのように静かに、かつ強固に捌き切るだろう。
設計レビューで「なぜここで強整合性が必要なのか？」と問われたとき、明確な根拠を持って答えられるか？ それが、一流のエンジニアとそうでないエンジニアの境界線だ。
コメント