トランザクションマネージャーの深層：Cloud Spannerの分散トランザクションを極限まで使いこなす
こんにちは。テクニカルリードの私だ。
今日のコードレビューで、誰かが「とりあえずトランザクションで囲っておけば安全だよね」という甘い認識でコードを書いているのを見かけた。
RDBの感覚でCloud Spannerを触っていると、必ず痛い目を見る。
Spannerは単なる「可用性の高いMySQLやPostgreSQL」ではない。地球規模のスケールで外部一貫性（External Consistency）を実現する、モンスター級の分散データベースだ。
その心臓部であり、すべての整合性とスループットの命運を握っているのが「トランザクションマネージャー（Transaction Manager）」である。
今回は、このトランザクションマネージャーが内部で何をやっているのか、2PC（2段階コミット）、ロック管理、そしてデッドロック検出のメカニズムを解剖し、我々アプリケーションエンジニアが「どう設計し、どう実装すべきか」をロジカルかつシャープに伝授しよう。
—
1. トランザクションマネージャーの正体と分散トランザクションのライフサイクル
Spannerのデータは、パーティション分割されて世界中のPaxosグループ（スプリット）に分散配置されている。
単一のスプリット内で完結する書き込みならローカルで済むが、複数のスプリットにまたがる更新（これが圧倒的に多い）が発生した瞬間、トランザクションマネージャーが真価を発揮する。
ライフサイクルの全貌
1. 読取りフェーズ（Read Phase）:
アプリケーションがクエリを発行し、データを読み込む。悲観的ロックを取らない限り、データはロックされない。
2. 変転フェーズ（Mutation Buffering）:
書き込み内容は、クライアント側（あるいはコミットコーディネーター）でバッファリングされる。
3. コミットフェーズ（2PC：2-Phase Commit）:
ここが肝だ。複数のスプリットにまたがる場合、トランザクションマネージャー（正確にはリーダーレプリカの中から選ばれたコーディネーター）が指揮を執る。
- Prepareフェーズ: コーディネーターは、関与するすべてのスプリット（参加者）に対し、「このトランザクションをコミットできるか？」と問う。各参加者はPaxosログに準備完了を書き込み、ロックを獲得して応答する。
- Commitフェーズ: すべての参加者から「Yes」が返ったら、コーディネーターはコミットを決定し、全参加者に通知する。これでTrueTimeに基づくタイムスタンプが確定し、外部一貫性が保証される。
[Client] —> (1. Mutate & Commit Request) —> [Coordinator (Paxos Leader)]
|
+—————————-+—————————-+
| (2. Prepare) | (2. Prepare)
v v
[Participant Split A] [Participant Split B]
- Lock acquired – Lock acquired
- Paxos Log (Prepared) – Paxos Log (Prepared)
| |
+<------------------- (3. Commit) ------------------------+
|
v
[Commit Success]
---
2. ロック管理とデッドロック検出の裏側
「Spannerはロックフリーで動く」と誤解しているエンジニアが多いが、それは読み取りの話だ。書き込み（Write/Read-Write Transaction）においては、厳密な排他制御が行われている。
悲観的ロックの嵐を防ぐ：ミューテーションの順序
Spannerは、競合が発生した際、行レベルの悲観的ロック（Pessimistic Locking）を取得する。
もしあなたが設計レビューで、以下のようなコードを通そうとしたら、私なら即座に差し戻す。
// 【アンチパターン】競合を招きやすいトランザクション処理
databaseClient.readWriteTransaction().run(transaction -> {
// 1. 残高を読み込む
Struct row = transaction.readRow(“Accounts”, Key.of(userId), Arrays.asList(“Balance”));
long balance = row.getLong(0);
// 2. 外部APIの呼び出しや重いビジネスロジック（ここで数秒ブロックすると最悪）
long calculated = heavyBusinessLogic(balance);
// 3. 書き込み
transaction.bufferUpdate(“Accounts”,
Value.struct(“UserId”, userId, “Balance”, calculated));
return null;
});
なぜこれが最悪なのか？
トランザクションが保持しているロック（この場合は `Accounts` テーブルの該当行）は、トランザクションが完了するまで解放されない。
その間に外部APIを叩いたり、重い処理を入れたりすると、ロックホルダーが長時間居座る形になり、後続のトランザクションが雪だるま式にブロック（待ち状態）される。これがレイテンシースパイク、ひいてはスループット低下の主原因だ。
デッドロック検出の仕組み
Spannerのトランザクションマネージャーは、待機グラフ（Wait-for Graph）をバックグラウンドで常に監視している。
Aが持っているロックをBが欲しがり、Bが持っているロックをAが欲しがる状態になると、トランザクションマネージャーは迅速にデッドロックを検知する。
検知された場合、どちらか一方のトランザクションがアボート（強制終了）され、`ABORTED` エラーがクライアントに返される。
—
3. 実務で絶対に守るべき堅牢な設計パターン
では、このトランザクションマネージャーを敵に回さず、味方につけて極限のパフォーマンスを引き出すにはどうすればいいか。設計の鉄則を授けよう。
鉄則1: 読み取りと書き込みの分離（Read-Only Transactionの活用）
データを更新しないのであれば、絶対に Read-Write Transaction を使ってはならない。
`Read-Only Transaction` はロックを一切取得しないため、競合によるブロックが発生しない。スループットは理論上の上限近くまで跳ね上がる。
// 【推奨】ロックを取らないリードオンリー
try (ReadOnlyTransaction tx = databaseClient.readOnlyTransaction()) {
Struct row = tx.readRow(“Accounts”, Key.of(userId), Arrays.asList(“Balance”));
// 安全かつ高速に読み取り
}
鉄則2: Read-Write Transaction 内の処理は「極限まで短く」
トランザクションブロック内には、DBの読み書き以外のロジック（外部通信、複雑なメモリ上の計算など）を一切含めないこと。
データをメモリにロードし、計算し、バッファに詰めてコミットするまでを、数ミリ秒単位で終わらせるのがプロの仕事だ。
鉄則3: アボート（`ABORTED`）に対するリトライの実装
Spannerの分散環境では、競合によるアボートは「仕様」である。例外をキャッチして即座に死ぬような設計は論外だ。
公式クライアントライブラリは自動リトライを内蔵しているが、独自の複雑な副作用（メール送信など）をトランザクション内に含めると、リトライ時に二重送信が起きる。
副作用は必ずコミット成功後に実行する（あるいは冪等性を担保する）。
—
4. パフォーマンス上の注意点：ホットスポットの回避
トランザクションマネージャーを悩ませる最大の敵が「ホットスポット」だ。
例えば、全ユーザーの「累計アクセス数」を管理する単一の行（例：`Counter` テーブルの `id = “total”`）に対して、毎秒数万件のRead-Write Transactionを発行したとする。
いくらSpannerが水平分散できようとも、同一の行（単一のPaxosグループの単一リーダー）に書き込みが集中する瞬間、トランザクションマネージャーのロック待ちのキューが爆発する。
対策：カウンターのシャーディング
もしカウンターのインクリメントが必要なら、キーをシャード（分散）させろ。
// シャーディングキー（例: 0〜9のランダムなプレフィックスを付与）
String shardedKey = “total_” + new Random().nextInt(10);
transaction.bufferUpdate(“Counters”,
Value.struct(“CounterId”, shardedKey, “Value”, currentValue + 1));
読み取る時は、それらを集約（SUM）する。この一手間で、トランザクションマネージャーの負荷は1/10に軽減される。
—
チーフアーキテクトからの総括
Cloud Spannerのトランザクションマネージャーは、分散システムの矛盾を魔法のように解決してくれる黒魔術ではない。物理法則と分散合意アルゴリズム（Paxos）の制約の中で、極限まで最適化された精巧なエンジンだ。
その仕組み——2PCのオーバーヘッド、悲観的ロックの挙動、デッドロックのメカニズム——を正しく理解していれば、あなたの書くコードはリクエストが急増してもびくともしない、堅牢で美しいシステムになるはずだ。
次のコードレビューでは、誰がトランザクション内に重い処理を混ぜ込んでいるか、私よりも先に君たちが見抜いてくれ。期待している。
コメント