【実務・中級編】ステイル読み取り (Stale Read) – Cloud Spanner

Cloud Spannerの隠し札：ステイル読み取り（Stale Read）を極め、レイテンシの限界を突破する

こんにちは。テックリードの私だ。
今日のコードレビュー、あるいはアーキテクチャ設計レビューで、こんなクエリを見たことはないだろうか？

「とにかく全部最新のデータを読ませるために、デフォルトのトランザクションで全件フェッチしています」

……待て。その設計、本当に必要か？
すべての読み取りに「真の最新（Strong Read）」を要求していませんか？あなたのシステム、無駄なレイテンシとコストを支払っていませんよ。

Cloud Spannerの本質は、世界規模の強整合性（Strong Consistency）にある。だが、「常に最新である必要がないデータ」に対してまで最強の同期プロトコルを強制することは、エンジンを常にベタ踏みして渋滞に突っ込むようなものだ。

今回は、Cloud Spannerのコアアーキテクチャの深層に踏み込み、スケーラビリティとレイテンシのジレンマを鮮やかに解決する「ステイル読み取り（Stale Read）」の極意を伝授しよう。

—

1. コアアーキテクチャ：なぜステイル読み取りは「速い」のか？

まず、Spannerが裏側でどう動いているかを思い出してほしい。
通常の読み取り（Strong Read）や書き込みトランザクションは、世界中に分散したPaxosグループ間でコンセンサスを取る必要がある。リーダーレプリカとのラウンドトリップ、ロックの獲得、そして真の現在時刻（TrueTime APIの不確実性ウィンドウの待機）が発生する。これが堅牢性の代償としてのレイテンシだ。

対して、ステイル読み取り（正確には「境界付きステイル読み取り / Bounded Stale Read」および「正確なステイル読み取り / Exact Stale Read」）はどうだろう。

ステイル読み取りは、過去の特定時点（Timestamp）におけるデータを読み取る。ここで何が起きるか？

1. リーダーへの通信不要: 過去のデータは、あなたのアプリケーションから物理的に最も近い「ローカルのリードレプリカ（Read-only Replica）」で完結できる。
2. ロックフリー: 書き込みとの競合が発生しないため、ロックの待機時間が文字通り「ゼロ」になる。
3. Paxosの素通り: コンセンサス形成を待つ必要がないため、ネットワークホップとオーバーヘッドが劇的に削減される。

つまり、ステイル読み取りとは「整合性の担保をあえて過去のタイムスタンプに委ねることで、物理的なレイテンシの壁を突破するチートコード」なのだ。

—

2. 実装パターン：コードレビューで合格点が出る書き方

では、実際にどう実装するのか。Go言語のクライアントライブラリを用いたコード例で見てみよう。
「ダッシュボードの集計画面」や「過去の履歴参照」といった、数秒の遅延が許容されるユースケースを想定している。

package main

import (
“context”
“fmt”
“time”

“cloud.google.com/go/spanner”
“google.golang.org/api/option”
)

// FetchDashboardMetricsWithStaleRead
// ステイル読み取りを用いて、レイテンシを最小化しながらメトリクスを取得する
func FetchDashboardMetricsWithStaleRead(ctx context.Context, client spanner.Client) error {
// 【重要】許容する古さ（Staleness）の定義
// ここでは「正確に10秒前のスナップショット」を指定する（Exact Stale Read）
// あるいは、BoundedStaleness(10time.Second) を使って「最大10秒以内の遅延で最も古いデータ」を選ぶことも可能。
t := time.Now().Add(-10 time.Second)
ro := client.ReadOnlyTransaction().WithTimestampBound(spanner.ExactStaleness(t))
defer ro.Close()

// クエリの実行（通常のトランザクションとインターフェースは完全に同一）
stmt := spanner.Statement{
SQL: `SELECT MetricName, MetricValue FROM SystemMetrics WHERE RecordedAt >= @StartTime`,
Params: map[string]interface{}{
“StartTime”: time.Now().Add(-1 time.Hour),
},
}

iter := ro.Query(ctx, stmt)
defer iter.Stop()

for {
row, err := iter.Next()
if err == iterator.Done {
break
}
if err != nil {
return err
}

var name string
var value float64
if err := row.Columns(&name, &value); err != nil {
return err
}
fmt.Printf(“Metric: %s, Value: %f (Stale Read)\n”, name, value)
}

return nil
}

レビュー時のチェックポイント

タイムスタンプの選び方: あまりに古すぎるデータ（例: ガベージコレクションの保持期間である1時間以上前）を指定するとエラーになる。通常は数秒〜数分程度のズレを許容する設計にする。
Bounded Stalenessの活用: `spanner.MaxStaleness(5 time.Second)` のように指定すると、Spannerは「指定した鮮度を満たせる最も新しいレプリカ」を自動選択してくれるため、無駄に古いデータを読むリスクを避けつつレイテンシを最適化できる。

—

3. 堅牢な設計パターン：どこにステイル読み取りを適用すべきか？

やみくもにステイル読み取りを使えばいいというものではない。設計レビューで「このクエリ、なんでStrong Readなの？」と突っ込まれないために、以下の適用基準（マトリクス）を頭に叩き込んでおいてほしい。

アーキテクチャ上のアンチパターン

「DBの負荷が高いから、とりあえず全部のクエリをステイル読みにしようぜ」——これは最悪の設計だ。
データ不整合によってユーザーが「さっき買ったはずのアイテムがない！」とパニックを起こすような箇所にステイル読み取りを適用してはならない。「ユーザーの体験に影響しない遅延の境界」をビジネスロジック単位で定義することが、シニアエンジニアの腕の見せ所だ。

—

4. パフォーマンス上の注意点と落とし穴

最後に、現場でよくあるトラブルと、その予防線を張っておこう。

1. ガベージコレクション（GC）の壁
Cloud Spannerは、デフォルトで過去1時間（最大設定による）のデータをガベージコレクションの対象外として保持している。つまり、「1時間以上前のステイル読み取り」を実行すると、`FAILED_PRECONDITION` エラーが発生する。過去のアーカイブデータを引く目的でステイル読み取りを乱用してはならない。長期的な履歴はBigQueryへのエクスポート等（Spanner Federated QueriesやCDC）を検討すべきだ。

2. レプリカの遅延（Replica Lag）の罠
リードレプリカが何らかの理由（ネットワーク障害や高負荷）でリーダーから遅延している場合、`ExactStaleness` で指定した時刻のデータがそのレプリカにまだ到達していないことがある。この場合、Spannerは自動的に最新のレプリカ（あるいはリーダー）へフォールバックしようとするが、状況によってはレイテンシが一時的に跳ね上がるかエラーになる。マルチリージョン構成では、レプリカの配置とリージョン間のレイテンシを考慮したStalenessの秒数設計が不可欠だ。

—

チーフアーキテクトからの総括

ステイル読み取りは、Cloud Spannerのポテンシャルを極限まで引き出すための「隠し札」だ。
すべての読み取りを強整合性でガチガチに固めるのは、設計をサボっている証拠に等しい。

「このデータは、何秒古くてもビジネス上成立するのか？」

この問いを常に突き詰め、コードの隅々にまで最適なトランザクション境界を引くこと。それこそが、大規模トラフィックを涼しい顔してさばききる、真にスケーラブルなシステムを作り上げる唯一の道だ。

次の設計レビューでは、君の口から「ここはBounded Stale Readで行きましょう」という提案が出ることを期待している。