分散Spannerの深淵：マルチノード環境における「分散デッドロック」とどう向き合うか
こんにちは。テックリードの私だ。
今回のコードレビューで、あるジュニアエンジニアが書いたトランザクション処理の設計を見て、私は思わず赤ペンを止めた。
「複数のスプリット（シャード）にまたがる更新処理で、なぜデッドロックが発生し得るのか。そして、Cloud Spannerはこのカオスをどうやって裏で調停しているのか、説明できるか？」
彼はフリーズした。無理もない。多くのエンジニアは、単一データベースのACIDトランザクションの挙動は理解していても、数千のノードにスケールアウトする分散データベースの「腸（はらわた）」で何が起きているかを知らない。
Cloud Spannerは、世界最高峰の分散RDBだ。しかし、物理の法則を曲げることはできない。複数ノードにまたがるトランザクション並行実行の世界では、「分散デッドロック（Distributed Deadlock）」が牙をむく。
今回は、Spannerのコアアーキテクチャがいかにしてこの難問に立ち向かっているのか、そして我々アプリケーションエンジニアがどう設計すべきかを、妥協のないロジックで伝授しよう。
—
1. コアアーキテクチャ：なぜ分散デッドロックが起きるのか
まず、Spannerのデータ分散モデルのおさらいだ。
Spannerはデータを「スプリット（Split）」という単位に分割し、Paxosグループによって複数のトランスポートノード間にレプリケーションしている。
単一のトランザクションが、異なるスプリットに存在する複数の行（Row）を更新する場合、以下のような分散トランザクション（2フェーズコミット / 2PC）のフローを踏む。
1. リーダーノードへのロック獲得要求: 各スプリットのリーダー（Paxos Leader）に対して、排他ロック（Exclusive Lock）を要求する。
2. コーディネーション: トランザクションコーディネーターが選出され、2PCのコミットプロセスをオーケストレーションする。
ここで悲劇が起きる。
- トランザクション A: スプリット 1 のロックを保持しつつ、スプリット 2 のロックを待っている。
- トランザクション B: スプリット 2 のロックを保持しつつ、スプリット 1 のロックを待っている。
単一のインスタンス内であれば、メモリ上の単一の待機グラフ（Wait-For Graph）をスキャンするだけでデッドロックを検知できる。しかし、スプリット 1 とスプリット 2 が物理的に異なるノード（あるいは異なるデータセンター）に存在する場合、誰が全体を俯瞰して「循環待ち（Cycle）」を検知するのか？
—
2. Spannerにおけるデッドロック検知のメカニズム
結論から言おう。Cloud Spannerは、完全なリアルタイム分散デッドロック検知アルゴリズム（Chandy-Misra-Haasのような分散スナップショットベースのグラフ解析）を、同期処理としてはやっていない。そんなことをすれば、グローバル規模での超低レイテンシと高スループットというSpannerのアイデンティティが崩壊するからだ。
代わりに、Spanner（および多くの分散SQLエンジン）が採用している防衛線は以下の2つだ。
① タイムアウトによる解消（Timeout-based Abort）
これが最も支配的なメカニズムだ。
Spannerのロックマネージャーは、トランザクションがロックを獲得できるまでの最大待機時間を厳しく管理している。一定時間（内部的なタイムアウト閾値）内にロックが取れない場合、システムは自ら身を引く。
[Tx A] —-(ロック待ち)—-> [Split 2のロック] (Tx Bが保持)
|
+— (一定時間経過: タイムアウト)
|
v
[ABORT] ──> トランザクションを強制アボートし、ロールバックを執行
アボートされたトランザクションは、クライアントライブラリ側で自動的にリトライされる（後述するベストプラクティス参照）。
② 厳密なタイムスタンプ順序付け（TrueTime APIの活用）
Spannerは、TrueTime（GPSと原子時計）による不確実性（$\epsilon$）を利用して、外部整合性（External Consistency）を保証する。読み取り専用トランザクションや、特定のコミット順序においては、このグローバルな順序付けが競合を調停するが、書き込みロックの競合においては、依然としてタイムアウトが最終防衛ラインとなる。
—
3. 現場で使える！堅牢な設計パターン
「タイムアウトでリトライされるなら、適当にコード書いても大丈夫だよね？」
――甘い。
高負荷時にデッドロックによるアボート（`ABORTED` エラー）が頻発すると、システム全体でリトライの嵐（Thundering Herd現象）が起き、スループットが劇的に低下する。最悪の場合、リクエストが雪崩を打って死に至る。
テクニカルリードとして、君たちには以下の設計パターンを厳守してほしい。
パターン A: アクセス順序の完全な正規化（Lock Ordering）
最もエレガントかつ確実な防御策は、「複数行を更新する際は、常に主キー（Primary Key）の昇順でアクセスする」というルールをコードベースに強制することだ。
❌ 悪い例（デッドロックの温床）
スレッドAとスレッドBでアクセス順序がバラバラ
def transfer_bad(transaction, from_id, to_id, amount):
# 順序を考慮せずにロックを取得しようとする
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance – {amount} WHERE AccountId = ‘{from_id}'”)
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance + {amount} WHERE AccountId = ‘{to_id}'”)
⭕ 良い例（順序の正規化）
def transfer_robust(transaction, from_id, to_id, amount):
# 主キーの辞書順でソートし、常に小さい方からロックを取得する
first_id, second_id = sorted([from_id, to_id])
# 常に決定論的な順序でSQLを実行
if first_id == from_id:
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance – {amount} WHERE AccountId = ‘{from_id}'”)
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance + {amount} WHERE AccountId = ‘{to_id}'”)
else:
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance + {amount} WHERE AccountId = ‘{to_id}'”)
transaction.execute_update(f”UPDATE Accounts SET Balance = Balance – {amount} WHERE AccountId = ‘{from_id}'”)
解説: どのトランザクションも「IDの小さい順」にロックを取るため、循環待ち（$A \to B$ かつ $B \to A$）が物理的に発生し得なくなる。これが王道にして最強の対策だ。
パターン B: インターリーブ（Interleave）構造の活用
Spannerの強力な武器である「インターリーブ（親子関係）」テーブルを設計に組み込む。親テーブルと子テーブル（例: `Customers` と `Orders`）をインターリーブしておくと、物理的に同じスプリット（または近接したスプリット）にデータが配置される確率が跳ね上がり、分散トランザクションのホップ数を削減できる。結果としてロック競合の窓を狭めることができる。
—
4. パフォーマンス上の注意点とモニタリング
実務において、デッドロックやロック競合は避けて通れない。だからこそ、「早期検知とメトリクス監視」がインフラエンジニアおよびアプリエンジニアの生命線となる。
1. `ABORTED` エラーの監視:
Cloud Spannerのモニタリングコンソールで、`Aborted Transactions` メトリクスを常に監視せよ。これが急増している場合、アプリケーション層でのロック競合（デッドロック含む）が起きている証拠だ。
2. トランザクションの粒度を最小化する:
トランザクション内で外部APIを叩いたり、重い計算をしたりしてはならない。ロックを保持する時間をミリ秒単位で切り詰めることが、分散デッドロックを防ぐ最大の秘訣だ。
3. 指数バックオフ付きリトライ（Exponential Backoff with Jitter）:
Spannerのクライアントライブラリはデフォルトで `ABORTED` エラー時の自動リトライを備えているが、カスタムロジックを書く場合は必ずランダムなジッター（Jitter）を入れたリトライを実装すること。
—
結びに代えて
Cloud Spannerは魔法の箱ではない。どれほど優れた分散データベースであっても、設計思想を無視した乱暴なトランザクションを投げ込めば、分散デッドロックという名の壁に跳ね返される。
次にコードレビューをする時、私はこう問いかける。
「このトランザクション、本当に分散ロックの競合を最小化する順序で書かれているか？」と。
その問いに自信を持って答えられるコードだけが、プロダクションの荒波を生き残る。
さあ、設計図を書き直そうか。
コメント