【Cloud Spanner】マルチリージョン構成の真実：グローバルスケールと強整合性を両立するアーキテクチャの極意
こんにちは。チーフアーキテクトの私だ。
設計レビューやコードレビューで、こんな議論に遭遇したことはないだろうか？
- 「グローバル展開するから、とりあえずマルチリージョン構成にしよう」
- 「海外ユーザー向けにレイテンシを下げたいから、マルチリージョンでリードを分散させればいいよね？」
- 「マルチリージョンなら、リージョンが1つ吹っ飛んでも100%データは無傷で停止しないはずだ」
……待て。その設計、本当に物理法則とCloud Spannerの内部挙動を理解して書かれているか？
Cloud Spannerのマルチリージョン構成は、正しく使えば「世界最高峰の可用性と強整合性を両立する魔法のインフラ」だが、仕組みを履き違えて設計すると、「予期せぬレイテンシの悪化」と「法外なコスト」という強烈なしっぺ返しを受ける。
今回は、実務の現場でインシデントを踏み抜かないために、Spannerのマルチリージョン構成における「本質」と「堅牢な設計パターン」をロジカルかつシャープに伝授しよう。
—
1. Cloud Spanner マルチリージョン構成の物理的現実
まず大前提として、光速の壁は超えられない。東京（`asia-northeast1`）とアイオワ（`us-central1`）の間を光が往復するだけで、物理的なミニマム・レイテンシ（RTT）は100ミリ秒を超える。
Cloud Spannerは、この物理制約が存在する世界で「グローバルな分散トランザクション（強整合性）」を実現している。これを支えているのが、PaxosアルゴリズムとGoogleの専用ネットワークバックボーンだ。
構成の基本：コミットメントとレプリカの役割
マルチリージョンインスタンスをデプロイする際、我々は以下の2種類のレプリカを意識する必要がある。
1. リード・ライト・レプリカ (Read-Write Replicas)
- トランザクションのコミット（書き込み）に過半数（Quorum）の合意が必要。
- 書き込みレイテンシは、最も離れたレプリカ間の物理距離に支配される。
2. リード・オンリー・レプリカ (Read-Only Replicas)
- 書き込みの合意には参加せず、データのコピーを受け取るだけ。
- Stale Read（古いデータの許容読み取り）を利用することで、ローカルリージョンから爆速（数ミリ秒）で読み取りが可能。
3. ウォッチャー (Witness)
- データは持たないが、Paxosの過半数合意（Quorum）のためだけに投票権を持つノード。ストレージコストを抑えつつ可用性を上げるために使われる。
—
2. 実務で直面する「やってはいけない」アンチパターン
設計レビューで私が一刀両断する、よくあるアンチパターンを挙げておこう。
アンチパターン A: 「マルチリージョンならどこから書いても速いはず」という誤解
Spannerのマルチリージョン構成（例: `nam-eur-asia` や `asia1`）において、すべての書き込みは「リージョン横断のPaxosグループ」で行われる。
つまり、東京から書き込みを発行しても、メタデータや合意形成のために他リージョンとの通信が発生する。「書き込みレイテンシはシングルリージョンより確実に増加する」。これを理解せずに、高頻度なINSERT/UPDATEをグローバルから乱発する設計は即座にリジェクト対象だ。
アンチパターン B: グローバル全域で「強整合性（Linearizable Read）」を毎回引く
本当にすべての参照系クエリで「今この瞬間の最新データ」が必要か？
プロフィール画面の閲覧、商品カタログの表示、過去の注文履歴……これらは数秒〜数分の古さが許容されるケースがほとんどだ。
もし、これをすべてのリージョンから強整合性で読みに行かせているなら、Spannerの真価である「Stale Readによるスケール」をドブに捨てているようなものだ。
—
3. 堅牢な設計パターン：ユースケース別の最適解
では、実務ではどう設計すべきか。代表的な2つのパターンを伝授する。
パターン1：グローバルSaaS向け「低レイテンシ読み取り＋ローカルライート」構成
北米とアジアの両方にユーザーを持ち、それぞれの拠点で書き込みのローカリティを担保したい場合の設計だ。
- アーキテクチャ方針:
- データのマスター（Read-Write）は特定のリージョン（例: `us-central1`）に寄せつつ、アジア(`asia-northeast1`)と欧州(`europe-west1`)にRead-OnlyレプリカとWitnessを配置する。
- アジアのユーザーからの「重い参照系」は、Stale Readを使ってローカルのRead-Onlyレプリカからミリ秒オーダーで吸い出す。
— 【実装例】Stale Read（タイムスタンプ指定）を用いた超高速ローカル読み取り
— 10秒以内の古いデータを許容することで、ネットワークホップを最小化しローカルから爆速で引く
SELECT
FROM Users@{FORCE_TIME_STAMP=COMMIT_TIMESTAMP() – INTERVAL 10 SECOND}
WHERE user_id = ‘usr_998877’;
> Architect’s Note: `FORCE_TIME_STAMP` や `MAX_STALENESS` を適切に使い分けることで、グローバル規模のトラフィックであってもSpannerのCPU使用率を劇的に抑えつつ、ユーザー体験（レイテンシ）を最大化できる。
パターン2：金融・決済系向け「真のハイパースケールDR（災害復旧）」構成
リージョン障害（震災や大規模停電）が発生しても、数秒で別リージョンへフェイルオーバーし、データ損失ゼロ（RPO = 0）を死守する構成。
- アーキテクチャ方針:
- 3つ以上のリージョンにRead-Writeレプリカを分散配置する（例: `asia-northeast1`, `asia-northeast2`, `australia-southeast1`）。
- どこか1つのリージョンが完全に消失しても、残りのリージョンでPaxosの過半数が維持されるため、システムは無停止で稼働し続ける。
—
4. パフォーマンスとコストの限界突破（チーフアーキテクトの知見）
最後に、マルチリージョンを運用する上で避けて通れない「コスト」と「ホットスポット」の話をしておこう。
1. ネットワークエグレス（転送料金）の爆発に備えろ
マルチリージョン構成では、リージョン間レプリケーションのために膨大なデータがネットワークを流れる。
特に、巨大なBLOBデータや、頻繁に更新される不要なカラムをテーブルに含めていると、クラウドの月額利用料の請求書を見た経営陣が気絶することになる。
スキーマ設計の段階で、「本当にマルチリージョンで同期すべきテーブルか？」を精査し、必要に応じてアプリケーション側でデータを分割（シャコーリング）するか、Cloud Storage等へのオフロードを検討せよ。
2. モノトニックなキー（連番やタイムスタンプ）によるホットスポット
シングルリージョンでも同様だが、マルチリージョンではこれがさらに致命傷になる。
`AUTO_INCREMENT` のような連番や、現在時刻のプレフィックスを持つプライマリキーを書き込むと、特定の1つのレプリカ（スプリット）に書き込みが集中し、グローバル規模のネットワーク遅延と相まってスループットが全く出なくなる。
— 【アンチパターン】時系列データをそのままPKにする
CREATE TABLE AccessLogs (
LogTime TIMESTAMP, — 先頭にこれがあると特定の範囲に書き込みが集中する！
UserId INT64,
Action STRING(MAX)
) PRIMARY KEY(LogTime, UserId);
— 【改善策】ハッシュプレフィックス（分散キー）を導入する
CREATE TABLE AccessLogs (
ShardId INT64, — 0〜15くらいのハッシュ値を付与して書き込みを分散
LogTime TIMESTAMP,
UserId INT64,
Action STRING(MAX)
) PRIMARY KEY(ShardId, LogTime, UserId);
この「ハッシュプレフィックスによる分散」を施すだけで、マルチリージョン全体でのスループットは桁違いに跳ね上がる。これをコードレビューで指摘できないエンジニアは、Spannerを扱う資格がないと言っても過言ではない。
—
まとめ
Cloud Spannerのマルチリージョン構成は、単に「チェックボックスをポチッと入れるだけの機能」ではない。
物理法則、Paxosの合意形成、コスト構造、そしてアプリケーションのクエリパターン（Stale Readの活用）のすべてが噛み合ったときに初めて、その真価を発揮する。
次の設計レビューでは、ただ「マルチリージョンにします」と言ってくる開発者に対して、こう問い詰めてほしい。
- 「その書き込み、どのリージョン間のPaxosを跨いでいるか説明できるか？」
- 「その参照、本当に強整合性が必要か？Stale Readに落とせないのか？」
- 「プライマリキーの分散設計はどうなっている？」
この問いにロジカルに答えられるチームであれば、君たちのシステムはグローバル市場において絶対に揺るぎない基盤を手に入れることができるはずだ。健闘を祈る。
コメント