Cloud Spannerのインスタンス構成：その選択は「運命」を分かつ
アーキテクトとして多くの設計レビューに立ち会ってきたが、Cloud Spannerを導入する際に最も甘く見られがちなのがこの「インスタンス構成」の選択だ。
「とりあえずマルチリージョンにしておけば安心だろう」という判断は、多くの場合、無駄なコストと不要なレイテンシの増大を招く。逆に「単一リージョンで十分」と判断した結果、災害時にサービスが沈黙するリスクを負うケースも見てきた。
Spannerのインスタンス構成は、単なるインフラ設定ではない。ビジネスのSLAと、ユーザー体験の境界線を定義する「戦略的な決断」だ。 今日は、現場のエンジニアが立ち返るべき、インスタンス構成の深淵を紐解いていく。
—
1. インスタンス構成の「本質」を見極める
Spannerの可用性とレイテンシは、物理的な距離とPaxosグループの合意形成（Quorum）によって支配される。
単一リージョン（Single-region）の真実
単一リージョン構成は、そのリージョン内の複数のゾーンにレプリカを配置する。
- 強み: 圧倒的な低レイテンシ（シングルディジットミリ秒）。
- 用途: ミッションクリティカルだが、同一リージョン内での可用性が確保できれば十分なアプリケーション。
- 注意点: リージョン障害には脆弱。リージョン全体が吹き飛べば、書き込みは停止する。
マルチリージョン（Multi-region）の「代償」
マルチリージョンは、地理的に分散したリージョン間でデータを同期する。
- 強み: リージョン障害に対する堅牢性。99.999%のSLA。
- 用途: グローバル展開するサービスや、絶対にダウンが許されない金融インフラ。
- 注意点: 書き込みレイテンシの増大。Paxosの合意形成に「地球の裏側」との通信が発生するため、ネットワーク往復時間（RTT）が物理的な限界となる。
—
2. 現場で問われる「書き込みレイテンシ」との対話
多くのエンジニアが陥る罠がある。「読み取り」のレイテンシはマルチリージョンでも`Stale Read`（読み取り専用レプリカへのクエリ）を活用することで最適化できる。しかし、「書き込み」のレイテンシは、リージョン構成によって物理的に決定される。
— 読み取りにおいて、Stale Readを活用することでマルチリージョン間の
— 物理的な距離によるレイテンシを回避する手法
— 構成設定: 過去15秒以内のデータを読み取る（書き込み待ちを発生させない）
SELECT FROM Users@{FORCE_STALENESS=t15}
WHERE user_id = ‘xxx’;
もし、あなたのアプリケーションが「高頻度な書き込み」を前提としているなら、マルチリージョン構成を選択する前に、その「書き込みの距離」がビジネス要件を満たすか徹底的にシミュレーションすべきだ。
—
3. 堅牢な設計パターン：アーキテクトからの提言
① パターンA：ハイブリッド戦略
「ユーザーデータは低レイテンシが必要だが、管理データは堅牢性が優先」という場合、インスタンスを分けろ。全てを一つの巨大なSpannerインスタンスに詰め込む必要はない。
② パターンB：読み取り重視のグローバル配置
読み取りがメインのサービスであれば、マルチリージョンは最強の武器になる。
- 設計の鍵: `read-only replica`をユーザーに近いリージョンに配置し、`leader`は書き込みの多いリージョンに置く。これだけで、書き込み負荷を抑えつつ、世界各地で高速な読み取りを実現できる。
—
4. パフォーマンスを殺す「アンチパターン」
最後に、コードレビューで私が必ず指摘する「やってはいけないこと」を記す。
1. 「とりあえず」のマルチリージョン: 単一リージョンで十分な要件に対し、不要なレイテンシとコストを支払わせるな。
2. トランザクションの肥大化: マルチリージョンで不必要な長時間のトランザクションを張るな。合意形成の時間が伸びれば伸びるほど、ロック競合でシステム全体が悲鳴を上げる。
3. ゾーン障害を考慮しない設計: アプリケーションコード側で、ゾーン障害発生時のリトライ戦略（Exponential Backoff）が実装されていない。Spannerは自動復旧するが、その間の数秒を耐えられない設計は「Spannerの恩恵を捨てている」のと同じだ。
—
最後に：エンジニアへのメッセージ
Cloud Spannerは、データベースという枠を超えた「分散システムの最高傑作」だ。しかし、この道具を使いこなせるかどうかは、「物理的な距離」をどれだけ冷徹に計算できるかにかかっている。
「ベストプラクティスは何か？」と聞かれたら、私はこう答える。
「ビジネス要件と物理法則の交差点を探せ」と。
インスタンスの配置戦略を一度設計したら、それで終わりではない。トラフィックのパターンが変われば、構成の最適解も変わる。常にモニタリングし、勇気を持って構成を変更（レプリカ追加・削除）する。それこそが、本物のSpannerエンジニアの姿だ。
設計に迷ったら、またここへ戻ってこい。議論しよう。
コメント