Cloud Spannerの「見えざる壁」を突破せよ：トランザクション制限と生存戦略
Cloud Spannerを「ただの分散RDBMS」だと思っているなら、今すぐその認識を改めるべきだ。Spannerは、TrueTimeという神の視点と、Paxosによる強整合性を両立させた、ある種の「物理法則の限界に挑むシステム」である。
しかし、その圧倒的なスケーラビリティの代償として、開発者が決して踏み越えてはならない「トランザクションの境界線」が存在する。今日は、現場で血を流すエンジニアのために、ドキュメントの行間にある「真の制約」と、そこを突破するためのアーキテクチャ設計論を語ろう。
—
1. 10秒の壁：トランザクション実行時間という呪縛
Spannerの読み取り書き込みトランザクション（RWトランザクション）は、デフォルトで最大10秒という制約を持つ。これを超えると、システムは容赦なく`DeadlineExceeded`を叩きつけてくる。
なぜ10秒なのか？
これは単なる恣意的な制限ではない。Spannerの楽観的並行制御（OCC）において、長時間トランザクションは「ロックの持ち逃げ」となり、システム全体のパイプラインを停滞させる癌になるからだ。
【現場のアンチパターン】
- 外部API呼び出しをトランザクション内で行う。
- 大量の行を読み込んでから、クライアントサイドで複雑な計算をして書き戻す。
【設計の処方箋】
トランザクションは「極限まで短く」が鉄則だ。
1. 事前計算: 必要な値の計算はトランザクション外で済ませる。
2. データの局所性: 読み取る範囲を最小化する。
3. 外部APIは非同期: トランザクション完了後にPub/Sub等で後続処理をキックせよ。
—
2. ロックの飽和：メモリという名の物理的制約
Spannerには「1トランザクションあたりのロック数」の制限はないが、「1トランザクションが保持できる変異（Mutation）のサイズ」と「メモリ消費量」という実質的な壁がある。
特に注意すべきは「読み取り後の書き込み」だ。あまりに広範囲をロックし続けると、他のトランザクションが待機列で飢餓状態に陥り、最終的にスループットが崩壊する。
堅牢な設計パターン：IDのバッチング
数万件の更新を一つのトランザクションで処理しようとするな。それはSpannerの設計思想に対する冒涜だ。
NG: 巨大なループで更新を詰め込む
Mutation数が膨大になり、ロック競合とメモリ不足を誘発する
OK: トランザクションを細分化し、バッチ処理する
def update_records_safely(db, ids):
batch_size = 500
for i in range(0, len(ids), batch_size):
subset = ids[i:i + batch_size]
# 小さな単位でコミットを刻むことで、ロック保持時間を極小化する
db.run_in_transaction(atomic_update_logic, subset)
—
3. ホットスポットの回避：パフォーマンスの真の敵
制限値そのものよりも怖いのが「特定のキーへの集中」だ。Spannerは分散キーに基づき範囲を分割するが、一つのキー（あるいは狭い範囲）に書き込みが集中すると、単一のPaxosグループがボトルネックとなる。
【伝説のエンジニアからのアドバイス】
「連番（インクリメントID）」や「タイムスタンプそのもの」を主キーにするのは今すぐやめろ。それはSpannerの分散性能をドブに捨てる行為だ。
- UUID v4の使用: 物理的にデータを分散させ、書き込みの並列性を最大化せよ。
- キーの逆転: タイムスタンプが必要なら、ハッシュ値をプレフィックスとして付与し、書き込み先を意図的に拡散させろ。
—
4. 読み取り専用トランザクションという「隠し玉」
「トランザクションで落ちる」という相談を受けると、大抵の場合、読み取りと書き込みが混在している。
書き込みが不要なデータ取得なら、「読み取り専用トランザクション（Read-only Transaction）」を積極的に使え。これはロックを取得せず、かつスナップショット読み取りを提供するため、書き込みトランザクションと競合しない。
スナップショット読み取りの例
これならロック競合を一切気にせず、読み取り専用のノードをスケールさせられる
with db.snapshot() as snapshot:
results = snapshot.execute_sql(“SELECT FROM Orders WHERE Status = ‘PENDING'”)
# ここでどれだけ時間をかけて処理しても、書き込みの邪魔にはならない
—
結び：Spannerを操るということ
Spannerの制約は、あなたを縛る鎖ではない。それは「巨大な負荷に耐えうるシステムを作るための規律」だ。
1. トランザクションは10秒以内。
2. ロックは最小限、かつ短期間で解放。
3. 書き込みはUUIDで分散。
4. 読み取り専用はロック不要の快楽を利用せよ。
コードを書く前に、常に「この処理は本当に単一トランザクションで行う必要があるか？」と自問自答せよ。その問いかけこそが、あなたのシステムを「止まらない巨大インフラ」へと進化させる唯一の道だ。
現場からは以上だ。コードに戻れ。次回の設計レビューで、君の美しいトランザクション設計が見られることを期待している。
コメント