TrueTimeの呪縛を解け：Cloud Spannerのコアアーキテクチャと分散トランザクションの極意
こんにちは。テックリードの私だ。
君たちが設計しているそのシステム、本当にグローバル規模のトラフィックに耐えられるか？「とりあえずRDBを立てて、レプリケーション遅延に泣く」という泥臭いアーキテクチャから、そろそろ卒業する時期だ。
Cloud Spannerをただの「無限にスケールするMySQLやPostgreSQL」だと思って使っているなら、今すぐその認識を改めろ。Spannerの真髄は、「物理的に分散されたノード間で、ロックなしで外部整合性（External Consistency / Linearizability）を保証する」という、分布式データベースの聖杯を成し遂げた点にある。
そして、その奇跡の裏側で絶対的な支配者として君臨しているのが、今回解説する TrueTime API だ。
—
1. なぜ「時刻」が分散システムの最大のボトルネックなのか？
分散システムにおける最大の悪夢は何か？ それは「各ノードの時計がズレていること」だ。
地球上の物理的な距離を考えてみてほしい。東京とオレゴンのデータセンター間ですら、光速の制約がある。もし、あるトランザクションの順序を「タイムスタンプの大小」で決定しようとしたとき、各サーバーのローカル時計が数ミリ秒でもズレていたらどうなるか？
- ノードA（東京）の時計が実際より5ms進んでいる。
- ノードB（オレゴン）で起きたイベントの方が物理的には先だが、ノードAのタイムスタンプの方が未来を指してしまう。
- 結果、因果関係が逆転し、データが破壊される。
従来のデータベースは、これを解決するために「単一のマスター（リーダー）」に書き込みを集中させたり、重厚長大でスケーラビリティを殺す二段階ロック（2PL）やPaxos/Raftの直列化に頼ってきた。
しかし、Spannerは違う。「絶対的な現在時刻」を諦め、代わりに「時刻の不確実性（Uncertainty）」をシステム全体で数学的にハンドリングするという天才的なアプローチをとった。それがTrueTimeだ。
—
2. TrueTime APIの正体：絶対時刻ではなく「時間幅（Interval）」を返す
TrueTime APIが提供するのは、`2023-10-25 10:00:00.000000` のような単一の時刻ではない。
返すのは以下の関数だ。
$$\text{TrueTime.now}() \rightarrow [t_{earliest}, t_{latest}]$$
つまり、「現在の絶対時刻は、確実にあらゆる誤差を含めてこの$t_{earliest}$から$t_{latest}$の間に存在する」という幅（誤差：$\epsilon$）を返す。
$\epsilon$（イプシロン）の正体
この誤差 $\epsilon$ は、データセンターに設置された原子時計（Atomic Clock）とGPS受信機によって極限まで小さく抑えられている。
- GPSは電波の遮断やスプーフ攻撃のリスクがある。
- 原子時計は長期間で見るとわずかにドリフト（ズレ）が生じる。
Googleはこの2つを冗長配置し、相互に補正し合うことで、通常のデータセンター間であっても $\epsilon$ を通常 1ms〜7ms程度 に収めている。つまり、Spannerの世界では「今が何時か」はピンポイントでは分からないが、「最大でも数ミリ秒のズレの範囲内にある」ことがハードウェアレベルで保証されるのだ。
—
3. 外部整合性を実現する「Commit Wait」のメカニズム
このTrueTimeの不確実性を利用して、Spannerはどうやってトランザクションの順序をグローバルに調停しているのか？
ここが設計レビューで最も突っ込むべきポイントだ。
Spannerで書き込み（Commit）が発生すると、以下のプロセスが走る。
1. タイムスタンプの取得: リーダー・レプリカがトランザクションのコミットメント時刻 $s = t_{latest}(now())$ を割り当てる。
2. コミット・ウェイト（Commit Wait）: ここが肝心だ。Spannerは、「割り当てられたタイムスタンプ $s$ が、現実世界の絶対時刻において確実に過去のものになった（つまり、現在の真の時刻が $s$ を過ぎた）」と確実に見なせるまで、トランザクションをわざと待機（ブロック）させる。
待機する時間は、まさに不確実性の幅である $2\epsilon$ だ。
— 概念的なタイムライン
[TrueTime.now()取得]
|
v
[s = t_latest]
|<-- 2ε の待ち時間 (Commit Wait) -->|
v
[現実世界の時刻が s を超過]
==> ここで初めてクライアントに応答を返す
なぜ待つのか？
もしこの待ち時間を入れずに即座に応答を返すと、別のデータセンターで「物理的には後だが、ローカル時計のズレでより早いタイムスタンプを持ったトランザクション」が生まれ、因果律が崩壊する。
「 $2\epsilon$ 待つことで、トランザクション $T_1$ が $T_2$ よりも物理的に前にコミットされたのであれば、 $T_1$ のタイムスタンプは必ず $T_2$ のそれより小さくなる」ことを数学的に担保しているのだ。
これが、Spannerにおける「外部整合性（External Consistency）」の正体である。
—
4. 実務設計における注意点：コードレビューの視点から
このTrueTimeとCommit Waitのアーキテクチャを踏まえて、我々アプリケーションエンジニアは実務でどう振る舞うべきか。設計レビューで指摘すべきポイントを伝授する。
① 「高頻度のホットスポット更新」はレイテンシの致命傷になる
TrueTimeのコミット・ウェイト（数ミリ秒の待ち）が存在するということは、Spannerは「物理的なレイテンシの底値」がハードコードされているシステムだということだ。
単一の行や連続するキーに対して、秒間数万件の激しい排他ロックを伴う書き込み（カウンターのインクリメントなど）を行う設計にすると、Commit WaitとPaxosのラウンドトリップが複合し、スループットが劇的に落ちる。
- 対策: 単一キーへの高頻度書込を避け、シャーディング（ハッシュ化キーの利用）を徹底せよ。
// 悪い例：単一のカウンター行を毎秒何千回も更新する
// UPDATE Metrics SET count = count + 1 WHERE id = ‘global_counter’;
// 良い例：シャードに分散させて書き込み、読み込み時に集約する
// UPDATE Metrics SET count = count + 1 WHERE id = ‘global_counter_shard_3’;
② 読み取り専用トランザクション（ReadOnly Transaction）の美学
Spannerの真骨頂は、「過去の任意のタイムスタンプを指定した読み取り（Stale Read）」や、「ロックなしの読み取り専用トランザクション」が極めて高速に動作する点にある。
TrueTimeがあるおかげで、「過去のこの瞬間におけるスナップショット」を、ロックを獲得することなく安全に取得できる。
もし君のシステムに「重い集計クエリや、レプリカ遅延を許容できるダッシュボード用の読み込み」があるなら、必ず `ExactStale` や `MaxStaleness` を指定した読み取り専用トランザクションを使え。書き込みトランザクションのパフォーマンスを一切阻害しない。
// Java (Cloud Spanner Client) の例：ロックなしの過去読み取り
TimestampBound bound = TimestampBound.ofExactStaleness(15, TimeUnit.SECONDS);
try (ResultSet resultSet = dbClient.singleUse(bound)
.executeQuery(Statement.of(“SELECT FROM Accounts”))) {
// 15秒前のスナップショットをロックフリーで安全に読み取る
}
—
5. チーフアーキテクトからの総括
Cloud SpannerのTrueTime APIは、物理世界（原子時計・GPS）と論理世界（分散トランザクション）を結合する、人類の分布式エンジニアリングにおける最高傑作の一つだ。
「なぜSpannerは遅延が数ミリ秒下回らないのか？」
その問いに対する答えが、この $\epsilon$ と Commit Wait にある。
このハードウェアとソフトウェアの協調による仕組みを理解していれば、「なぜシャード設計が必要なのか」「なぜ安易なカウンター更新がパフォーマンスを殺すのか」が、感覚ではなく物理法則として腹に落ちるはずだ。
データベースをただの箱として扱うな。背後にある物理的・数学的限界を理解し、その上で美しくスケールするシステムを設計し抜け。君たちの健闘を祈る。
コメント