TrueTimeの深淵：Cloud Spannerがいかにして「物理の限界」を克服したか
多くのエンジニアが「Spannerは凄い」と言う。だが、その凄さが「TrueTimeという魔法の時計があるから」というレベルで止まっているのなら、君はまだSpannerの足元にも及んでいない。
真のアーキテクトであれば、TrueTimeを単なる「時刻同期ツール」と捉えるのはやめるべきだ。これは、分散システムにおける「不確実性（Uncertainty）」を定量化し、物理法則をデータベースのトランザクションロジックへと昇華させた、計算機科学の最高傑作の一つである。
今回は、カタログスペックの向こう側にある、TrueTimeの真髄を剥き出しにする。
—
1. 物理的な不確実性と「ε（イプシロン）」の概念
分散システムにおいて、時刻を完全に同期させることは不可能だ。ネットワーク遅延、クロックドリフト、OSの割り込み。これら全てが「今、何時か？」という問いに誤差を生む。
従来の分散DBは、この誤差を無視するか、あるいは論理時計（Lamportタイムスタンプ等）で誤魔化してきた。しかし、Spannerは違った。「時刻には必ず誤差がある」という前提をシステム設計の第一級市民として受け入れたのだ。
TrueTimeは、時刻 $t$ を単一の値として返すのではない。以下の形式で返す。
$$ TT.now() \rightarrow [earliest, latest] $$
この区間 $[earliest, latest]$ の幅こそが、システムの不確実性 $\epsilon$ である。原子時計とGPS受信機をデータセンターの各ノードに直結させることで、Googleはこの $\epsilon$ を極限まで絞り込んでいる。だが、重要なのは「0にすること」ではない。「この範囲内に必ず真の現在時刻が存在する」という確証を得ることにある。
2. Commit Wait：因果律を物理層で制御する
Spannerのシリアライザビリティを支えるのは、この $\epsilon$ を利用した「Commit Wait」という戦略だ。
トランザクション $T_i$ が発生したとき、システムは以下の手順を踏む。
1. タイムスタンプの割り当て: $s_i = TT.now().latest$ を取得する。
2. Commit Wait: システムは、現在の時刻 $t$ が $s_i$ を確実に追い越すまで、つまり $t > s_i$ が保証されるまで、書き込み処理を意図的に待機させる。
なぜ待つのか？ それは、「未来のタイムスタンプを持つトランザクション」が過去に遡って発生しないことを物理的に保証するためだ。
// 概念的なコミット待機ロジック
void CommitTransaction(Transaction t) {
Timestamp s_i = TT.now().latest; // 現時点での最大誤差を見越した時刻
// ここで物理的な待機が発生する
// TT.now().earliest が s_i を超えるまで待つことで、
// どのノードから見ても「このトランザクションの後に発生した」ことが確定する
while (TT.now().earliest < s_i) {
// CPUを回すのではなく、Wait-freeな待機キューへ
sleep(epsilon);
}
// この地点で、s_i は過去の確定した時刻となる
ApplyWrites(t, s_i);
}
この「待機」は、一見するとパフォーマンスのボトルネックに見える。しかし、これこそが「分散ロックなしで外部整合性（External Consistency）を維持する」という、データベースエンジンにおける聖杯を実現する唯一の手段なのだ。
3. なぜ「同期」ではなく「不確実性の管理」なのか
多くのエンジニアは、NTP（Network Time Protocol）の延長でTrueTimeを考えてしまう。だが、NTPは「過去の通信」に依存する。パケットが遅延すれば時刻はズレる。
一方、TrueTimeは専用のハードウェア層でクロックの誤差を監視し続けている。GPSが受信不能になれば、原子時計が主導権を握り、それでも誤差が拡大しそうになれば、システムは自動的にスロットリング（あるいは停止）を選択する。
この「誤差が一定値を超えたら沈黙する」という挙動こそが、分散システムにおける最強の安全装置だ。整合性が破壊されるくらいなら、可用性を犠牲にしてでも止まる。この潔さこそが、Googleというエンジニアリング集団の矜持である。
4. アーキテクトへの提言：Spannerを使うということ
君たちがSpannerの上でアプリケーションを設計する際、忘れてはならないことがある。
- 読み取り整合性の代償: `Snapshot Read` を行う際、過去のタイムスタンプを指定すれば、TrueTimeの恩恵によりロックなしで読み取れる。これは最高効率だが、指定する時刻が現在に近いほど、システムは「その時刻が本当に過去であるか」を確認するために待ちが発生する可能性がある。
- 物理レイテンシとの対話: 物理的な距離は、TrueTimeの $\epsilon$ を増大させる。巨大なトランザクションをグローバルにまたがってコミットしようとすれば、必然的にCommit Waitの時間が長くなる。設計レベルで「どこでデータを保持し、どこでコミットするか」を局所化することは、今なおSpannerにおいてもエンジニアの責務だ。
最後に
TrueTimeは単なる時計ではない。「分散環境において、因果関係を定義するための物理定数」である。
もし君が、次世代の分散DBを設計しようと考えているなら、まずは「時刻を正しく合わせよう」とすることから卒業することだ。時刻は常にズレる。そのズレをいかにして「システムが許容可能な範囲（イプシロン）」に閉じ込め、それを論理的な整合性の担保へと昇華させるか。
そこにこそ、エンジニアリングの真髄がある。Spannerという巨人の肩に乗るということは、その極限の思考を追体験することに他ならない。
技術を愛する者たちよ、時刻という幻想を捨て、物理という現実と対峙せよ。そこにこそ、真の性能が眠っている。
コメント