Cloud Spannerのデッドロック：分散トランザクションの深淵と「戦い方」
Cloud Spannerは、単なる「水平スケールするRDBMS」ではない。TrueTimeという物理的な時間同期を基盤に、Paxosアルゴリズムでコンセンサスを維持し、分散環境下で外部整合性（External Consistency）を保証する、いわば「物理法則に挑戦したソフトウェアの結晶」だ。
しかし、どれほど洗練されたアーキテクチャであっても、トランザクションの競合、そしてそれに伴うデッドロックという「分散システムの悪夢」からは逃れられない。本稿では、Spannerのロック管理の深層に触れ、なぜデッドロックが発生するのか、そしてそれをどう御すべきかについて、理論と実装の境界から解説する。
—
1. ロック管理のレイヤ：Lock TableとWait-for Graph
Spannerのロックは、各スプリット（Split）を管理する`Spanner Server`内の`Lock Table`で管理される。重要なのは、Spannerがロックの粒度を動的に最適化することだ。
通常のRDBMSと異なり、Spannerは分散環境である。あるトランザクションが複数のスプリットにまたがる際、各参加ノード（Participant）でロックが獲得される。ここで重要なのは、Spannerが「Wait-for Graph」を分散的に構築し、デッドロックを検知しているという事実だ。
なぜデッドロックは起きるのか？
Spannerのデッドロックは、主に以下の2つのパターンに集約される。
1. アクセス順序の不整合: トランザクションAが[Key1, Key2]の順にロックを要求し、トランザクションBが[Key2, Key1]の順に要求した場合。
2. ロックの昇格（Lock Promotion）: 読み取りモードで獲得したロックを、同じトランザクション内で書き込みモードに昇格させる際、他者のロックと競合が発生するケース。
—
2. Spannerのデッドロック検知メカニズム
Spannerのデッドロック検知は、待機状態の依存関係を追跡することで行われる。しかし、数百のノードにまたがる分散環境で、リアルタイムに完全なグラフを構築するのはオーバーヘッドが大きすぎる。
そこでSpannerは、「タイムアウトによる強制終了」と「バックオフ戦略」を基本線としている。
- Wait-for Graphの深層: Spannerは、ノード間で待機状態の情報をやり取りするが、検知にはコストがかかる。そのため、特定の閾値を超えた待機が発生した際、システムは「デッドロックの可能性」を排除するために、最も効率的と思われるトランザクションを優先的にアボート（Abort）させる。
- Abortの真実: アボートは敗北ではない。これは、Spannerが「整合性を維持するためのコスト」として許容している設計上の防波堤だ。
—
3. 極限の回避策：エンジニアが守るべき「戒律」
アプリケーション層でデッドロックを回避するためには、Spannerの特性を逆手に取る必要がある。
① アクセス順序の「正規化」
これは基本だが、最も強力だ。アプリケーションコード内で、ロックを取得するキーを常にソートしてからトランザクションを開始せよ。
— 悪い例: アプリケーションのロジック順にUPDATEを実行
— 良い例: キーを昇順にソートして、必ず小さい値からロックを獲得する
— キーの順序が保証されていれば、閉路（Cycle）は発生しない
② ロックの「先取り」と「粒度」
Spannerのトランザクション内で、`SELECT`を打つ際、将来的に`UPDATE`する可能性があるなら、`SELECT … FOR UPDATE`（またはロックを必要とする読み取り）を早い段階で行うこと。
遅延させると、ロックの昇格時にデッドロックが発生しやすくなる。
③ インタリーブ（Interleaving）の副作用を理解する
テーブルをインタリーブしている場合、親子関係にある行は物理的に近い場所に格納される。これはI/O効率は良いが、ロック競合の「ホットスポット」になりやすい。単一の親行に紐づく大量の子行を並列更新しようとすれば、即座に競合の嵐に見舞われる。
—
4. チーフアーキテクトからの提言：Abortを許容せよ
多くのエンジニアが「トランザクションのアボート」をシステムエラーと捉えるが、これは誤りだ。
Spannerのような楽観的かつ厳密な整合性を追求するシステムでは、「アボートは、システムが整合性を守るために発する正常なシグナル」である。
推奨される実装パターン
アプリケーション側では、`Aborted`エラーを例外としてキャッチし、指数バックオフ（Exponential Backoff）を用いたリトライを組み込むことが必須である。
擬似コード: べき等性を担保したリトライ戦略
def execute_transaction_with_retry(db):
for attempt in range(MAX_RETRIES):
try:
return db.run_in_transaction(transaction_func)
except AbortedError:
# べき等性が担保されているなら、再試行するだけで良い
# ただし、短期間に再試行を繰り返すと負荷を増大させるため
# 指数バックオフを導入する
sleep(2 attempt + random_jitter())
continue
raise Exception(“Max retries exceeded”)
—
結論：分散システムの高みへ
Cloud Spannerにおけるデッドロックとの戦いは、物理的な距離（光の速度）と、論理的な整合性（ACID）の折り合いをつける芸術だ。
デッドロックをゼロにしようと躍起になるな。それは不可能だ。代わりに、「デッドロックを発生させにくいデータ設計を行い、発生した際には美しくリトライする」、この姿勢こそが、Spannerを使いこなす唯一の道である。
真のエンジニアは、ツールを信じるのではなく、ツールの限界を知り、その限界の先にある最適解を設計する。健闘を祈る。
コメント