Spannerの「過去」を読み解く：Stale Readがもたらすスケーラビリティの真髄
多くのエンジニアが「Spannerは強い整合性（Strong Consistency）を提供するデータベースである」という枕詞に安心し、その恩恵のみを享受している。しかし、真のアーキテクトであれば、その「強さ」の背後に隠されたコスト——つまり、Paxos合意形成とTrueTimeによる同期オーバーヘッド——を理解しなければならない。
今回は、Spannerのパフォーマンスの限界を突破するための鍵、「Stale Read（古いデータの読み取り）」について、その内部メカニズムを深掘りする。
—
1. 強い整合性のコスト：なぜ「現在」を読み取るのは重いのか
Spannerのトランザクションは、外部整合性（External Consistency）を保証するために、TrueTime APIを利用してグローバルなコミットタイムスタンプを割り当てる。
最新のデータを読み取る際、Spannerは単にレコードを取得するだけではない。読み取り対象のレプリカが、リーダーに対して「現在の状態が最新であるか」を確認（または同期）する必要がある。これは、地理的に分散した環境においてネットワークの往復遅延（RTT）を強いることを意味する。
「今、何が起きているか」を知ることは、物理的な光速の制約との戦いなのだ。
—
2. Stale Readの内部メカニズム：マルチバージョン・コンカレンシー・コントロール (MVCC)
Stale Readの本質は、SpannerのMVCC（多版同時実行制御）の実装そのものにある。
Spannerは、すべてのデータをタイムスタンプ付きで保持している。データが更新されるたびに古いバージョンが即座に消去されるわけではなく、設定された保持期間（デフォルトでは1時間）まで、過去のバージョンがSSTable上に残る。
`exact_staleness` を指定したクエリを発行すると、SpannerのリーダーはPaxosの合意形成を待機することなく、指定されたタイムスタンプ時点でのデータをローカルから直接読み取る。
- メリット: リーダーに対する同期通信が不要（ローカル読み取り）。
- 技術的帰結: 読み取り専用のトラフィックをリードレプリカに完全にオフロードでき、書き込みパスのスループットを一切阻害しない。
—
3. アーキテクトが知るべき実装上の最適化戦略
単に「古くてもいいから読み取る」というコードを書くだけでは不十分だ。システム設計において、以下の極限知見を適用せよ。
読み取り専用トランザクションの最適化
Stale Readを活用する際は、`ReadOnlyTransaction` を明示的に用いること。
// 概念的な実装イメージ: 15秒前のスナップショット読み取り
// スループットが極限に達した際、クエリを読み取り専用レプリカへ誘導する
spanner::TransactionOptions options = spanner::TransactionOptions::ReadOnly();
options.set_exact_staleness(std::chrono::seconds(15));
auto tx = client.ReadOnlyTransaction(options);
// このクエリはPaxosグループのリーダーを叩かず、最も近いレプリカで完結する
auto rows = tx.ExecuteQuery(spanner::SqlStatement(“SELECT FROM LargeTable”));
なぜ15秒なのか？
TrueTimeの不確実性（Uncertainty Window）は通常数ミリ秒だが、ネットワーク遅延やレプリカの同期ラグを考慮すると、短すぎる設定は無意味な同期待ちを誘発する。15秒程度のstalenessを許容することで、レプリカがリーダーの最新状態に追いつくための十分な猶予を与え、結果として読み取りのレイテンシを極限まで平滑化できる。
—
4. 限界を突破する運用上の注意点：ガベージコレクションとパフォーマンス
Stale Readを多用する場合、データベースの「ガベージコレクション（GC）設定」が運命を分ける。
- `version_retention_period` の設定:
デフォルトの1時間は、障害対応には十分だが、分析クエリを多用するアーキテクチャでは過小評価されることがある。古いデータを読み取る頻度が高いシステムでは、この期間を延長することで、より古い過去を覗き込むことが可能になる。ただし、SSTableの肥大化によるディスクI/Oへの負荷を考慮する必要がある。
- コールドデータの読み取り:
もし、あなたが1時間以上前のデータを頻繁に読み取る必要があるなら、それはSpannerのStale Readの領域を超えている。それはBigQueryの領域だ。SpannerからDataflowやGCSへエクスポートし、分析基盤へ逃がすのが「正しい」アーキテクチャである。
—
結びに：エンジニアの美学
SpannerのStale Readは、単なる機能ではない。「強い整合性」という幻想から解放された、スケーラビリティという名の現実である。
「すべてを最新にする必要がある」という思い込みは、システム設計における最もコストの高いバイアスだ。アーキテクトである君たちは、ビジネス要件を冷静に分析し、どこで「過去」を受け入れ、どこで「現在」を突き詰めるべきかを定義しなければならない。
Spannerのエンジンは、君たちがそれを使いこなすのを待っている。次は、Paxosグループのトポロジーを考慮した物理配置の最適化について話そうか。
極限を目指せ。それが我々の職務だ。
コメント