【テクニカル・上級編】トランザクション分離レベル – Cloud Spanner

Cloud Spannerのトランザクション分離：その「完全性」という名の代償

Cloud Spannerを単なる「グローバルにスケールするRDBMS」と呼ぶのは、その真の価値を半分も見落としている。このシステムの核心は、分散システムにおいて長年「聖杯」とされてきた外部整合性（External Consistency）を、パフォーマンスを犠牲にすることなく、いかにして物理的なレイテンシの壁を突破して実現しているかにある。

我々エンジニアがSpannerと対峙する際、最も深く理解すべきは、彼らが提供する「Serializable（直列化可能）」という隔離レベルが、一般的なRDBMSのそれとは根本的に異なるアーキテクチャに基づいているという事実だ。

1. 外部整合性とTrueTimeの物理的制約

Spannerのトランザクション分離は、PaxosとTrueTimeの融合によって成立している。多くの開発者は「シリアライザブルだから競合しても安全だ」と安易に考えているが、その下層で何が起きているかを知る必要がある。

Spannerのトランザクションは、TrueTimeによる「絶対的な時刻」を基盤に順序付けられる。ここで重要なのは、「読み取り専用トランザクション（Snapshot Read）」と「読み書きトランザクション（Read-Write Transaction）」の分離メカニズムだ。

読み取り専用トランザクションは、特定のスナップショットタイムスタンプ $t$ を使用して、その時点でコミットが完了しているデータのスナップショットを読み取る。これはロックフリーで実行される。一方、読み書きトランザクションは、Paxosグループのリーダーを通じて順序付けられ、コミット時にタイムスタンプが割り当てられる。

この設計において「シリアライザブル」を保証するためには、読み書きトランザクションの競合検知が、楽観的並行性制御（OCC）の延長線上にあることを理解しなければならない。

2. 競合と再試行：なぜ「再試行」が不可欠なのか

Spannerの読み書きトランザクションは、内部的に以下のプロセスを辿る。

1. Read Phase: データを読み込み、ローカルなバッファに保持する。この時点ではロックは取得されない。
2. Buffered Writes: 書き込み内容をクライアント側にキャッシュする。
3. Commit Phase: `commit()` を呼び出した時点で、リーダーに対してロックの獲得と書き込みをリクエストする。

ここで競合が発生した場合、サーバー側は `Aborted` エラーを返す。これは、「誰かが君のトランザクションよりも先に順序付けされたよ」というSpannerからのメッセージだ。

多くのアーキテクトがここで陥る罠は、アプリケーション側の再試行ロジックを単なる「エラーハンドリング」として軽視することにある。

伝説的なアーキテクトが実装する、Spannerのトランザクション再試行ロジックの骨子
def run_transaction(db, callback):
# 指数バックオフを用いて競合率が高い環境下でのトライブリッドな再試行を行う
attempt = 0
while True:
try:
return db.run_in_transaction(callback)
except AbortedError:
# 競合発生時、ただちに再試行するのではなく、バックオフ戦略を動的に調整する
# 内部のPaxosステートの収束を待つための「知的な」待機時間が必要
backoff(attempt)
attempt += 1
continue

3. パフォーマンスの限界を突破するメモリ最適化の勘所

Spannerの読み書きトランザクションにおいて、最もコストが高いのは「Read Phaseでの往復」だ。

もしあなたが、トランザクション内で何度も読み取りを行っているなら、それは設計ミスだ。Spannerのトランザクションは、「必要なデータをRead Phaseで一括で取得し、アプリケーション側で計算し、最後にまとめてコミットする」というパターンに最適化されている。

Read-Writeの範囲を最小化せよ: 読み取りセットが広すぎると、コミット時に他者の更新と衝突する確率が飛躍的に高まる。
ポイント読み取りの多用: 範囲スキャン（Range Scan）は、インデックスの広範囲にロックを張るのと同等の競合リスクを生む。可能な限りPrimary Keyによるポイントルックアップに落とし込め。
バッファリングの意識: 書き込みデータはコミット時までSpanner側に保持されない。つまり、トランザクション内の読み取りは、過去の自身の書き込みを見ることができない。これを補完するために、アプリケーションメモリ内で状態を保持する工夫が真のエンジニアには求められる。

4. 最後に：エンジニアへの提言

Spannerのトランザクションは、魔法ではない。分散環境下で「正確さ」を追求した結果、物理的な制約（光速、原子時計の精度、Paxosのラウンドトリップ）と対峙している。

シリアライザブルであることを「重い」と嘆くのは、アマチュアの思考だ。「シリアライザブルであるからこそ、複雑なロックのデッドロックを気にせず、Paxosの堅牢性という圧倒的な恩恵を享受できる」と考えるべきだ。

再試行ロジックを疎かにする者は、Spannerの真価を半分も引き出せていない。トランザクションの競合は、失敗ではなく「整合性を守るための正常なプロセス」である。この哲学を理解した時、あなたのアーキテクチャは次のステージへ昇華する。

データベースは、単なるデータの箱ではない。時空を超えて一貫性を保ち続けるための、数学的な芸術作品なのだから。