【テクニカル・上級編】読み取り書き込みトランザクションの制限 – Cloud Spanner

Cloud Spannerのトランザクション限界：分散合意とロックの「見えざる境界線」

Cloud Spannerは、CAP定理の呪縛を解き放ち、外部整合性（External Consistency）と高可用性を両立させた奇跡のようなシステムだ。だが、その恩恵を享受する一方で、我々エンジニアは、この「分散データベースの聖杯」が物理法則の制約下にあることを忘れてはならない。

特に、読み書きトランザクション（Read-Write Transaction）において、システムの限界にどう対峙するか。それは単なるリファレンスの暗記ではなく、Spannerの内部メカニズム――Paxos、ロックマネージャ、そして分散トランザクション調整――への深い洞察が問われる領域だ。

今日は、ドキュメントの隅に小さく書かれた「制約」の裏側にある、真の限界について語ろう。

—

1. 10秒の壁：トランザクションタイムアウトの深層

Spannerの読み書きトランザクションには、デフォルトで10秒という実行時間制限がある。多くの者がこれを「単なる設定」と捉えるが、それは誤りだ。

なぜ10秒なのか？

この制限は、「Paxosグループ間の同期オーバーヘッド」と「デッドロック回避の収束性」に起因する。Spannerは分散環境で直列化可能性（Serializable）を保証するために、トランザクションの各ステップでロックを獲得し、コミット時に2フェーズコミット（2PC）を介したPaxosによる合意形成を行う。

もし、10秒を超えてトランザクションが留まれば、それはシステム全体に「ゾンビロック」を撒き散らすリスクを孕む。分散システムにおいて、長寿命のトランザクションは、ロックの競合チェーンを肥大化させ、最終的にはシステム全体のレイテンシを指数関数的に悪化させるガン細胞となる。

チーフアーキテクトからの助言:
10秒を超えそうな複雑な処理は、決して一つのトランザクションに詰め込んではならない。それは設計の敗北だ。ビジネスロジックを「読み取り」と「非同期書き込み」、あるいは「事前計算による状態更新」へと分割せよ。

2. ロック保持の限界：メモリ上の物理的制約

Spannerのロックマネージャは、各スプリット（Split）のLeaderノードのメモリ上で動作する。ここで重要なのは、「ロック数」は「トランザクション内の行数」に正比例し、かつメモリリソースを直接消費するという点だ。

ロック解放のメカニズム

トランザクション内で膨大な行を読み込み、さらに更新を加えようとすると、ロックマネージャのインメモリテーブルが爆発する。これがメモリ制限に達すると、Spannerはトランザクションを即座にアボート（Abort）させる。

— 不適切なクエリの例:
— 全行をスキャンして更新をかけるような設計は、ロックの爆発を招く
UPDATE MyTable SET Status = ‘PROCESSED’ WHERE Status = ‘PENDING’;

もしこのテーブルが数百万行あれば、ロックマネージャはパンクする。大規模な更新が必要な場合は、「バッチ処理への分割」が絶対的な正義だ。

Key Range単位の分割: IDの範囲（例: 1-1000, 1001-2000）でバッチを切る。
書き込みの冪等性: 分割されたバッチがリトライされても安全な設計をインフラ層ではなく、データモデル層で担保する。

3. 分散トランザクションの「隠れたコスト」：2PCとレイテンシ

複数のスプリットに跨るトランザクションは、2PC（2フェーズコミット）を誘発する。このとき、最もレイテンシを支配するのは「最も遅いPaxosグループの応答」である。

内部構造のリアル

1. Prepareフェーズ: 全参加者が書き込み権限をロックし、ログをPaxosで合意させる。
2. Commitフェーズ: コーディネータがコミットを決定し、全参加者に反映を指示する。

この間、対象となったすべてのスプリットでロックが保持され続ける。つまり、「1つのトランザクションが、地球上の異なるリージョンにまたがる複数のLeaderノードのロックを同時に握り続ける」という状態が生まれる。

このとき、もしネットワークの微小な揺らぎ（Jitter）があれば、ロック保持時間が延び、他のトランザクションが雪崩式に待機させられる。これを「ロック競合の増幅」と呼ぶ。

4. 極限のチューニング：アーキテクトの視点

限界を突破するためには、以下の原則を徹底してほしい。

1. ロック範囲の最小化: 必要なカラムのみにアクセスし、範囲選択（Range Scan）は可能な限り狭く絞る。インデックスの設計が悪いと、意図しない行までロックする羽目になる。
2. 読み取りと書き込みの分離: 書き込み前の読み取りは、`Snapshot Read`を活用してトランザクション外で行う。ロックを握るのは、本当に変更を行うその瞬間だけにする。
3. スプリットの設計: スキーマ設計時にPrimary Keyの構成を誤ると、特定のスプリットに負荷が集中し、ロックのホットスポットが発生する。分散データベースの恩恵を殺さないためには、負荷を均一に分散させるKey設計が不可欠だ。

—

結論：Spannerを「ただのDB」として扱うな

Cloud Spannerの限界は、システムの欠陥ではなく、「分散環境で整合性を担保するための物理的な代償」だ。

我々アーキテクトがやるべきことは、この限界にギリギリまで近づくような粗雑なコードを書くことではない。トランザクションのスコープを極限まで小さくし、分散の恩恵を最大限に引き出すための「エレガントなデータフロー」を設計することだ。

もしトランザクションがタイムアウトし、ロック競合で悲鳴を上げているなら、それはSpannerが「設計の修正」を求めているサインだ。機械に無理を強いるな。アーキテクチャで解決せよ。

それが、真のエンジニアリングというものだ。