【実務・中級編】ウィットネスレプリカ – Cloud Spanner

Cloud Spannerの「見えない守護者」：Witnessレプリカを使いこなせ

いいか、Cloud Spannerを単なる「Googleが作った高可用なRDB」としか見ていないなら、その設計は甘い。

多くのエンジニアがマルチリージョン構成を組む際、コストと可用性のバランスで頭を抱える。そこで登場するのが「Witness（ウィットネス）レプリカ」だ。だが、こいつを単なる「投票用の飾り」だと思っているなら、今すぐ考えを改めるべきだ。これは、分散システムの堅牢性を極限まで高めるための「戦略的リソース」だ。

今日は、教科書的な解説はすっ飛ばして、実務レベルでWitnessをどう扱い、どう設計すべきかを叩き込む。

—

1. Witnessの本質を理解する

まず、Paxosのクォーラム（過半数）理論を思い出せ。3ノード構成で2/3、5ノードで3/5の合意があれば、書き込みは確定する。

Witnessレプリカは、以下の特徴を持つ：

データコピーを持たない: ストレージを消費しない。
投票権を持つ: Paxosのラウンドで「Yes/No」を投じる。
リーダーにはなれない: データの保持がないため、当然だ。

「なぜわざわざ投票だけのノードを置くのか？」
答えはシンプルだ。「物理的な距離によるレイテンシの増大を抑えつつ、書き込みの可用性を維持するため」だ。通常、過半数の合意を得るには、広域ネットワークを超えてデータを同期させる必要がある。だが、データを持たないWitnessなら、通信コストを最小化しつつ、論理的な「過半数」を構成できる。

—

2. 設計における「黄金比」：マルチリージョン構成の勘所

実務で最も多いのは、3リージョン構成で「2つの読み取り可能なリージョン」＋「1つのWitnessリージョン」を置くパターンだ。

[Region A: Leader/Full Replica] <-----> [Region B: Follower/Full Replica]
^ ^
|———- [Witness] ————–|

なぜこれが最強なのか？

高可用性: AかBが沈んでも、生き残ったリージョンとWitnessで過半数を維持できる。
書き込みレイテンシの抑制: 3つ目のフルレプリカ（データ持ち）を遠隔地に置くのと比べ、WitnessはネットワークIOが軽量だ。データの物理転送を伴わないからな。
コスト効率: ストレージ料金がかからない。これが地味に効く。

チーフアーキテクトからの忠告：
Witnessを置くリージョンは、必ず「他の2つのリージョンからネットワーク的に最も安定している場所」を選べ。もしWitnessのネットワークが不安定なら、それはそのままシステムの書き込み停止（可用性低下）に直結する。「とりあえず近いから」で選ぶな。リージョン間のクロスリージョン・ネットワークのレイテンシと変動幅を監視し、その中心点にWitnessを置くのがプロの仕事だ。

—

3. パフォーマンスと運用の「落とし穴」

Witnessレプリカは「データを持たない」が、「Paxos通信には参加する」ことを忘れてはならない。

注意点1：ネットワークのオーバーヘッド

Witnessはデータのレプリケーションは行わないが、Paxosの提案（Proposal）に対する投票メッセージは受け取る。もしWitnessリージョンとの回線が細い、あるいは不安定な場合、リーダーはクォーラム形成のために待機時間を強いられる。これはレイテンシのスパイクとして顕在化する。

注意点2：リージョン障害時の振る舞い

Witnessリージョンが完全にダウンした場合、構成によっては「書き込み可能なレプリカの数」が減る。この状態で別のフルレプリカが落ちれば、即座にダウンタイムだ。Witnessは「おまけ」ではなく、アーキテクチャの要石であるという認識をチームで共有しておけ。

—

4. こう設計せよ：実務的チェックリスト

設計レビューで私が必ず確認するポイントを記す。君たちの設計がこれに準じているか確認してくれ。

1. Read-Onlyの要件は何か？

もし全リージョンで高速な読み取りが必要なら、Witnessではなくフルレプリカを検討しろ。Witnessは「書き込み可用性」を救うためのものだ。

2. Witnessのリージョン選定は適切か？

メインの2リージョンとのRTT（往復遅延時間）を比較し、最も安定した経路を選択しているか？

3. 監視はできているか？

Witnessリージョンのヘルスステータスだけでなく、Paxosの投票レイテンシ（`spanner.googleapis.com/instance/leader_election_latency` 等）を注視しろ。

—

最後に：エンジニアとしての矜持

Cloud SpannerにおけるWitnessレプリカは、物理法則（光速の壁）を数学でハックするエレガントな解法だ。しかし、ツールを正しく理解せずに使うのは、ただの「おまじない」に過ぎない。

システムは、書かれたコード以上に、「そこに何がないか（何をあえて持たせないか）」という引き算の設計でその真価が決まる。Witnessレプリカを使いこなすということは、分散システムの理論と、泥臭いネットワークトポロジーの両方を愛するということだ。

設計が終わったら、もう一度構成図を見直せ。そのWitnessは、本当にシステムを救う位置にいるか？

それができていれば、君のアーキテクチャは世界最高峰に一歩近づく。健闘を祈る。