TrueTimeとタイムスタンプオラクル（TPO）：Cloud Spannerの最強にして最大の「ボトルネック」をどう飼いならすか
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいはアーキテクチャレビューで、君たちはまた「なぜこのクエリがレイテンシを食っているのか」「なぜこの書き込みでコンテンション（競合）が起きるのか」頭を悩ませていることだろう。
Cloud Spannerを「無限にスケールするマネージドRDB」とだけ捉えているなら、それは設計の初期段階で致命傷を負うフラグだ。Spannerの心臓部は、分散ストレージでもなければPaxosグループの分散合意アルゴリズムだけでもない。
それを統御する「タイムスタンプオラクル（TPO）」と「TrueTime」のコンビネーションこそが、このデータベースの美しさと恐ろしさの本質だ。
今回は、この核心部分に真っ向からメスを入れる。綺麗事抜きの実務レベルの知見を授けよう。
—
1. タイムスタンプオラクル（TPO）と TrueTime の正体
まず、前提を揃えよう。Spannerはグローバルに分散したノード間で、「ロックなしで外部整合性（External Consistency / 厳密な直列化可能性）」を実現している。これを支えるのが、モノトニック（単調増加）にトランザクションのコミットタイムスタンプを割り当てるタイムスタンプオラクル（TPO）と、物理時刻の不確実性をAPIとしてラップしたTrueTimeだ。
TrueTimeの本質は「時刻の幅（Uncertainty）」にある
世の中のエンジニアの9割は、TrueTimeを「Googleが作っためっちゃ正確なNTP（時計）」と誤解している。違う。TrueTimeの本質は、時刻を絶対値ではなく「$[earliest, latest]$」という幅（$\epsilon$:イプシロン、通常数ミリ秒）として扱う点にある。
[ TrueTimeの確実性の窓 ]
過去 ———————– [earliest now latest] ———————–> 未来
|<--- 2 ε --->|
TPOはこのTrueTimeの不確実性（$\epsilon$）を考慮し、「絶対に因果関係の順序が逆転しない」ことが数学的に証明された未来のタイムスタンプをトランザクションに割り当ててからコミットを確定させる。
つまり、Spannerのトランザクションは、コミットの瞬間に必ず「$\epsilon$ の待機（Commit Wait）」を強制される。これが、Spannerの書き込みレイテンシの物理的な下限値の正体だ。
—
2. 設計レビューで頻発するアンチパターン
このTPOとTrueTimeの挙動を理解していないと、次のような「やってはいけない設計」を平気でプロダクションに投入してしまうことになる。
アンチパターン A: ホットスポットを生成するシーケンシャルキー
「分かりやすいように、IDはインクリメンタルな数値にしよう」「ミリ秒単位のタイムスタンプをプレフィックスに付けよう」。
――これ、Spannerでは最悪手だ。
— 【悪夢のDDL】これを作った瞬間、単一のPaxosグループに書き込みが集中する
CREATE TABLE Transactions (
TransactionId STRING(64) NOT NULL,
TransactionTime TIMESTAMP NOT NULL,
Payload STRING(MAX),
) PRIMARY KEY (TransactionTime, TransactionId); — タイムスタンプを先頭にしている！
なぜダメなのか？
TPOは単調増加するタイムスタンプを厳密に管理し、書き込みの順序を裁定する。そこにアプリケーション側からも単調増加するキー（`TransactionTime` や自動インクリメント風のID）で書き込みを殺到させると、特定のSplits（シャード）と、それを担当する単一のリーダーレプリカに書き込みが完全に直列化（コンテンション）する。
TPOがいくら優秀でも、物理的な単一リーダーのCPUとネットワーク帯域が枯渇すれば、スループットは地に落ちる。
【正しいアプローチ：ビット反転やUUIDv4による負荷分散】
— 【推奨設計】ハッシュプレフィックスやUUIDでキー空間に負荷をキレイに分散させる
CREATE TABLE Transactions (
ShardedId STRING(64) NOT NULL, — 例: ハッシュ化されたプレフィックス + UUID
TransactionTime TIMESTAMP NOT NULL,
Payload STRING(MAX),
) PRIMARY KEY (ShardedId);
キー空間全体にトラフィックを均等に散らしつつ、時系列の検索が必要な場合は、セカンダリインデックスやGenerated Columnを適切に活用するべきだ。
—
3. 読み取りの魔術：Stale Read（古い読み取り）でTPOをバイパスする
トランザクションの整合性を担保するため、TPOとTrueTimeは書き込み（Write）において重い同期処理を行っている。しかし、「最新のデータでなくてもよい」ユースケースにおいて、毎回この厳密なタイムスタンプ発行のコストを払うのはアーキテクチャの無駄遣いだ。
ここで真価を発揮するのが Stale Read（過去読み取り） である。
実務で使うべきStale Readのコードパターン（Go）
ダッシュボードの集計、レポーティング、あるいは厳密なリアルタイム性を求められない参照クエリでは、必ずStale Readを強制せよ。TPOへの問い合わせやロック待ちが発生しないため、爆発的なスループットと低レイテンシが手に入る。
package main
import (
“context”
“fmt”
“time”
“cloud.google.com/go/spanner”
)
// ReadUserDataStale は、TPOの同期をバイパスして爆速でデータを取得するサンプルコード
func ReadUserDataStale(ctx context.Context, client spanner.Client, userID string) error {
// 【チーフアーキテクトの知見】
// ExactStale Read を使い、例えば「10秒前」の正確なスナップショットを指定する。
// これにより、TPOのロック競合やコミット待ちから完全に解放される。
targetTime := time.Now().Add(-10 time.Second)
ro := client.ReadOnlyTransaction().WithTimestampBound(spanner.ExactStale(targetTime))
defer ro.Close()
stmt := spanner.Statement{
SQL: `SELECT UserName, Status FROM Users WHERE UserId = @userId`,
Params: map[string]interface{}{
“userId”: userID,
},
}
iter := ro.Query(ctx, stmt)
defer iter.Stop()
for {
row, err := iter.Next()
if err == iterator.Done {
break
}
if err != nil {
return err
}
var userName string
var status int64
if err := row.Columns(&userName, &status); err != nil {
return err
}
fmt.Printf(“User: %s, Status: %d (Stale Read from %v)\n”, userName, status, targetTime)
}
return nil
}
このアプローチを取ることで、ホットスポットに対する読み取り負荷を完全に分散し、トランザクションの競合エラー（`ABORTED`）の発生率を劇的に引き下げることができる。
—
4. チーフアーキテクトからの最終提言
Cloud SpannerのタイムスタンプオラクルとTrueTimeは、魔法の杖ではない。物理世界の限界（光速の限界やハードウェアのクロック同期のゆらぎ）と戦うための、極めて高度なエンジニアリングの結晶だ。
設計の現場において、以下の3点を常に頭に叩き込んでおいてほしい。
1. 書き込みのホットスポットを作るな
単調増加するキーを主キーの先頭にするな。TPOの調停能力を過信せず、アプリケーション層でキーを綺麗に分散させろ。
2. Commit Waitのコストを意識せよ
ミリ秒単位のレイテンシがシビアに問われるパスでは、トランザクションの粒度を最小限に絞れ。
3. 読込は可能な限り Stale Read を検討せよ
すべての読み取りに最強の外部整合性を適用する必要はない。ビジネス要件とトレードオフを慎重に見極め、TPOの負荷をオフロードしろ。
これらをクリアしたシステムだけが、Cloud Spannerの真のポテンシャル――「無限のスケールと強烈な堅牢性」をその手にする資格を持つ。
次のコードレビューでは、君たちの書いた美しく分散されたスキーマとクエリに出会えることを期待している。実装にかかれ。
コメント