Cloud SpannerのStaleness制御：分散トランザクションのコストを「秒」で買う技術
Cloud Spannerを単なる「SQLが叩けるマネージドDB」だと思っているなら、今すぐその認識を捨てたほうがいい。これは、真の意味で「物理法則」をハックした、世界で最も洗練された分散システムの一つだ。
多くのエンジニアが「読み取りの整合性」を気にするとき、脳内にあるのはRDBMSの隔離レベル（Isolation Level）だろう。しかし、SpannerにおいてStaleness（古さ）を制御することは、単なる読み取り設定ではない。これはTrueTimeという「物理時刻の不確実性」に対するコストの最適化そのものだ。
今回は、`Exact Staleness`と`Max Staleness`が、内部アーキテクチャのどこに突き刺さるのか、その極限のメカニズムを紐解く。
—
1. なぜ「Staleness」が重要なのか：TrueTimeの不確実性とスループット
Spannerの読み取りには、デフォルトで`Strong Read`が適用される。これは読み取り時点で最新のコミット済みデータを保証するが、内部ではTrueTimeの不確実性（$\epsilon$）を待機する時間が含まれる。
ノード間での時刻同期が完全でない以上、システムは「現在時刻 $t$」において、どこまでが確定した過去かを判定するために、時刻のズレを考慮した待機時間が必要になる。このオーバーヘッドを回避し、かつ分散トランザクションの競合を排除する唯一の手段が「Staleness」の導入だ。
内部構造への影響
- Strong Read: Read-Write トランザクションと同期し、Snapshotの準備に同期的なラウンドトリップや同期待機が発生する可能性がある。
- Stale Read: 既にコミットが完了し、Replicaが保持する特定時点のSnapshotを直接参照する。これには、Paxosグループのリーダーへの問い合わせが不要になるケースが多く、「読み取りの局所性（Locality）」を最大限に活かせる。
—
2. Exact Staleness：過去の「確定した瞬間」を撃ち抜く
`Exact Staleness`は、指定した時間（例：15秒前）のデータをピンポイントで読み取る。これは、レプリケーションラグが許容される分析クエリや、バックアップ・ETL処理において最強のツールだ。
— 15秒前のスナップショットを指定
— このクエリはPaxosリーダーへの通信をバイパスし、
— ローカルレプリカのメモリ/ディスク上の特定バージョンを直接参照できる
SELECT FROM Users@{FORCE_STALENESS=T15s} WHERE status = ‘ACTIVE’;
チーフアーキテクトの視点：メモリ最適化の極致
ここでの「極限」は、`Version GC`の挙動を理解することにある。SpannerはデータをMVCCで保持しているが、古いバージョンは適宜ガベージコレクションされる。
もし`Exact Staleness`で指定した時刻が、`_version_retention_period`（デフォルト1時間）を超えていれば、クエリは即座に失敗する。この設定を使いこなす者は、「システムがいかにメモリを解放し、古いバージョンを追い出しているか」というGCの呼吸を理解している。
—
3. Max Staleness：不確実性とパフォーマンスのトレードオフ
`Max Staleness`は、「この時間内であれば、最新データでなくても構わない」という緩やかな制約だ。これは、低レイテンシを優先したい分散コンポーネントにおいて極めて強力に機能する。
— 最大10秒以内の古いデータで良い場合
— リーダーがビジーでも、最新のレプリカから読み取れる
SELECT FROM Inventory@{FORCE_MAX_STALENESS=T10s} WHERE item_id = ‘A1’;
内部メカニズムの深淵
`Max Staleness`を指定すると、Spannerは「最新のコミットタイムスタンプ」と「各レプリカの適用タイムスタンプ」を比較する。
もしレプリカのラグが指定時間内であれば、わざわざネットワークを越えて最新のリーダーに問い合わせに行かず、手元のレプリカで解決する。これにより、クロスリージョン環境における広域ネットワークのレイテンシを完全に遮断できる。
—
4. アーキテクトが語る「Staleness戦略」の鉄則
私が設計レビューで必ず確認するのは、「なぜその読み取りに最新性が必要なのか？」という問いだ。
1. ReadOnlyトランザクションのデフォルト: 多くのケースで、`Strong Read`は過剰だ。ダッシュボードやレポート用途であれば、1〜5秒の`Max Staleness`を許容するだけで、レスポンスタイムは劇的に改善し、リーダーノードのCPU負荷は目に見えて下がる。
2. スループットとコストの相関: `Strong Read`は、常にPaxosリーダーへの「生存確認」を伴う。これはSpannerにおいて最も高価な操作の一つだ。Stalenessを意図的に活用することは、インフラコストを最適化するための、最も高レベルなチューニングである。
3. 副作用の理解: Stalenessを許容するということは、「誰かの死（更新）を少し遅れて知る」ことである。整合性（Consistency）と可用性・レイテンシ（Availability/Latency）のトレードオフを、アプリケーションコード側で明示的に定義する。これこそが、分散システムエンジニアの醍醐味だ。
—
結びに：Spannerを「支配」するために
Cloud Spannerを「ただのデータベース」として使うか、それとも「分散合意アルゴリズムを自由に操る武器」として使うか。その分水嶺は、このStaleness設定の理解にある。
`Exact Staleness`で過去をスライスし、`Max Staleness`で現在をサンプリングする。この二つの刃を適切に振るうことができれば、大規模トラフィック下でもシステムの挙動を完全に制御下に置くことが可能だ。
データベースは、決してブラックボックスではない。我々エンジニアが仕様の深淵に潜り込み、その挙動を完全に掌握したとき、初めて本当の「高可用性」がその姿を現す。
次は、Paxosグループのリージョン配置と、このStalenessの関係性について深掘りすることにしよう。現場からは以上だ。
コメント