【テクニカル・上級編】インスタンス構成 – Cloud Spanner

Cloud Spannerのインスタンス構成：物理レイヤーから読み解く「可用性とレイテンシの真実」

Cloud Spannerを単なる「マネージドな分散RDBMS」と呼ぶのは、エンジン設計者から見ればあまりに表層的だ。Spannerの真髄は、「TrueTimeによる外部整合性の維持」と「Paxosによるレプリケーション」を、物理的な距離の制約の中でいかに調停するかという点にある。

アーキテクトとして、インスタンス構成を選択する際、カタログスペックの可用性パーセンテージを眺めるのは素人の所業だ。我々が見るべきは、Paxosグループが物理的にどう配置され、書き込みのラウンドトリップがどの程度の「物理的コスト」を支払うか、その一点に尽きる。

—

1. リージョン構成：局所的整合性と書き込みスループットの極致

シングルリージョン構成を選択するということは、「Paxosのリーダーとレプリカの物理距離を最小化し、TrueTimeの不確実性（$\epsilon$）を極限まで抑え込む」という意思決定に他ならない。

内部メカニズムの要諦

シングルリージョンでは、Paxosグループは同一リージョン内の複数のゾーンに分散される。ここでのレイテンシ支配要因は「ディスクI/O」ではなく、ゾーン間を跨ぐ「ネットワークの往復時間（RTT）」だ。

書き込みパス: クライアントがリーダーに書き込みをリクエストし、過半数のレプリカがログを永続化するまで待機する。シングルリージョンであれば、このRTTは数ミリ秒オーダーに収まる。
メモリ最適化: リージョン構成では、データアクセスが局所化されるため、各ノードのBuffer Poolが非常に効率的に機能する。頻繁にアクセスされるホットな行はLSMツリーの最上位レイヤーに留まりやすく、キャッシュヒット率の最大化が容易だ。

アーキテクトの戒め: 「安価だから」という理由でリージョン構成を選ぶな。そのデータが地理的に分散したユーザーからアクセスされる場合、後述するマルチリージョン構成への移行には「データ再配置（Rebalancing）」という重いコストを支払うことになる。

—

2. マルチリージョン構成：CAP定理への挑戦と物理の限界

マルチリージョン構成は、Spannerの技術的到達点だ。特に「構成可能なレプリカ配置」は、CAP定理を「いかに賢くハックするか」という問いに対するGoogleの回答である。

「読み取り専用レプリカ」の深淵

マルチリージョンにおいて最も誤解されているのが、読み取り専用レプリカの役割だ。これは単なるバックアップではない。

— 読み取り専用レプリカでのステイル読み取り（Staleness）の活用
— 物理的に近いリージョンのレプリカから読み取ることで、
— 強い整合性を犠牲にしてレイテンシを劇的に低下させる。
SELECT FROM orders@{FORCE_RPOLL_TIMEOUT=100ms, STALENESS=15s}
WHERE user_id = 12345;
— 15秒前のスナップショットをローカルで読み取ることで、
— リーダーへのRTTを完全に排除する。

書き込みの「コスト」：Witnessレプリカの役割

マルチリージョンで書き込みを行う際、すべてのレプリカがデータ保持と投票を行うと、地球規模の通信遅延がスループットを殺す。ここで登場するのがWitness（立会人）レプリカだ。

Witnessの正体: データの実体を持たず、Paxosの投票権のみを持つ軽量ノード。
物理的最適化: 書き込みの一貫性を保つための「定足数（Quorum）」を、データの複製を伴わずに達成する。これにより、書き込みのスループットを維持しつつ、広域的な耐障害性を実現している。

—

3. インスタンス構成の選択：真の設計指針

エンジニア諸君が設計時に問うべきは、次の問いだ。

1. 「強い整合性を必要とする書き込みの許容レイテンシは？」

ミリ秒単位であれば、シングルリージョン一択。

2. 「読み取りの大部分はステイル読み取りで許容可能か？」

もしYesならば、マルチリージョン構成でリージョン間に読み取り専用レプリカを散布し、グローバル規模での超低レイテンシ読み取りを実現せよ。

3. 「可用性の定義は単一リージョンの消失を想定しているか？」

リージョン単位の障害を許容するなら、マルチリージョン以外に選択肢はない。その代わり、Paxosの定足数維持のための物理的なネットワーク遅延をシステム設計の前提条件として受け入れろ。

—

最後に：チーフアーキテクトからの助言

Cloud Spannerは、単なるデータベースではない。「広域分散システムにおける物理法則の制約を、ソフトウェアでいかに優雅に抽象化するか」という研究成果そのものだ。

インスタンス構成を選ぶことは、インフラを選ぶことではない。君たちが構築するアプリケーションが、「光速の壁と、いかに折り合いをつけていくか」という哲学的な選択をしていることを忘れてはならない。

レイテンシに泣き、整合性に頭を抱える。その苦悩こそが、真のエンジニアリングの醍醐味だ。Spannerのアーキテクチャを理解すれば、その苦悩すらも計算可能な変数に変わる。

さあ、限界を超えた設計を始めよう。