【テクニカル・上級編】ロックの仕組み – Cloud Spanner

Cloud Spannerのロック機構：分散トランザクションにおける「動的均衡」の真髄

多くのエンジニアは、Cloud Spannerのロックを「行レベルのロックが自動でかかる便利な機能」程度に認識している。だが、真のアーキテクトであれば、その背後にある「分散システムにおける一貫性とスループットのトレードオフを、どうやって物理的に無効化しているのか」という点にこそ着目すべきだ。

Spannerは、TrueTimeによる外部整合性（External Consistency）を担保するために、単なるロックマネージャー以上の「調律」を行っている。今回は、その内部構造の深淵に潜り込みたい。

—

1. 2PL（二相ロック）とTrueTimeの共犯関係

Spannerのトランザクションは、本質的に厳密二相ロック（Strict 2PL）に基づいている。しかし、分散環境でこれを単純に実装すれば、ネットワーク遅延の餌食となり、スループットは崩壊する。

Spannerのロックが極めて特殊なのは、それがPaxosグループ内でのレプリケーションと密接に結合している点だ。

ロックの所有権（Lock Table）: ロックは各Paxosグループ（Split）のリーダーのメモリ上で管理される。
共有ロック（Shared）と排他ロック（Exclusive）: Read/Writeトランザクションにおいて、リーダーは読み書きするデータセットに対してロックを確保する。
TrueTimeの介在: ロックを解放するタイミング（コミットタイムスタンプの決定）は、Paxosの書き込みと同期し、かつTrueTimeの不確実性（$\epsilon$）を考慮した待機時間を経て確定する。

ここでのキモは、「ロックの待機時間」と「分散コミットの待機時間」をオーバーラップさせている点にある。これにより、ロック保持時間を極小化し、単なるデータベース以上の並行性を引き出しているのだ。

2. メモリ最適化：Lock Tableの限界と回避策

Spannerのリーダーは、ロック情報をメモリ上のハッシュテーブルで管理する。膨大な数の行に同時アクセスが発生した場合、ロックテーブル自体がボトルネック（いわゆる「ロック競合のホットスポット」）になることは避けられない。

ここで、アーキテクトとして意識すべきは以下の「極限の最適化」である。

頻発するロック競合を回避する設計思想

1. Read-Onlyトランザクションの活用:
ReadOnlyトランザクションは、ロックを取得しない（Snapshot Read）。特定のタイムスタンプを指定することで、ロックマネージャーをバイパスする。書き込みが必要ない場面では、これを使用しないのはアーキテクチャ上の罪である。
2. キー空間の分散化:
Spannerのロックは行単位だが、負荷はキーのハッシュ値に依存する。キーの先頭に「ホットスポットになりにくいプレフィックス」を付与し、複数のPaxosグループへ負荷を分散させるのが定石だ。
3. ロングトランザクションの撲滅:
ロックを長時間保持するトランザクションは、システム全体のスループットを物理的に低下させる。バックエンドでの重い処理をトランザクション内に含めるのは言語道断だ。

—

3. デッドロック検出：分散グラフの走査

Spannerは、各Paxosグループ内で待機グラフ（Wait-for Graph）を構築し、デッドロックを検知する。しかし、分散システムにおける「真のデッドロック検出」はNP困難に近い。

— 典型的だが注意すべきロック競合のシナリオ
— トランザクションAとBが逆順で更新を行う場合
— リーダーは待機グラフを検知し、一方をAbortさせる。

BEGIN TRANSACTION;
— 行Xの排他ロックを確保
UPDATE Users SET balance = balance – 100 WHERE id = ‘A’;
— 行Yの排他ロック待ちが発生
UPDATE Users SET balance = balance + 100 WHERE id = ‘B’;
COMMIT;

Spannerのデッドロック検知は、「待機時間（Lock Wait Timeout）」によるガードレールと、「周期的なグラフ探索」のハイブリッドだ。特に、分散トランザクションにおいて、リーダー同士が循環参照に陥るような複雑なケースでは、特定のタイムアウト値をトリガーに即座にロールバックを行う。

アーキテクトへの助言: 「デッドロックが起きたら再試行すればいい」という甘い考えは捨てろ。アプリケーション層での設計（アクセス順序の固定化）によって、ロック競合自体を論理的に排除するのが、我々が目指すべきプロフェッショナルのコードだ。

—

4. 結び：エンジニアが向き合うべき「物理の壁」

Cloud Spannerを使いこなすということは、「ネットワークの遅延を、分散合意アルゴリズムとロックの抽象化によってどう隠蔽するか」という戦いに身を置くことと同義だ。

ロックは単なる「データ保護の仕組み」ではない。それは、システム全体のリソース使用効率と、整合性のバランスを決定づける「心臓の鼓動」だ。

次にSpannerを触る際、君たちは単にSQLを書くのではなく、「今、どのPaxosグループのリーダーが、どの行のロックを確保し、どの程度の期間、Paxosのクォーラムを待機しているのか」を脳内でイメージしてほしい。それができれば、君はもうCloud Spannerのアーキテクトだ。

——真の性能は、設定値ではなく、設計の深淵に宿る。