【Cloud Spannerの深層】ウィットネスレプリカ（Witness Replica）の真実と、コストを抑えて可用性を極限まで高める設計パターン
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいはアーキテクチャ設計レビューで、こんな議論が出なかっただろうか？
- 「マルチリージョン構成にしたいが、ストレージコストが倍増するのは予算的に厳しい」
- 「可用性（SLA 99.999%）は絶対に死守したいが、本当にすべてのリージョンにフルデータを置く必要があるのか？」
この問いに対するCloud Spannerからの回答が、「ウィットネスレプリカ（Witness Replica）」だ。
教科書的なドキュメントにはこう書いてある。「データを保持せず、Paxosの投票権のみを持つレプリカです」。
だが、プロのエンジニアならこう突っ込まなければならない。「データを持たないのに、どうやって一貫性と可用性を担保するのか？」「安物買いの銭失いにならないための正しい配置戦略とは何か？」と。
今回は、Spannerのコアアーキテクチャの深部に踏り込み、ウィットネスレプリカを実務の武器として使いこなすための知見を叩き込む。
—
1. そもそもウィットネスレプリカとは何者か？
Cloud Spannerの基盤を支えるのは、Paxos分散合意アルゴリズムだ。
スプリットブレインを防ぎ、強整合性（Serializable）を担保するためには、Paxosグループ内で過半数（Quorum）の合意が必要になる。
通常、リージョン間（マルチリージョン）で可用性を高める場合、次のような構成を考える。
- リージョンA（リーダー）
- リージョンB（フルリード/ライトレプリカ）
- リージョンC（フルリード/ライトレプリカ）
この構成では、すべてのリージョンが全データのストレージを持ち、同期書き込みを行う。ストレージコストはリージョン数に比例して跳ね上がる。ここで登場するのがウィットネスだ。
[リージョンA: リーダー] (データあり + 投票権)
[リージョンB: メンバー] (データあり + 投票権)
[リージョンC: ウィットネス] (データなし + 投票権のみ)
ウィットネスレプリカの本質は、「ストレージコストを極限まで削りながら、Paxosのクォーラム（過半数の投票権）を物理的に離れた場所に確保する」ための苦肉の策……ではなく、極めて洗練されたアーキテクチャ上のトリックである。
ウィットネスの3大特徴
1. データストレージがゼロ：ユーザーデータのコピーを持たないため、ストレージ費用がかからない（正確にはメタデータやログの一部例外はあるが、実データコストは圧倒的に低い）。
2. 計算・投票ノードとして機能：Paxosのリーダー選挙や、コミット時のログ複製（プレペアド・フェーズ）において「1票」を投じる。
3. 読み取りリクエストには応えられない：データがないのだから当然だ。だが、書き込みのクォーラム形成には不可欠である。
—
2. なぜウィットネスが必要なのか？（数学的・物理的必然）
マルチリージョン構成で可用性（99.999%）を担保するには、最低3つの独立した障害ドメイン（通常は3つのリージョン）に投票権を分散させる必要がある。これを「3リージョン・クォーラム」と呼ぶ。
もし、リージョンAとリージョンBの2つだけで構成した場合、どちらか一方がネットワーク断や大規模障害で落ちた瞬間、過半数（2票中の2票、あるいは過半数割れ）を失い、書き込みが停止（Availabilityの喪失）する。
かといって、3つすべてのリージョンにフルデータを置くと、ストレージ料金が3倍になる。
ここでSpannerの設計者は考えた。「書き込みの合意（Paxos）に必要なのは、データのコピーそのものではなく、『トランザクションの順序合意』だけではないか？」と。
こうして、データを持たずに合意形成（投票）だけに特化したウィットネスが生まれた。
—
3. 実務で直面する設計の罠：ウィットネス配置のアンチパターン
設計レビューでよくある事故が、「とりあえずコスト削減のために、適当なリージョンにウィットネスを置く」という愚行だ。
ウィットネスを配置する際は、以下の物理法則（ネットワーク遅延と障害独立性）を厳守しなければならない。
罠その1：レイテンシの罠
Paxosは、過半数のノードからの応答（RTT）を待ってコミットを完了する。
もし、リーダー（リージョンA）から遠く離れた、レイテンシが極悪なリージョンCにウィットネスを置いた場合、すべての書き込みレイテンシがそのウィットネスとの往復時間に引きずられることになる。
> 【チーフアーキテクトの教訓】
> 「ウィットネスはコストが安いからといって、地球の裏側に置いてはならない。書き込みレイテンシの許容範囲内（通常は同一大陸内や、レイテンシが安定しているピアリングリージョン間）に配置せよ。」
罠その2：相関障害（Correlated Failures）の罠
3つのリージョン（A, B, C）でクォーラムを組む際、AとCの電力網や海底ケーブルが同じ経路だった場合、C（ウィットネス）が落ちると同時にAが孤立する可能性がある。
「データを持たないから適当でいいや」ではなく、フルレプリカと同等以上に、独立した障害ドメイン（Fault Domain）を選定する必要がある。
—
4. Cloud Spannerにおけるデフォルト挙動とコスト構造
実は、Google Cloud Spannerの標準的なマルチリージョン構成（例: `nam-eur-asia` のようなグローバル構成、あるいは USの特定マルチリージョン）では、Googleが最適なクォーラム配置を裏側で自動的に管理している。
ユーザーがマルチリージョンインスタンスを作成する際、Googleは自動的に「2つのフルデータ・リージョン + 1つのウィットネス（あるいはそれに準ずる投票ノード）」のトポロジーを構築していることが多い。
コスト面でのインパクト（実務目線）
- ストレージ料金：フルデータリージョン分の容量課金のみ。ウィットネス分のデータストレージ課金は発生しない。
- ネットワーク（下り）料金：Paxosの同期トラフィックは発生するため、リージョン間転送量（Cross-region network egress）のコストは発生する。ここは削減できないので注意せよ。
—
5. 設計レビューで使えるチェックリスト
もし、あなたがチームのテクニカルリードとして、Cloud Spannerのマルチリージョン構成をレビューする立場なら、以下の質問を投げかけてほしい。
1. 「このマルチリージョン構成におけるPaxosの投票権の内訳はどうなっているか？」
（答えられないエンジニアは、Spannerの公式ドキュメントを表面しか読んでいない）
2. 「書き込みレイテンシのSLAに対して、ウィットネスの物理的配置距離は許容範囲内か？」
（地球の裏側にウィットネスを置いてレイテンシが爆発していないか確認する）
3. 「コスト削減目的でシングルリージョンに逃げようとしていないか？ 可用性とのトレードオフを数式で説明できるか？」
—
6. まとめ
ウィットネスレプリカは、「データの耐久性と可用性を落とさずに、ストレージコストの無駄を極限まで削ぎ落とす」ための、Spannerの分散合意アルゴリズムにおけるマスターピースだ。
仕組みの本質を理解していれば、単なるマネージドサービスの裏側のブラックボックスではなく、「どこに・なぜその構成が必要なのか」をロジカルに設計・説明できるはずだ。
次のアーキテクチャ設計では、ぜひこの「ウィットネス」というカードを戦略的に切ってみせたまえ。健闘を祈る。
コメント