【テクニカル・上級編】トランザクションタイムアウト – Cloud Spanner

Cloud Spannerの「トランザクションタイムアウト」という名の深淵：分散トランザクションの死生観

Cloud Spannerを単なる「マネージドな分散RDBMS」と呼ぶのは、エンジニアとしての怠慢だ。あれは、分散システムにおける「整合性（Consistency）」と「可用性（Availability）」のトレードオフを、物理法則の限界まで押し広げた巨大な分散ステートマシンである。

多くのエンジニアが設定画面の片隅にある「トランザクションタイムアウト」を単なる安全装置と見なしている。だが、このタイムアウト値の背後には、Paxosアルゴリズム、TrueTimeによるクロック同期、そしてロックマネージャの残酷な現実が横たわっている。

本稿では、このタイムアウトという「神の見えざる手」が、Spannerの内部アーキテクチャにおいて何を制御しているのか、その深淵を覗く。

—

1. タイムアウトは「安全装置」ではない、「一貫性の番人」である

Spannerの分散トランザクションは、複数のSplit（シャード）にまたがる。このとき、コーディネータノードは各参加者に対して2フェーズコミット（2PC）を要求する。

ここで最も恐ろしいのは、「準備完了（Prepared）状態のまま、誰からもコンタクトがないゾンビトランザクション」だ。

もしトランザクションがタイムアウトなしに放置されれば、該当するロック範囲は永久に解放されず、Participantノードのメモリを食いつぶし、やがてシステム全体が「ロックのデッドロック」という名の静寂に包まれる。Spannerのタイムアウトは、この「分散システムにおけるデッドロック」を、強制的なRollbackという外科手術で防いでいるに過ぎない。

2. メモリとロックの局所性：なぜタイムアウトが重要か

Spannerのロックマネージャは、各Splitのレプリカ内に存在する。トランザクションが実行される際、そのトランザクションが参照する行データには排他制御（Read/Write Lock）が掛かる。

長期実行の代償: 大規模なバッチ処理や、極端に重いクエリが長時間走ると、その間、Spannerはトランザクションの状態情報をメモリ上に保持し続ける。
メモリ圧迫とGC: 保持されたロック情報がヒープメモリを圧迫すれば、GoランタイムのGC（ガベージコレクション）が頻発する。これがスパイクを生み、レイテンシをさらに悪化させるという「負のフィードバックループ」に陥る。

タイムアウトを設定することは、単に「止める」ことではない。「リソースの寿命を、システムの許容限界内に強制的に収束させる」というメモリ管理戦略そのものなのだ。

3. 実務的な限界設計：ベストプラクティスを超えて

多くの現場ではデフォルト値で運用されているが、高負荷・高スループットな環境では、以下の観点で「タイムアウトの再定義」を行う必要がある。

トランザクションの「時間的制約」をコードで表現せよ

クライアント側でタイムアウトを制御するのは基本だが、Spanner側の `CommitTimeout` も適切に調整すべきだ。

// Goでのトランザクション実行の例
// コンテキストにタイムアウトを付与し、Spannerの内部処理に強制的な期限を与える
ctx, cancel := context.WithTimeout(ctx, 15 time.Second) // 15秒以上は許容しない
defer cancel()

_, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, txn spanner.ReadWriteTransaction) error {
// 複雑なRead-Modify-Writeのロジック
// ここでタイムアウトが発生すると、Spanner側は即座にロックを解放し、
// 参加者ノードにアボートメッセージを伝播させる。
return nil
})

監視すべきメトリクス：`spanner.googleapis.com/api/request_count`

タイムアウトが頻発する場合、それはアプリの設計ミスか、Splitのホットスポット化のどちらかだ。

アボートレートの監視: `grpc_code = ‘DEADLINE_EXCEEDED’` を見逃すな。
レイテンシヒストグラム: p99.9のレイテンシがタイムアウト値に張り付いている場合、物理的なI/Oの限界を突破している。この時は、スキーマのインターリーブ設計や、主キーの分散（単調増加IDの回避）といった、よりプリミティブなレベルでの修正が必須となる。

—

4. チーフアーキテクトからの提言

君たちが直面している「タイムアウト」エラーは、Spannerが発している「これ以上このトランザクションを放置すると、システム全体の整合性が崩壊する」という悲鳴だ。

単にタイムアウト時間を延ばして延命を図る行為は、エンジニアとして最もやってはならないことだ。そうではなく、以下の問いを自問自答してほしい。

1. 「このトランザクションは本当に一つのアトミックな操作であるべきか？」
2. 「データの読み取りと書き込みの間に、不必要なネットワークI/Oを挟んでいないか？」
3. 「TrueTimeの同期精度を考慮した上で、スループットを最大化するトランザクション境界になっているか？」

Spannerはブラックボックスではない。それは、君たちのコードの書き方がそのまま「分散システムの物理特性」として現れる、誠実な鏡だ。タイムアウトという名の制約を受け入れ、その境界線内で最高のパフォーマンスを引き出すことこそが、真のエンジニアリングである。

これ以上の最適化を望むなら、次はストレージ層のSplit管理アルゴリズムについて議論しよう。準備はいいか。