【実務・中級編】スナップショット読み取り – Cloud Spanner

【Cloud Spanner極限知見】スナップショット読み取り：ロックフリーがもたらす究極のスケーラビリティと設計の罠

こんにちは。チーフアーキテクトの私だ。
今回は、Cloud Spannerのコア中のコア、「スナップショット読み取り（Snapshot Read）」について深く掘り下げよう。

世の中の多くのエンジニアは、Spannerを「リレーショナルデータベースの皮を被ったNoSQLであり、無限にスケールするもの」と漠然と捉えている。しかし、その裏側でなぜSpannerが読み取りと書き込みの競合を完全に排除し、グローバル規模での高スループットを実現できているのか、その根幹を理解している者は意外と少ない。

コードレビューや設計レビューの場で、「とりあえず最新データを読めばいいや」と安易に通常クエリを乱発し、システム全体のパフォーマンスをドブに捨てているコードを見かけるたび、私は頭を抱えたくなる。

今回は、スナップショット読み取りのメカニズムを解剖し、実務の現場でどう使い倒すべきか、その設計パターンと「踏み抜いてはならない地雷」をロジカルかつシャープに伝授しよう。

—

1. なぜスナップショット読み取りは「最強」なのか：内部アーキテクチャの真実

まず前提として、多くの一般的なRDB（PostgreSQLやMySQLなど）における「読み取り」を思い出してほしい。これらは通常、MVCC（多版同時実行制御）を採用しているとはいえ、トランザクション分離レベル（REPEATABLE READやSERIALIZABLEなど）やロック（Shared Lock）の管理、そしてUndoログのパージ問題に常に悩まされる。

一方、Cloud Spannerのスナップショット読み取りは、それらとは次元が違う。

TrueTimeとPaxosが織りなす「ロックフリー」の魔法

Spannerの根幹には、Googleが誇る分散同期の最高傑作TrueTime APIがある。TrueTimeは、絶対的な時刻ではなく「時刻の不確実性（誤差の幅、通常は数ミリ秒以内 $\pm \epsilon$）」を保証する。

スナップショット読み取りを実行する際、我々は「過去の特定の正確なタイムスタンプ（例: 2023-10-01T12:00:00.000000000Z）」を指定する。内部的な動きはこうだ：

1. ロックゼロの強み: スプリット（データシャード）を管理するPaxosリーダーに対して、共有ロックや排他ロックを一切要求しない。ロック待ちのキューイングが発生しないため、どれだけ高頻度の書き込み（Mutation）が裏で走っていようとも、読み取り性能が劣化することが理論上ゼロになる。
2. ストレージの多版保持: Spannerのストレージ層（Colossus）にあるファイルはイミュータブル（不変）であり、書き込みは常に新しいバージョンを追記する形でアペンドされる。指定されたタイムスタンプ時点における正確なデータを、ディスク上のファイルからダイレクトに（必要に応じてインデックス経由で）引き抜く。

つまり、スナップショット読み取りとは単なる「古いデータを読む機能」ではなく、「分散トランザクションの同期コストを完全にバイパスするためのチートコード」なのだ。

—

2. 実務での活用シーン：いつ、どのように使うべきか

設計レビューで私が開発チームによく推奨する、代表的なユースケースは以下の3つだ。

① 整合性の取れた「大規模バッチ処理・データエクスポート」

日次や月次の集計バッチ、あるいはBigQueryへのデータ同期（Dataflow等を用いたエクスポート）を行う際、通常のトランザクションで全件スキャンをかけたらどうなるか？他のオンライン書き込みトランザクションと競合し、レイテンシが跳ね上がり、最悪の場合はアボート（Aborted）の嵐に見舞われる。

ここでスナップショット読み取りの出番だ。バッチの開始時点のタイムスタンプを固定し、その時点ののスナップショットとしてデータを読み出せば、オンラインの書き込みを一切ブロックせず、安全かつ完全に矛盾のないスナップショットを手に入れられる。

② マイクロサービス間における「分散トランザクション（Sagaパターン等）の整合性確認」

別々のマイクロサービスが非同期にイベントを処理する際、「あのイベントが発生した時点の、ユーザーの状態はどうなっていたか？」を厳密に監査・検証したい場合がある。TrueTimeベースのタイムスタンプをイベントに付与し、受信側でそのタイムスタンプを指定してスナップショット読み取りを行えば、「時空を超えた正確な状態の再現」が担保される。

③ ユーザー向けの「過去データ参照・監査ログ」機能

「先週のあの時点での設定はどうなっていたか」といった、タイムトラベルクエリをリクエストする機能。Spannerなら追加の監査テーブルや履歴テーブルを自前で実装する必要すらない。

—

3. コード実装：正しいスナップショット読み取りの書き方

では、Java（Google Cloud Client Library）を用いた実務レベルの実装コードを見てみよう。単に古いデータを読むだけでなく、「正確なタイムスタンプの取得」と「バウンド指定」のベストプラクティスを示している。

import com.google.cloud.Timestamp;
import com.google.cloud.spanner.;

public class SpannerSnapshotReader {

private final SpannerClient spannerClient; // 適切な初期化済みのクライアント

public SpannerSnapshotReader(DatabaseClient dbClient) {
// 通常、読み取り専用トランザクションやスナップショット読み取りは DatabaseClient を通じて行う
}

指定した正確なタイムスタンプ（Exact Staleness）でデータを読み取る例

/
public void readDataAtSpecificTime(DatabaseClient dbClient, Timestamp targetTimestamp) {
// 【重要】ReadOnlyTransaction を正確なタイムスタンプで構築する
// 厳密には、これ自体がスナップショット読み取りのセマンティクスを持つ。
try (ReadOnlyTransaction transaction = dbClient.readOnlyTransaction(
TimestampBound.ofExactStaleness(targetTimestamp))) { // あるいは ofReadTimestamp(targetTimestamp)

// クエリの実行
String sql = “SELECT AccountId, Balance FROM Accounts WHERE Region = @region”;
Statement statement = Statement.newBuilder(sql)
.bind(“region”)
.to(“JP”)
.build();

try (ResultSet resultSet = transaction.executeQuery(statement)) {
while (resultSet.next()) {
String accountId = resultSet.getString(“AccountId”);
long balance = resultSet.getLong(“Balance”);

// ログや処理
System.out.printf(“Account: %s, Balance: %d (at %s)%n”,
accountId, balance, targetTimestamp);
}
}
}
}
}

チーフアーキテクトのコード解説：

`TimestampBound.ofExactStaleness` や `TimestampBound.ofReadTimestamp` を適切に使い分けること。過去の「何秒前（Staleness）」を指定するか、あるいは「絶対的なタイムスタンプ（ReadTimestamp）」を指定するかは、要件定義の段階で明確にしておく必要がある。

—

4. 厳戒：スナップショット読み取り設計における「3つの罠」

甘い言葉の裏には必ず代償がある。実務でこの機能を導入する際、以下の3点を誤ると、システムは簡単に崩壊する。

罠1: ガベージコレクション（GC）の制限時間を超えた過去を読むな

Cloud Spannerは、過去のデータを永遠に保持しているわけではない。ストレージコストとパフォーマンス維持のため、古いバージョンはバックグラウンドでガベージコレクション（GC）によってパージされる。

制限時間: デフォルトでは、Spannerが保持するデータのバージョンの有効期限は最大1時間（正確にはGC windowに依存、デフォルトは60分）である。
結果: 「昨日（24時間前）の時点のデータをスナップショット読み取りしたい」といったコードを書くと、`FAILED_PRECONDITION` エラー（Stale read request is too old）が返されてシステムがクラッシュする。数日前のデータを扱いたいなら、スナップショット読み取りではなく、別ストレージ（BigQueryやCloud Storage）へのエクスポート基盤を設計しなさい。

罠2: 不確実性（Uncertainty）の罠と `MaxStaleness` の誤用

「あまり厳密な時刻でなくてよいから、とにかく高速に読みたい」という理由で `MaxStaleness` を使う場合がある。しかし、許容する古さ（Staleness）の値を小さくしすぎると、TrueTimeの同期遅延（数ミリ秒）の影響を受け、かえって内部の待機処理が発生することがある。

設計指針: 厳密な一貫性が必要ないバッチやレポート系であれば、数秒〜数分（例: `30秒`など）の余裕を持たせたバウンドを指定するのが、Spannerの分散キャッシュを最も効率よくヒットさせる秘訣だ。

罠3: インデックス設計の欠落による「スキャン地獄」

ロックフリーであっても、「スキャンするデータ量」が減るわけではない。
スナップショット読み取りで特定の過去データを引く際、適切なセカンダリインデックス（あるいは複合主キーのプレフィックス）が設計されていないと、数千万〜数億行のフルテーブルスキャンが走る。ロックは取らないが、CPUとメモリ（ネットワーク帯域）を完全に食い潰し、ノードのレイテンシを悪化させる原因になる。

鉄則: 通常クエリと同様に、スナップショット読み取りを行うクエリに対しても必ず実行計画（Query Execution Plan）を検証し、インデックスが効いていることを確認してから本番投入しろ。

—

5. 結びの言葉：技術の本質を見極めよ

Cloud Spannerのスナップショット読み取りは、分散データベースの制約をエレガントにハックするための最強の武器だ。しかし、それは「魔法の杖」ではない。TrueTimeの物理的限界、GCウィンドウという時間的制約、そしてインデックス設計というリレーショナルデータベースの基礎原理の上に成り立っている。

あなたがテクニカルリードとして設計レビューに臨む時、ただ「動くコード」を書かせるな。

「その読み取りは、なぜ最新データである必要があるのか？」
「もし過去データで足りるなら、スナップショット読み取りのタイムスタンプはどう設計しているか？」
「GCウィンドウの制約を考慮しているか？」

この問いをチームに投げかけられるエンジニアこそが、真にCloud Spannerを支配し、スケーラブルで堅牢なシステムを構築できるアーキテクトだ。

妥協のない設計を期待する。