Cloud Spanner 読み取り専用トランザクションの極意：ロックフリーの牙城をどう使い倒すか
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいはアーキテクチャ設計レビューで、こんなコードを見かけなかったか？
— よくあるアンチパターン：ただの参照なのに無駄な排他制御やデフォルトトランザクションを叩いている
SELECT FROM Users WHERE user_id = ‘xxx’;
もし、君が「参照系だから適当にSELECTを投げればいいや」と考えているなら、Cloud Spannerの真のポテンシャルをドブに捨てていると言わざるを得ない。Spannerの真価は、グローバル規模の整合性と高スループットの両立にある。そして、そのスループットの大部分を支えているのが「読み取り専用トランザクション（Read-Only Transaction）」だ。
今回は、この読み取り専用トランザクションのコアアーキテクチャを解剖し、実務の現場で「絶対に踏み抜いてはいけない地雷」と「極限までパフォーマンスを引き出す設計パターン」を授けよう。
—
1. コアアーキテクチャ：なぜ読み取り専用トランザクションは「ロックフリー」なのか？
一般的なRDB（あるいは多くの分散SQLデータベース）では、データの整合性を担保するために、たとえ読み取りであっても共有ロック（Shared Lock）を取得したり、MVCC（多版同時実行制御）の裏で複雑なロックマネージャーを動かしたりする。これがボトルネックになり、高負荷時にスレッドが詰まる現象を君たちも何度も見てきたはずだ。
しかし、Cloud Spannerの読み取り専用トランザクションは一味違う。
TrueTime API と分散スナップショット
Spannerの心臓部には、原子時計とGPSレシーバによって世界中のデータセンターの時刻同期誤差を極小（数ミリ秒以内）に抑え込む TrueTime API が存在する。
読み取り専用トランザクションが開始された瞬間、Spannerは以下のように動作する：
1. タイムスタンプの決定: トランザクションに対し、過去または現在の特定の正確なタイムスタンプ（$T_{read}$）を割り当てる。
2. ロックレス・フェッチ: 書き込みトランザクション（Pessimistic Lockingや2PCを使用）との競合を一切気にせず、$T_{read}$ 時点におけるデータのマルチバージョン（MVCC）へ直接アクセスする。
3. 完全なアイソレーション: 他のトランザクションがどれだけ激しくデータを更新していようとも、読み取り専用トランザクションは影響を受けず、ブロックされることも、ブロックすることもない。
つまり、「競合が原理的に発生しないため、ロック待ちがゼロになる」。これが、高並行環境下でもレイテンシがフラットに保たれる理由だ。
—
2. 実務での実装：コードレビューの現場から
では、実際のアプリケーションコード（ここではGo言語のクライアントライブラリを想定する）で、どう実装すべきかを見ていこう。
❌ やってはいけない：暗黙的トランザクションの乱用
単発の `SingleRead` や、トランザクションコンテキストを明示しないクエリ発行は、実は内部で毎回トランザクションのオーバーヘッドが発生する可能性がある。特に複数の関連する読み取りを整合性を保って行いたい場合、これは悪手だ。
⭕ 正しい実装：明示的な読み取り専用トランザクション
複数のテーブルから「ある一時点の整合性を持ったスナップショット」としてデータを取得する場合は、必ず `ReadOnlyTransaction` を明示的に張るべきだ。
package main
import (
“context”
“fmt”
“log”
“cloud.google.com/go/spanner”
)
// FetchUserProfileAndOrders は、整合性の取れたスナップショットから
// ユーザー情報と注文履歴をロックフリーで取得する模範的な実装。
func FetchUserProfileAndOrders(ctx context.Context, client spanner.Client, userID string) error {
// ReadOnlyTransactionを開始
// ※ デフォルトでは Strong（現在時刻）の読み取りになる
txn := client.ReadOnlyTransaction()
defer txn.Close()
// 1. ユーザー情報の読み取り
userStmt := spanner.Statement{
SQL: `SELECT name, email FROM Users WHERE user_id = @userId`,
Params: map[string]interface{}{
“userId”: userID,
},
}
iter := txn.Query(ctx, userStmt)
defer iter.Stop()
// データ処理の省略…
// 2. 注文履歴の読み取り（ユーザー情報と「同一時点」のデータであることが保証される）
orderStmt := spanner.Statement{
SQL: `SELECT order_id, amount, created_at FROM Orders WHERE user_id = @userId ORDER BY created_at DESC`,
Params: map[string]interface{}{
“userId”: userID,
},
}
orderIter := txn.Query(ctx, orderStmt)
defer orderIter.Stop()
// ここで取得するデータは、ロックを一切取得せずに安全にスキャンされている。
fmt.Println(“Successfully fetched consistent snapshot data.”)
return nil
}
このコードの美しい点は、`Users` と `Orders` を別のクエリで取得していながら、トランザクション内で完全に同じスナップショット（論理的な一時点）が保証されている点にある。アプリ側で「途中でデータが書き換わったらどうしよう」と怯える必要は一切ない。
—
3. 堅牢な設計パターンと「バウンド読み取り（Bounded Stale）」の魔力
プロの設計者であれば、デフォルトの `Strong` 読み取りだけでなく、Stale（陳腐化）読み取りを使いこなす必要がある。
パターンA: リアルタイム性が不要な参照系への「Stale Read」適用
ダッシュボードの集計、アナリティクス、履歴参照など、「1秒や2秒前のデータでも全く問題ない」ユースケースは非常に多い。この場合、`TimestampBound` に過去を指定する、あるいは許容する古さ（Max Staleness）を指定する。
// 5秒以内の遅延を許容するバウンド読み取り
// これにより、Spannerは最も近いレプリカ（Read-Only Replica）のローカルキャッシュや
// ローカルのコミット済みデータから瞬時にデータを引き抜くことができる。
bound := spanner.MaxStaleness(5 time.Second)
ro := client.ReadOnlyTransaction().WithTimestampBound(bound)
アーキテクトからの助言:
これを適切に設定すると、リーダーレプリカ（Leader Replica）への負荷を劇的に削減でき、クロスリージョン環境であってもレイテンシをミリ秒単位で最小化できる。コストとパフォーマンスのバランスを取るための最強のカードだ。
—
4. パフォーマンス上の注意点（地雷原の歩き方）
最後に、レビューで私が必ずチェックする「やってはいけないアンチパターン」を警告しておく。
1. 読み取り専用トランザクション内での書き込みの企て
- 当たり前だが、`ReadOnlyTransaction` 内で `BufferWrite` を呼ぼうものなら、即座にランタイムエラー（またはコンパイルエラー）になる。データを変更したいなら、潔く `ReadWriteTransaction` を使え。
2. 長すぎるトランザクションの放置
- スナップショット分離のため、Spannerは過去のバージョンを保持し続ける必要がある。読み取り専用トランザクションを何分も開きっぱなしにすると、ガベージコレクション（GC）が走れなくなり、ストレージレイヤに深刻なプレッシャーを与え、最悪の場合パフォーマンスが劣化する。クエリは高速に実行し、トランザクションは速やかに閉じろ。
3. インデックスの設計ミス
- ロックフリーであっても、スキャン効率が悪ければ意味がない。フルテーブルスキャンを引き起こすクエリを読み取り専用トランザクションで大量に発行すれば、CPU資源が枯渇する。EXPLAINプランの確認はエンジニアの義務だ。
—
まとめ
Cloud Spannerの読み取り専用トランザクションは、単なる「速いSELECT」ではない。
「分散環境において、整合性を犠牲にすることなく、ロックの呪縛から完全に解放されたスケーラビリティを手に入れるための究極の武器」である。
君たちの次の設計レビューでは、ただ動くだけのコードではなく、こうしたSpannerのプリミティブを極限まで理解した美しいアーキテクチャが提案されることを期待している。
それでは、次のコードレビューで会おう。
コメント