Spannerの読み取り専用レプリカ：TrueTimeがもたらす「鮮度と整合性」の極限最適化
こんにちは。テクニカルリードの私だ。
今日のコードレビューやアーキテクチャ設計レビューで、こんな質問を受けていないだろうか？
- 「読み取り専用レプリカを使えば読み取り性能はスケールするけど、古いデータを読まされるリスクはないのか？」
- 「リアルタイムな整合性を保ちながら、高スループットな参照系クエリを捌くにはどう設計すればいい？」
Cloud Spannerを「ただの無限にスケールするリレーショナルデータベース」だと思っているなら、今すぐその認識をアップデートしてほしい。Spannerの真髄は、分散システムにおける「絶対的な時間（TrueTime）」と「分散トランザクション」の美しき融合にある。
今回は、読み取り専用レプリカ（Read-Only Replica）がTrueTimeをどう活用し、「強整合性（Strong Consistency）」を維持しながら極限の読み取りパフォーマンスを発揮するのか、そのコアアーキテクチャと実務で使える設計パターンを叩き込む。
—
1. コアアーキテクチャ：なぜ読み取り専用レプリカで「強整合性」が保てるのか？
一般的な分散DB（例えばMySQLのレプリケーションや、一部のNoSQL）では、リーダーからフォロワーへのデータ同期は非同期（あるいは半同期）で行われる。そのため、フォロワー（読み取り専用ノード）を参照すると、「Stale（古い）データ」を掴むリスクが常につきまとう。
しかし、Spannerの読み取り専用レプリカは違う。
これを理解するには、Spannerの二つの武器——PaxosグループとTrueTime APIの連携を覗く必要がある。
TrueTimeが保証する「絶対時間」の幅（Uncertainty）
Spannerの全ノードには、GPS受信機と原子時計が物理的に搭載されている。これにより、時刻は絶対的な誤差の範囲（$\epsilon$、通常は1〜7ミリ秒程度）として表現される。
TrueTimeは「今という時刻の範囲 `[t.earliest, t.latest]`」を返す。システムはこの誤差の幅が収まるまで安全に待機（Commit Wait）することで、グローバルな因果関係の順序を完全に保証する。
読み取り専用レプリカにおけるスナップショット読み取りのメカニズム
読み取り専用レプリカには、Paxosリーダーが存在しない。代わりに、リーダーを持つスプリット（データシャード）のデータを非同期で持続的にキャプチャしつつ、特定のタイムスタンプ（過去の正確な時間 $T$）を指定したスナップショット読み取りを実行する。
ここでマジックが起きる。
クライアントが「強整合性読み取り（Strong Read）」を要求すると、Spannerは次のように動作する。
1. タイムスタンプの決定: リーダー側で直近にコミットされたトランザクションの最大タイムスタンプ（または現在時刻 $T_{now}$）を基準とする。
2. レプリカの同期確認: 読み取り専用レプリカは、自分が保持しているデータが指定されたタイムスタンプ $T$ までに適用されているかを確認する。
3. ロックフリーな実行: もしデータが追いついていれば、ロックを獲得することなく、その瞬間のデータをミリ秒単位のオーバーヘッドなしで高速にスキャンする。
つまり、「過去の特定の正しい瞬間 $T$ をスパッと切り取って読む」ことで、リーダーへの負荷をゼロにしながら、書き込みと矛盾しない最新（あるいは指定時点）のデータを完全に安全に読み出せているのだ。
—
2. 実務で直面する罠：デフォルト設定と「Stale Read」の使い分け
アーキテクチャの美しさを理解したところで、実務での設計に踏み込もう。
Spannerのクライアントライブラリで読み取りを行う際、何も指定しないとデフォルトで「強整合性読み取り（Strong Read）」が選択される。これが何を意味するか、コードを見てみよう。
アンチパターン：全クエリに Strong Read を強制する愚
// Java (Cloud Spanner Client API)
DatabaseClient dbClient = client.getDatabaseClient();
// デフォルトは Strong Read。すべての参照クエリでリーダーやレプリカの同期待ちが発生しうる
try (ResultSet resultSet = dbClient.singleUse().executeQuery(
Statement.of(“SELECT FROM Accounts WHERE AccountId = 1”)) {
while (resultSet.next()) {
// 処理
}
}
ダッシュボードの集計、アナリティクス、マイページの新着通知など、「1秒前のデータでも全く問題ない」ユースケースでこれをやると、読み取り専用レプリカの真価（高スループット＆低レイテンシ）をドブに捨てることになる。
模範解答：許容可能な古さを指定する「Stale Read（許容陳腐化読み取り）」
もし、ミリ秒単位のリアルタイム性が不要なバッチ処理やレポーティング、あるいは「ユーザープロフィールの表示」程度であれば、以下のようにStale Readを明示すべきだ。
// 5秒以内の遅延を許容するStale Readの例
TimestampBound bound = TimestampBound.ofMaxStale(Duration.ofSeconds(5));
try (ResultSet resultSet = dbClient.singleUse(bound).executeQuery(
Statement.of(“SELECT FROM Products WHERE Category = ‘Electronics'”)) {
while (resultSet.next()) {
// ロック競合なし、極限まで最適化されたレプリカからの超高速読み取り
}
}
これにより、クエリはスループットの限界を引き上げられ、CPUコストも劇的に削減される。コスト削減とパフォーマンス向上の両立、これこそシニアエンジニアの仕事だ。
—
3. 堅牢な設計パターン：CQRSとマルチリージョン戦略
ここで、大規模プロダクトを支えるための具体的な設計パターンを2つ伝授する。
パターンA: 厳格なCQRS（Command Query Responsibility Segregation）の構築
書き込み（Mutation/DML）と読み取り（Query）の経路を物理的・論理的に分離する。
- 書き込み系 (Command): マルチリージョン構成のリーダーノードに対して実行。トランザクションの直列化可能性（Serializable）を担保。
- 読み取り系 (Query): アプリケーション層で `TimestampBound` を使い分け。
- 決済や在庫引当などのクリティカルパス $\rightarrow$ `Strong Read`
- ダッシュボード、検索、レコメンド $\rightarrow$ `Max Stale (例: 1秒〜10秒)`
パターンB: グローバル分散環境におけるローカル・リージョン読み取りの極意
マルチリージョンのCloud Spanner（例: `nam-eur-asia1` などのコンフィグ）では、各リージョンに読み取り専用レプリカが配置される。
ここで注意すべきは、「ユーザーから一番近いリージョンの読み取り専用レプリカを強制的に叩く」設計だ。
// 特定のリージョン（例: us-east4）の読み取り専用レプリカを指定してスナップショットを読む
TimestampBound bound = TimestampBound.ofExactStale(Timestamp.now().minus(Duration.ofSeconds(2)));
// リージョン指定を含めたオプション設定（クライアント設定に依存）
// ※実務ではルートプールやルーティングポリシーと組み合わせてレイテンシを極限まで削る
物理的な光速の壁（レイテンシ）をTrueTimeの仕組みの上で華麗にバイパスし、ユーザーの足元（ローショナルレプリカ）から瞬時にデータを引き抜く。これが真のグローバルスケールアーキテクチャだ。
—
4. パフォーマンス上の注意点（Pitfalls）
最後に、レビューで必ず指摘すべき「やってはいけないアンチパターン」を挙げておく。
1. 「今この瞬間の正確なデータ」を `Exact Stale` で無理やり読もうとするな
`TimestampBound.ofExactStale()` に未来のタイムスタンプや、レプリカがまだ追いついていない極端に現在に近い時間を指定すると、レプリカ側でデータが追いつくまで待機（Stall）が発生し、かえってレイテンシが跳ね上がる。陳腐化時間を指定するなら、現実的な余裕（最低でも数秒）を持たせろ。
2. ホットスポットに対する過信
読み取り専用レプリカは負荷分散に極めて有効だが、「単一の行（Row）」にトラフィックが数千QPS以上集中するようなホットスポット（例: セールの特設ページの在庫カウンター）が存在する場合、レプリカであってもストレージ層のCPUが枯渇する。シャードキーの設計（プレフィックス付与など）の基本を忘れてはならない。
—
結びにかえて
Cloud Spannerの読み取り専用レプリカとTrueTimeの組み合わせは、分散データベースの歴史における最高傑作の一つだ。
「強整合性を維持しながら、レプリカでスケールする」という一見矛盾した要求を、物理法則（原子時計）と巧妙なスナップショットアルゴリズムでエレガントに解決している。
君たちが次に書く設計書やコードレビューでは、ただ「動く」だけでなく、この背後にあるメカニズムを理解した上で、適切な `TimestampBound` が選択されていることを期待する。
妥協のない、美しいアーキテクチャを作ろう。
コメント