【実務・中級編】コミット待機 – Cloud Spanner

Cloud Spannerの「コミット待機」という魔法：TrueTimeと線形化可能性の正体

Cloud Spannerを単なる「SQLが使えるNoSQL」や「勝手にスケールするRDB」だと思っているなら、今すぐその認識を捨ててほしい。Spannerの真価は、分散システムにおける「時刻」という曖昧な概念を、物理的な限界ギリギリまで突き詰めて「真実」へと昇華させた点にある。

その核心にあるのが「コミット待機（Commit Wait）」だ。なぜSpannerは、世界中に散らばるノード間で整合性を保てるのか。今日は、この泥臭くもエレガントな仕組みを、現場の設計者の視点で深掘りする。

—

1. なぜ「待つ」必要があるのか？

分散システムにおいて、異なるノードで生成されたタイムスタンプを比較することは不可能に近い。クロック・スキュー（時計のズレ）があるからだ。

Spannerは、Googleのデータセンター内に配置されたGPSと原子時計を用いたTrueTimeという仕組みを採用している。だが、たとえ原子時計であっても、ネットワーク通信やハードウェアの物理的な限界により、「完全に同期した時刻」は得られない。必ず「この時刻とこの時刻の間にあるはずだ」という不確実性範囲（$\epsilon$）が存在する。

もし、あるトランザクション $T_1$ が時刻 $t_1$ でコミットされたとして、別のノードで $T_2$ が $t_2$ で読み込みを行った時、$t_2 < t_1$ なのに $T_1$ の結果が見えてしまうようなことがあれば、それは「線形化可能性（Linearizability）」の崩壊を意味する。 ここで登場するのがコミット待機だ。

Spannerは、トランザクションのコミットタイムスタンプ $s$ を割り当てた後、即座に結果を返さない。「不確実性範囲 $\epsilon$ が経過するまで」意図的に待機するのだ。これにより、確実に $t_{now} > s$ であることを保証し、全世界のどのノードから見ても「このトランザクションは過去のもの」として確定させる。

—

2. 実務へのインパクト：パフォーマンスと設計のトレードオフ

エンジニアが最も恐れるのは、「なぜかレイテンシがスパイクする」という現象だ。Spannerにおいて、このコミット待機はレイテンシの一部として組み込まれている。

避けるべき設計パターン

1. 頻繁な書き込みの集中:
コミット待機は、いわば「書き込みの物理的な制約」だ。単一の行やパーティションに対して猛烈な頻度で更新を投げれば、ロック待ちとコミット待機が重なり、スループットは確実に頭打ちになる。

対策: ホットスポットを避けるための主キー設計（シーケンシャルなIDを避ける、ハッシュ化する）は、この物理制約を緩和するための必須テクニックだ。

2. 外部システムとの密結合:
「トランザクションの中で外部APIを叩く」といった愚行は言語道断だ。コミット待機という物理的な待機時間がある中で、さらに外部のレイテンシが加われば、トランザクションは瞬く間にタイムアウトする。

—

3. ロジカルな設計指標：ReadOnlyトランザクションの活用

コミット待機を意識したとき、最も有効な武器になるのが「強整合性を維持した読み取り」だ。

Spannerでは、書き込みを伴わない「強整合性読み取り」において、特定のタイムスタンプを指定することができる。

— Python (google-cloud-spanner) での強整合性読み取りの例
with database.snapshot(read_timestamp=timestamp_bound) as snapshot:
# 指定した時刻の「確定したスナップショット」を読み取る
# コミット待機の影響を考慮しつつ、一貫したデータを取得可能
results = snapshot.execute_sql(“SELECT FROM Accounts WHERE ID = @id”, …)

もし、現在の最新データが必ずしも必要ない（数秒前のデータで許容できる）のであれば、Stale Read（陳腐化読み取り）を利用すべきだ。これにより、コミット待機やロックによる競合を完全に回避できる。

15秒前のスナップショットを取得（これならコミット待機を待つ必要がない）
from google.cloud.spanner import ReadTimestampBound
snapshot = database.snapshot(
read_timestamp_bound=ReadTimestampBound(exact_staleness=timedelta(seconds=15))
)

—

4. 伝説のアーキテクトからのアドバイス

実務でSpannerを扱う君たちへ伝えたいのは、「魔法を魔法のまま使うな」ということだ。

コミット待機は「コスト」ではなく「信頼の対価」だ。 数ミリ秒の待機と引き換えに、私たちは「世界中どこから叩いても整合性が崩れない」という、数年前までは夢物語だった一貫性を手にしている。
「書き込み」の回数を最小化せよ。 アプリケーション層でトランザクションをまとめ上げ、可能な限りバッチ化し、読み取りと書き込みの責務を厳格に分離する。これができているチームのSpannerは、極めて高いパフォーマンスを発揮する。

Cloud Spannerは、物理法則（光速やクロックの精度）に挑戦しているデータベースだ。その制約を理解し、その上で動くアプリケーションを書く。それこそが、真のクラウドネイティブなエンジニアの矜持である。

さあ、コードを開こう。あなたのアプリケーションは、この「時間の重み」を正しく扱えているか？