Cloud Spannerの「神の視点」：TrueTimeとトランザクションタイムスタンプ・オーラクルを使いこなす
Cloud Spannerを単なる「リレーショナルなNoSQL」だと思っているなら、今すぐその認識を改めた方がいい。Spannerの本質は、Googleが物理法則（光速と時刻の不確実性）という制約を、原子時計とGPSという暴力的なまでのインフラでねじ伏せ、「グローバルな順序付け」を数学的に保証した点にある。
本稿では、Spannerの核となる「トランザクションタイムスタンプ」と、それを支えるTrueTimeの仕組みを、設計者の視点から解剖する。
—
1. TrueTime：なぜ「時刻のズレ」を許容できるのか
分散システムにおいて、ノード間の時刻同期は悪夢だ。NTPは数ミリ秒から数十ミリ秒の誤差を生む。しかし、Spannerはこれを「誤差を隠蔽する」のではなく、「誤差を仕様として扱う」という逆転の発想で解決した。
TrueTime APIが返すのは、単なる時刻 `t` ではなく、「[earliest, latest] というインターバル（不確実性区間）」だ。
- Waitルール: コミットタイムスタンプ `s` を決定する際、Spannerは `s > TrueTime.now().latest` となるまで待機する。
- 意味: これにより、「物理的に未来の時刻」で書き込まれることは絶対にあり得ない。この「待機」こそが、外部整合性（External Consistency）を担保する代償だ。
エンジニアへの教訓:
この「待機」はパフォーマンスに直結する。トランザクションのコミット待機時間は、TrueTimeの不確実性（デフォルトで最大7ms程度）に依存する。これを理解せずに「なぜレイテンシが安定しないのか」と悩むのは、物理学と戦っているのと同じだ。
—
2. トランザクションタイムスタンプ・オーラクル：順序付けの魔術
Spannerでは、書き込みが発生するとTrueTimeに基づいてトランザクションタイムスタンプが割り振られる。これが「グローバルな順序」となる。
強力な武器：`commit_timestamp` カラムの活用
Spannerのテーブル設計で、`commit_timestamp` を活用できているか？ これを主キーの一部やインデックスに組み込むことで、アプリケーション側で「複雑な時刻管理ロジック」を書く必要がなくなる。
— 注文履歴テーブルの設計例
CREATE TABLE Orders (
OrderId INT64 NOT NULL,
UserId INT64 NOT NULL,
Amount INT64 NOT NULL,
— 変更があった瞬間のコミット時刻をSpannerが自動生成
CommitTime TIMESTAMP OPTIONS (allow_commit_timestamp = true)
) PRIMARY KEY (OrderId);
— 読み取り時にこのタイムスタンプを使うことで
— 「その瞬間の状態」を矛盾なくスナップショット読み取りできる
SELECT FROM Orders WHERE CommitTime > ‘2023-10-01T00:00:00Z’;
—
3. 実務で「刺さる」設計パターンとアンチパターン
◎ 賢い設計：読み取り専用トランザクションでの活用
分析クエリやバッチ処理を行う際、`STALENESS` を活用せよ。Spannerはグローバルに整合したスナップショットを過去の任意の時刻（最大1時間前）で読み取れる。
Pythonクライアントでのスナップショット読み取り例
過去15秒時点の整合性が取れたデータを読み取る（読み取り専用なのでロック競合なし）
with database.snapshot(exact_staleness=datetime.timedelta(seconds=15)) as snapshot:
results = snapshot.execute_sql(“SELECT FROM Orders”)
この設計を知っているか否かで、システムの可用性とパフォーマンスは劇的に変わる。
× 致命的なアンチパターン：アプリケーションでのタイムスタンプ生成
「アプリケーション側で `time.now()` を取得してカラムに入れる」設計は、Spannerにおいては最大の愚行だ。
ノード間のクロックズレにより、トランザクションの論理的な順序が崩れる。必ずSpanner側で `spanner.commit_timestamp()` を生成させること。これこそが、グローバルな一貫性を担保する唯一の道だ。
—
4. パフォーマンスの境界線：スプリットとホットスポット
トランザクションタイムスタンプによる順序付けは、裏を返せば「主キーの先頭に順序性のある値（タイムスタンプ）を置くとホットスポットが発生する」というSpannerの物理的制約と向き合う必要がある。
- ホットスポット回避: タイムスタンプを主キーの先頭にするのは避けろ。`UUID` や `bit-reversed sequence` を使い、書き込みを複数のスプリット（データ分割単位）に分散させよ。
- 読み取りの最適化: 順序付けが必要なクエリに対しては、`ORDER BY` ではなく、適切なセカンダリインデックスを作成する。Spannerはインデックスも透過的に分散管理する。
—
結論：Spannerを使いこなすという哲学
Cloud Spannerは「速いデータベース」ではない。「正しい順序で、かつグローバルに整合した状態を維持し続ける、極めて稀有なデータベース」だ。
TrueTimeという物理的基盤の上に、トランザクションタイムスタンプという論理的秩序を構築する。この仕組みを理解したあなたは、もう「DBのロック競合」や「分散トランザクションの不整合」に夜も眠れない日々を送る必要はない。
設計レビューの際は、こう問いかけてほしい。
「そのトランザクションは、本当にグローバルな順序付けを必要としているか？ もしそうなら、TrueTimeの不確実性を設計の味方につけられているか？」
これに答えられるエンジニアこそが、真にSpannerを飼い慣らせるアーキテクトだ。
コメント