Cloud Spannerの魂：楽観的並行性制御が引き起こす「真の並列」の深淵
多くのエンジニアが「Cloud Spannerは読み取りにロックをかけないから速い」と口にする。それは事実だが、表面的な理解に過ぎない。
Spannerの真価は、分散システムにおいて「整合性（Consistency）」と「可用性（Availability）」という長年の二律背反を、楽観的並行性制御（Optimistic Concurrency Control: OCC）を軸としたトランザクション層でどう解決したかにある。今日は、カタログスペックの裏側にある、我々が実装の深淵で見た「真のメカニズム」について語ろう。
—
1. ロックの不在と「検証」のコスト
Spannerの読み取りトランザクションは、基本的にロックを獲得しない。これはSnapshot Isolationを支えるMVCC（多版同時実行制御）の恩恵だが、書き込みを伴うRead-WriteトランザクションにおけるOCCの挙動は、より洗練されている。
SpannerにおけるOCCの核心は、「コミット直前のバリデーション（検証）」にある。
1. Read Phase: クライアントはリーダーからデータを読み取るが、この際、読み取ったデータのタイムスタンプ（`read_timestamp`）が記録される。
2. Buffered Phase: 書き込みデータはクライアント側のメモリ（あるいはバックエンドの一時ストレージ）でバッファリングされる。
3. Commit Phase: トランザクションを確定させる際、SpannerはPaxosグループに対して「読み取ったデータセットが、現在の状態と照らし合わせて依然として最新か？」を検証する。
ここで重要なのは、「競合がなければロックの取得コストを回避し、競合があればAbortしてやり直す」という設計思想だ。
なぜこれがスループットを最大化するのか？
従来型の悲観的ロック（2PL）では、トランザクションの開始と同時に行ロックを確保するため、ノード間通信のレイテンシがそのままロック保持時間に加算される。SpannerのOCCは、この「ノード間通信の待ち時間」をロックの外に追い出した。これにより、Paxosのコンセンサス形成という本質的なコスト以外、システムを停止させる要因を排除している。
—
2. 内部メカニズム：`Commit Wait` と TrueTime の共犯関係
OCCが成立するためには、分散環境下で「データが古いか新しいか」を正確に判定する、絶対的な時間軸が必要だ。ここでGoogleの誇る`TrueTime`が登場する。
// 概念的なトランザクションのコミットフロー
// TrueTimeを使用して、コミット時刻 t を決定する
Timestamp commit_ts = TrueTime.now().latest;
// バリデーション：
// 読み取ったデータが [start_ts, commit_ts] の間で変更されていないかを確認
if (ValidationService.is_consistent(read_set, commit_ts)) {
Paxos.propose(write_set, commit_ts);
} else {
// 競合発生：Abortしてリトライの戦略（バックオフ）を選択
throw TransactionConflictException();
}
注意すべきは、`commit_ts` が確定した後の `Commit Wait` だ。Spannerは、自身の時刻誤差（$\epsilon$）が解消されるまでコミットを意図的に待機させる。これにより、どのノードから見ても「コミット時刻以降の読み取りは、必ずコミット後の最新データを参照する」ことが保証される。
これは単なる時計の話ではない。「厳密な直列化可能性（External Consistency）」を維持するための、物理法則への挑戦だ。
—
3. アーキテクトが見る「メモリとCPUの最適化」
大規模なワークロードにおいて、OCCは諸刃の剣となる。競合が多い環境ではAbortの嵐が吹き荒れ、CPUサイクルが無駄に消費されるからだ。これを防ぐために、我々アーキテクトが意識すべき極限のチューニングポイントがある。
A. Read-Modify-Writeのアンチパターン
もし君が「読み取って、アプリで計算して、書き込む」というコードを書いているなら、それはSpannerのOCCを殺している。
代わりに、Mutationによるサーバーサイドの更新を活用せよ。可能な限り `Update` クエリを単一のトランザクション内で完了させ、クライアントへのラウンドトリップを減らすことが、バリデーション成功率を劇的に高める。
B. Paxosグループの局所性
データの読み取りと書き込みが異なる物理ノードに分散していると、Paxosの合意形成でOCCの検証コストが増大する。パーティショニング戦略（主キーの設計）を適切に行い、関連するデータが同一のSplit（範囲）に収まるように設計せよ。これにより、ネットワークを跨ぐ検証コストがメモリ内アクセスに近い速度まで最適化される。
—
4. 伝説のエンジニアからの提言
SpannerのOCCは、魔法ではない。極めて緻密に計算された「統計的な勝利」だ。
- 読み取り中心なら: Snapshot Readを積極的に使え。`read_timestamp` を指定することで、過去のバージョンをロックなしで読み取れる。これはOCCの検証コストすら発生させない、最強の読み取りモードだ。
- 書き込みが混在するなら: トランザクションのサイズを小さく保て。「1つのトランザクションで多くの行を触らない」。触る範囲が広ければ広いほど、バリデーションの失敗確率は指数関数的に上昇する。
Spannerを使いこなすということは、分散システムの「物理的制約」と「論理的整合性」の間の隙間に、完璧なコードを流し込む作業に他ならない。
君たちの設計するシステムが、この広大な分散空間において、いかに美しく、いかに整合性を保ちながらスループットを叩き出すか。その鍵は、このOCCの挙動を脳内に完全に投影できているかどうかにある。
健闘を祈る。
コメント