【テクニカル・上級編】トランザクション再試行ロジック – Cloud Spanner

Cloud Spannerのトランザクション再試行：その「不可避な競合」をいかに御するか

Cloud Spannerを単なる「スケールするRDBMS」と定義しているうちは、まだ表面しか見えていない。Spannerの本質は、分散トランザクションにおける「真実の合意（Paxos）」と「外部整合性（TrueTime）」の極致にある。

我々エンジニアが対峙すべきは、Spannerが強制する「楽観的並行性制御（OCC）」に起因するアボート（Aborted）だ。これは故障ではなく、システムが整合性を守るための「呼吸」である。この呼吸を止めることはできない。ならば、呼吸を最適化し、システムを止めることなくスループットを最大化する術を身につける必要がある。

—

1. なぜ「アボート」は起こるのか？：内部の視点

Spannerの読み書きトランザクションは、2相コミット（2PC）とPaxosの組み合わせで構成されている。競合が発生する主因は、対象となるスプリットの「ロック競合」と「タイムスタンプの衝突」だ。

特に高頻度で更新されるホットキーに対するトランザクションは、Paxosのリーダーノードにおいてシリアライズされる。もし、別のトランザクションが先にコミットを完了し、そのタイムスタンプが自らの読み取り範囲に影響を与えた場合、Spannerは一貫性を担保するために、問答無用で自らのトランザクションをアボートさせる。

これは、アプリケーション側の不備ではない。分散システムにおいて「直列化可能性（Serializable）」を維持するための物理的な制約だ。

2. 再試行ロジックの「限界突破」：指数バックオフの罠

多くのエンジニアは、単なる指数バックオフ（Exponential Backoff）を実装して満足する。だが、大規模システムではそれだけでは不十分だ。

アンチパターン：単純なスリープ

固定的な待機時間は、「Thundering Herd Problem（群れをなす衝撃）」を誘発する。全ノードが同時にアボートし、同じタイミングで再試行を投げれば、リーダーノードは再試行の嵐に飲み込まれ、スループットはゼロに収束する。

ベストプラクティス：ジッター（Jitter）の導入

再試行には「ランダムな揺らぎ」が不可欠だ。単なる乱数ではなく、フルジッター（Full Jitter）を実装せよ。

// 熟練の再試行戦略：Full Jitterによる負荷分散
func retryWithJitter(ctx context.Context, op func() error) error {
const maxRetries = 5
baseDelay := 10 time.Millisecond

for i := 0; i < maxRetries; i++ { err := op() if err == nil { return nil } // 競合エラー（Aborted）かどうかの厳密な判定 if spanner.ErrCode(err) != codes.Aborted { return err } // Full Jitterの計算: delay = rand(0, base 2^i) delay := time.Duration(rand.Int63n(int64(baseDelay (1 << i)))) select { case <-time.After(delay): continue case <-ctx.Done(): return ctx.Err() } } return fmt.Errorf("max retries exceeded") }

3. 「読み取り」と「書き込み」の分離というアーキテクチャ

トランザクション再試行のコストを最小化するための極意は、「トランザクションの範囲を可能な限り狭くする」ことだ。

読み取りの最適化: 可能な限り「読み取り専用トランザクション（Snapshot Read）」を使え。これにはロックが発生しない。
書き込みの分離: アプリケーションロジックをトランザクション内に詰め込んではならない。値を計算し、外部APIを叩き、その結果を持って「最後に」書き込む。トランザクションの時間はミリ秒単位であるべきだ。

4. メモリとCPUの「深層」：なぜ再試行がコストになるのか

再試行が発生するということは、クライアント側のメモリ上で再構築されるオブジェクトのライフサイクルが長くなることを意味する。大規模なトラフィック下では、GC（ガベージコレクション）のスパイクが再試行回数を増やし、さらなるアボートを呼ぶという「負のループ」が完成する。

これを防ぐためには、トランザクション関数の不変性（Immutability）を徹底し、再試行時に再利用可能なリソースを極限まで減らすこと。また、クライアントライブラリの `SessionPool` 設定を、ワークロードの特性に合わせてチューニングせよ。デフォルト値は「平均的な何か」であり、あなたの「特定の高負荷」に対する最適解ではない。

5. 伝説のアーキテクトからの助言

最後に、再試行ロジックを「隠蔽」することに固執してはならない。

アボートは、システムの状態を雄弁に物語るメトリクスだ。再試行回数（Retry Count）を必ず監視項目に入れよ。 もし再試行率が閾値を超えたなら、それはコードのバグではなく、データベースの設計（スプリットの設計やホットキー）に問題があるという合図である。

Spannerは、魔法ではない。物理法則に忠実な、極めて精緻な機械だ。その挙動を理解し、再試行という「調和」をシステムに組み込むことができたとき、君のアプリケーションは初めて、Spannerの真のパワーを享受できることになるだろう。

技術に妥協するな。その1ミリ秒の待機時間が、システム全体の命運を分けるのだから。