【実務・中級編】トランザクションマネージャーの内部動作 – Cloud Spanner

トランザクションマネージャーの内部動作：Cloud Spannerは如何にして「分散の悪夢」を克服したか

こんにちは。テクニカルリードの私だ。
今日のコードレビューで、誰かが「Spannerを使っているから、トランザクションは何も考えずに安全にスケールする」とコメントしているのを見かけた。

……甘い。甘すぎる。

Cloud Spannerは、確かに現代の分散データベースの最高峰であり、外部整合性（External Consistency）とグローバルなACIDトランザクションを両立させた驚異的なプロダクトだ。しかし、それは「物理法則の制約を魔法のように消し去った」わけではない。Googleのエンジニアたちが、泥臭い分散合意と洗練されたトランザクションマネージャーの協調によって、「分散システムの悪夢」を極限まで隠蔽しているに過ぎないのだ。

実務でSpannerを使うエンジニアであれば、その下層で何が起きているのかを知る必要がある。なぜなら、不適切なデータモデリングやアクセスパターンのせいで、トランザクションマネージャーが悲鳴を上げ、レイテンシが爆発する現場を私は何度も見てきたからだ。

今回は、Spannerの心臓部である「トランザクションマネージャー」の内部動作と、2相コミット（2PC）の状態遷移に真っ向からメスを入れる。

—

1. 分散トランザクションのライフサイクルとコーディネーターの役割

Spannerのトランザクションは、単一のノードで完結することは稀だ。データがシャード（スプリット）され、グローバルに分散している以上、複数のPaxosグループを跨ぐ必要がある。

ここで登場するのが、リーダー（Leader）レプリカの中に存在する「トランザクションマネージャー（Transaction Manager）」だ。

リーダーとコーディネーターの選出

マルチプルなPaxosグループにまたがる書き込みトランザクションが発生した時、クライアントはまずアクセスするデータのリーダーレプリカ群と通信を始める。その中で、「リード・ウォーク（Read/Write Transaction）」のコーディネーター（Coordinator）として機能するPaxosグループのリーダーが1つ選出される。

これが何を意味するか、実務的に考えてみてほしい。
コーディネーターとなったリーダーは、以下の重責を一身に背負う。

1. タイムスタンプの調停（TrueTime APIの活用）
2. 2相コミット（2PC）のオーケストレーション
3. ロックのライフサイクル管理

[Client] —> (Read/Write Request) —> [Coordinator Leader]
|
+————————-+————————-+
| (2PC Prepare Phase) | (2PC Prepare Phase)
v v
[Participant Leader A] [Participant Leader B]
(Paxos Group A) (Paxos Group B)

もし、このコーディネーターと参加者（Participants）の間でネットワーク遅延やパケットロスが発生すれば、トランザクションは直ちにレイテンシのペナルティを受ける。これが「ホットスポット」の正体だ。特定のキーレンジに書き込みが集中すると、特定のリーダーとトランザクションマネージャーに負荷が収束し、システム全体のスループットが急降下する。

—

2. 2相コミット（2PC）における状態遷移の管理

Spannerの強みは、分散環境でありながら厳密な直列化可能性（Serializable）を提供することだ。これを支えるのが、Paxosと組み合わせた最適化された2相コミット（2PC）である。

教科書的な2PCは「ブロックしやすい（Blocking）」という致命的な弱点を抱えている。参加者がクラッシュした際、コーディネーターからの指示を待つ間にロックが保持され続け、システムが停止することがあるからだ。
しかし、Spannerの2PCは、各参加者がPaxosグループ（＝高可用なステートマシン）であるという前提で実装されている。これにより、個々のノードが落ちてもPaxosの合意形成によって状態が復元されるため、従来の2PCよりもはるかにロバスト（堅牢）になっている。

2PCの状態遷移と内部シーケンス

トランザクションマネージャーが管理する2PCのライフサイクルは、厳密なステートマシンとして動作する。

[Active / Executing]
│
▼ (Client invokes Commit)
[Prepared] ──(Paxos Log Replication)──► [Committed / Aborted]
│
▼ (Apply to Storage & Release Locks)
[Finished]

1. Active（実行中）:
クライアントが読み取りを行い、ローカルのロックを獲得しながら、書き込みバッファにデータを蓄積している状態。この段階ではまだ通信は最小限。

2. Prepared（準備完了）:
クライアントがコミットを要求すると、コーディネーターはすべての参加者リーダーに対して `Prepare` メッセージを送信する。

参加者側は、コミットに必要な変更をPaxosログに記録し、「準備OK（Yes）」の投票を返す。この時点で、変更は永続化の保証（Durability）の領域に入るが、まだ可視（Visible）ではない。

3. Committed / Aborted（決定）:
すべての参加者から「Yes」の投票が集まると、コーディネーターはTrueTime APIを用いてコミット・タイムスタンプ ($s$) を決定する。

コーディネーターは、このタイムスタンプと共に `Commit` メッセージを全参加者にブロードキャストする。
タイムスタンプの決定には、TrueTimeの不確かさ（Uncertainty $\epsilon$）を考慮したウェイト（Commit Wait）が含まれる。これにより、物理時間の順序とトランザクションの因果関係が完全に一致することが保証される。

4. Finished（完了）:
各参加者がコミット・タイムスタンプ ($s$) でデータを適用し、保持していたロックを解放する。

—

3. 実務で知るべき「パフォーマンス上の罠」と堅牢な設計パターン

ここまで読んだ賢明なエンジニアなら、Spannerのトランザクションマネージャーを最大限に活かすための設計指針が自然と見えてきたはずだ。

❌ アンチパターン：不必要なクロスグループ・トランザクションの乱用

以下のようなコードレビューを見かけたら、即座に差し戻しを命じてほしい。

// 【悪夢のアンチパターン】
// 異なるインターリーブ関係にない親を持つテーブルの更新を1つのトランザクションで行う
databaseClient.readWriteTransaction().run(transaction -> {
// ユーザデータの更新 (Paxosグループ A に属する可能性)
transaction.bufferUpdate(
Mutation.newUpdateBuilder(“Users”).set(“UserId”).to(1).set(“Status”).to(“ACTIVE”).build()
);

// 全く関係のないシステムログの更新 (Paxosグループ B に属する可能性)
transaction.bufferUpdate(
Mutation.newInsertBuilder(“SystemLogs”).set(“LogId”).to(UUID.randomUUID().toString()).set(“Message”).to(“User active”).build()
);
return null;
});

何が問題か？
このコードは、確実に「クロスグループ・トランザクション」を引き起こす。トランザクションマネージャーは複数のPaxosグループを調整するために2PCを発動し、ネットワークラウンドトリップが増加し、レイテンシが悪化する。さらに、ロック保持期間が長くなるため、並行実行性能（スループット）が劇的に低下する。

✅ 堅牢な設計パターン：インターリーブ（Interleave）とドメイン分割

データの物理的局所性をデザインせよ。Spannerの真骨頂は「親子関係のインターリーブ（Interleaving）」にある。

— 親テーブル
CREATE TABLE Customers (
CustomerId INT64,
Name STRING(MAX),
) PRIMARY KEY(CustomerId);

— 子テーブル（親と同じスプリットに物理的に共存する）
CREATE TABLE Orders (
CustomerId INT64,
OrderId INT64,
OrderDate DATE,
) PRIMARY KEY(CustomerId, OrderId),
INTERLEAVE IN PARENT Customers ON DELETE CASCADE;

この設計の優位性:
`Customers` とその子である `Orders` をインターリーブ配置すると、同一の `CustomerId` を持つレコードは物理的に同一のPaxosグループ（同じスプリット）に格納される。
したがって、顧客情報とその注文を同時に更新するトランザクションは、単一のPaxosグループ内で完結するため、重い2PCをバイパスし、ローカルコミットとして超高速に処理される。

トランザクションマネージャーは「何もしなくてよい（単一グループ内の合意だけで済む）」ため、リソースを消費しない。これが実務でスケールするシステムのデータモデリングだ。

—

チーフアーキテクトからのメッセージ

Cloud Spannerは、開発者から分散システムの複雑性を巧みに隠してくれる。しかし、その内部でトランザクションマネージャーがTrueTimeを睨みつけ、2PCのステートマシンを駆動させ、数々のPaxosグループと緊密に同期をとっているという「事実」から目を背けてはならない。

コードを書くとき、スキーマを定義するとき、常に想像するんだ。
「今、私の書いたこのクエリは、いくつの一覧（Paxos Group）のトランザクションマネージャーを巻き込んでいるだろうか？」

この問いを常に持てるエンジニアこそが、真にスケーラブルで堅牢なシステムを構築できる。
次の設計レビューでは、美しくインターリーブされたスキーマと、洗練されたトランザクション境界を見せてもらうとしよう。期待している。