【実務・中級編】ロックテーブル – Cloud Spanner

Spannerの頭脳：ロックテーブルの内部挙動と、競合を制する分散トランザクション設計

こんにちは。テックリードの私だ。
今日のコードレビュー、あるいはアーキテクチャレビューで、また「とりあえずトランザクションで囲んでおけば動くだろう」という甘い設計を見かけた。

Cloud Spannerは、無限にスケールするかのような錯覚を抱かせる美しいデータベースだ。しかし、その魔法の裏側にある物理法則を無視した設計は、高負荷時に容赦なく「ロック競合とレイテンシの悪夢」となって跳ね返ってくる。

今回は、Spannerの並行性制御と競合制御の心臓部である「ロックテーブル（Lock Table）」のコアアーキテクチャに深くメスを入れる。
教科書的なドキュメントには書かれていない、各ノードのメモリ上で何が起きているのか、そして我々エンジニアが実務でどう立ち回るべきかをロジカルに伝授しよう。

—

1. ロックテーブルとは何か：分散メモリ上の闘技場

Spannerにおける「ロックテーブル」は、単なる概念上の用語ではない。各スプリット（Split）を保持するリーリーダー（Leader Replica）のメモリ上に存在する、極めて高速なインメモリデータ構造だ。

Spannerのトランザクションは、基本的にはPessimistic Locking（悲観的ロック）と2段階ロック（2PL: Two-Phase Locking）、そしてTrueTimeによる外部整合性（External Consistency）の三位一体で成り立っている。

何が管理されているのか？

ロックテーブルは、「どのトランザクション（ID）」が、「どの行（Row）」または「どのキー範囲（Range）」に対して、「どのようなモード（読取／排他）」のロックを保持・要求しているかを管理している。

どこに存在するのか？

データスプリットのリーダーノード内だ。つまり、データが分散していれば、ロックテーブルもまた分散している。ここがポイントだ。単一のマスターサーバーが存在するわけではない。

ロック競合の本質

2つのトランザクションが同じキーに対して書き込みを行おうとしたとき、リーダーノードのロックテーブル上で衝突が発生する。
先行するトランザクションがロックを解放するまで、後続のトランザクションの処理スレッドはロックテーブルのキューで待機（またはアボート）させられる。この「待機」が積もりに積もった状態が、いわゆるホットスポット問題の正体だ。

—

2. 実務で踏み抜く「ロック競合」のアンチパターン

コードレビューで最もよく指摘する、ロックテーブルを爆発させる悪夢のような設計パターンを見ていこう。

アンチパターン A: 単一カウンターのインクリメント

「ユーザーのアクセス数」や「在庫の残数」を管理するために、1つの行をひたすらUPDATEし続ける設計だ。

— 【悪夢のパターン】全リクエストがこの1行のロックを奪い合う
UPDATE Inventory
SET quantity = quantity – 1
SHARD_ID = ‘item_001’;

何が起きているか？
Spannerのロックテーブル上には、`item_001` の行に対する排他ロック（Exclusive Lock）の獲得待ち行列が形成される。数千のスレッドがこの1行のロックを奪い合うため、CPUはロックの管理とコンテキストスイッチに消費され、スループットは劇的に低下、最終的にタイムアウト（DEADLINE_EXCEEDED）の嵐となる。

アンチパターン B: 巨大な範囲（Range）を巻き込むトランザクション

読み取りと書き込みの境界が曖昧なトランザクションで、広範囲のプレフィックスに対してロックを要求してしまうケースだ。

— 【危険なパターン】テーブル全体、あるいは広範囲なキーをスキャンしながら更新
BEGIN TRANSACTION;

SELECT FROM Orders
WHERE status = ‘PENDING’ AND created_at < '2023-10-01'; -- この間に該当する数千行に対してロックが波及する可能性がある UPDATE Orders SET status = 'ARCHIVED' WHERE status = 'PENDING' AND created_at < '2023-10-01'; COMMIT; 何が起きているか？
範囲クエリと更新が同一トランザクション内で行われると、Spannerはファントムを防ぐためにキー範囲に対するロック（Range Locks）を確保しようとする。これにより、他のトランザクションがその範囲への挿入や更新を行えなり、並行性が完全に殺される。

—

3. ロックテーブルを制する堅牢な設計パターン

では、我々はこの分散ロックの制約の中でどうシステムを設計すべきか。プロダクションで実証済みのパターンを授けよう。

設計パターン 1: シャーディング・カウンター（Shard Counter）

単一の行への集中を避けるため、キー空間を意図的に分割し、ロックの競合先を分散させる手法だ。

— 【推奨パターン】シャードID（例: 0〜9）を付与してカウンターを分散
— 更新時はランダム、あるいはハッシュ値からシャードを選択する
UPDATE InventoryShards
SET quantity = quantity – 1
WHERE item_id = ‘item_001’ AND shard_id = 3;

— 読み取り時は全シャードをSUM集計する
SELECT SUM(quantity) FROM InventoryShards WHERE item_id = ‘item_001’;

効果: ロックテーブル上の競合先が1/Nに分散するため、スループットが線形にスケールするようになる。

設計パターン 2: 読み取り専用トランザクション（Read-Only Transactions）の徹底

データを変更しない（参照系）処理には、絶対に書き込み用トランザクションや悲観的ロックを使ってはならない。

Spannerの真骨頂は、読み取り専用トランザクションがロックを一切取得しない点にある。TrueTimeの仕組みにより、過去のタイムスタンプを指定した一貫性のある読み取り（Bounded Stalenessなど）が、ロックテーブルに一切負荷をかけずに実行できる。

// Java (Spanner Client) の例: ロックフリーな読み取り
TimestampBound bound = TimestampBound.ofExactStaleness(Duration.ofSeconds(10));
try (ReadOnlyTransaction tx = databaseClient.readOnlyTransaction(bound)) {
ResultSet resultSet = tx.executeQuery(
Statement.of(“SELECT FROM Users WHERE user_id = ‘12345’”)
);
// ロックテーブルを参照しないため、高スループットを維持
}

—

4. チーフアーキテクトからの実践的な運用知見

最後に、本番運用やパフォーマンスチューニングの現場で役立つ、実践的な知見をいくつか置いておく。

1. Cloud Monitoringの監視指標を見極めろ

`Spanner/Transactions/Lock_Wait_Seconds` や `Spanner/Transactions/Aborted_Transactions` のメトリックを必ずダッシュボードに置け。
ロック待ち時間が跳ね上がっている場合、それはコードのどこかで「ホットスポットへの集中」や「ロングラン・トランザクション」が発生している動かぬ証拠だ。

2. トランザクションは短く、小さく保て

トランザクション内で外部API呼び出し（RPCなど）を行う愚行は論外だ。ネットワークレイテンシの分だけロックの保持時間が延び、ロックテーブルを圧迫する。ビジネスロジックはトランザクションの外で完結させ、Spannerへのアクセスは極限まで凝縮させろ。

3. 読み取り・書き込みの順序を統一せよ

複数のテーブルやキーを更新する際、アプリケーション全体でアクセス順序（例: テーブルAの後にテーブルB）を厳格に統一すること。デッドロック（Spanner内部でのアボート）の発生確率を劇的に減らすことができる。

—

まとめ

Cloud Spannerのロックテーブルは、分散環境でありながらACID特性を担保するための、いわば「秩序の守護者」だ。
そのメカニズムを理解せず、リレーショナルデータベースの古い常識のままコードを書けば、システムはやがて息絶える。

しかし、その背後にあるメモリ構造と競合の原理を理解し、「ロックの粒度を細かくする」「読み取り専用を徹底する」「ホットスポットを回避する」という原則をコードに落とし込めば、Spannerは君の期待を遥かに超えるスケーラビリティと堅牢性で応えてくれるはずだ。

次のコードレビューでは、これらの視点を持ってチームメンバーのプルリクエストを厳しく、そして愛を持ってチェックしてほしい。健闘を祈る。