【テクニカル・上級編】読み取り書き込みトランザクション – Cloud Spanner

Cloud Spannerの真髄：読み取り書き込みトランザクションの深淵を覗く

Cloud Spannerを単なる「水平スケールするRDBMS」だと定義するなら、それはこのシステムの持つ真の狂気を見落としている。

Spannerの読み取り書き込みトランザクション（Read-Write Transaction）は、分散システムにおいて「完全な直列化可能性（Serializable）」と「高可用性」という、本来トレードオフにあるはずの概念を物理法則の限界ギリギリで両立させた、現代工学の金字塔だ。

なぜ、グローバル規模の分散環境でACID特性を保証できるのか。その内部の「地獄」を紐解こう。

—

1. 楽観的並行制御（OCC）の限界を超えて

Spannerのトランザクションは、本質的に楽観的並行制御（Optimistic Concurrency Control）に基づいている。しかし、単なるOCCではない。

読み取りフェーズ: トランザクション内で行われる読み取りは、スナップショットとして扱われる。ローカルのReplicaで読み取りを行い、Timestamp Oracle (TrueTime) を用いて整合性を確保する。
書き込みフェーズ: 書き込みバッファはクライアントサイドに保持され、コミットの瞬間に全データの変更セットがコーディネーターへと送られる。

ここで多くのエンジニアが誤解するのが、「再試行（Retry）」のコストだ。Spannerの `Aborted` は失敗ではない。これは、「システムがあなたのトランザクションよりも高優先度の、あるいは先にコミットされた別のトランザクションを検知した」という、極めて正常かつポジティブな警告である。

2. TrueTime：物理時計の不確実性を数学的に封じ込める

Spannerのトランザクションを語る上でTrueTimeを避けることはできない。分散システムにおいて「現在時刻」ほど信用ならないものはない。Spannerは `[earliest, latest]` という誤差幅（epsilon）を持つインターバルを扱う。

読み取り書き込みトランザクションのコミット時、Spannerは Commit Wait という戦略をとる。

書き込みデータのタイムスタンプ $s$ を決定する。
システムは、絶対的な時刻が確実に $s$ を経過するまで（つまり、後続のトランザクションが $s$ を観測できないように）待機する。

この「待ち」こそが、Spannerがグローバルで順序を保証できる唯一無二のロジックだ。この数ミリ秒の待機は「遅延」ではなく、「分散環境における時間の定義」そのものである。

3. パフォーマンスを極限まで引き出すための「内部構造」への介入

熟練したアーキテクトがトランザクションを設計する際、以下の3点に神経を尖らせるべきだ。

A. 競合（Contention）の局所化

読み取り書き込みトランザクションは、同一の「分割単位（Split）」に集中すると、Paxosグループのリーダーへの負荷が集中する。

— 悪い例: 全てのトランザクションが単一の行を更新する
— これではPaxosリーダーのシリアライゼーションがボトルネックとなり、
— スループットが極端に低下する。
UPDATE Counters SET Value = Value + 1 WHERE CounterID = ‘GLOBAL_SEQUENCE’;

解決策は、シャード化されたカウンタや、トランザクションの粒度を最小化するための設計だ。Spannerの内部では、行単位のロックではなく、もっと細かいキーの範囲ベースでのロック管理が行われていることを忘れてはならない。

B. 書き込みバッファの肥大化を避ける

トランザクション内で巨大な `SELECT` を実行し、その結果をもとに書き込みを行う際、クライアント側のメモリを圧迫していないか？
Spannerのトランザクションは、サーバ側で保持される状態（ロック）を最小化しなければならない。トランザクションの処理時間は、そのまま「ロックが占有される期間」に直結する。

C. 冪等性と再試行ロジックの最適化

Spannerのクライアントライブラリは `runInTransaction` を提供しているが、これを盲目的に信じてはならない。

// 伝説的なアーキテクトは、再試行回数だけでなく、
// 競合発生時のバックオフ戦略をアプリケーションの特性に合わせてチューニングする
_, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, txn spanner.ReadWriteTransaction) error {
// 読み取りは極力シンプルに
// 複雑なJOINや集計はトランザクション外（読み取り専用トランザクション）で行う
// 最後に書き込みのバッファを構築する
return txn.BufferWrite([]spanner.Mutation{…})
})

再試行が発生するたびに、トランザクション内の全ロジックが再実行される。トランザクション内での副作用（外部APIコールなど）は絶対の禁忌である。

4. チーフアーキテクトからの提言

Cloud Spannerは「魔法」ではない。非常に洗練された「分散合意アルゴリズム（Paxos）」と「厳密な物理時計管理（TrueTime）」の上に成り立つ、極めて論理的な物理層の産物だ。

多くの開発者は、Spannerのトランザクションが「遅い」と文句を言う。しかし、それは多くの場合、トランザクションの範囲（Scope）が広すぎるか、競合設計が甘いことに起因している。

トランザクションは短く、そして鋭くあれ。

読み取り書き込みトランザクションが必要なのは、データの整合性が「物理的な不可分性」を要求する瞬間だけだ。それ以外は、読み取り専用トランザクションに逃がすか、アプリケーションレベルでの非同期処理を検討せよ。

Spannerの限界は、Spannerそのものの限界ではなく、それを扱うエンジニアの「分散システムに対する解像度」の限界だ。この怪物のようなデータベースを使いこなすには、単なるSQLの知識ではなく、データがネットワークを飛び交い、Paxosの海を渡り、TrueTimeの不確実性と折り合いをつけるそのプロセスを、頭の中で可視化する必要がある。

健闘を祈る。