【テクニカル・上級編】高可用性（HA） – Cloud Spanner

Cloud Spannerの99.999%：物理レイヤの制約を「合意」で塗り替えるアーキテクチャの真髄

世の中の多くの分散データベースが「可用性」と「整合性」の狭間で妥協を強いられる中、Cloud Spannerが99.999%のSLAを平然と提示できる理由は、単なる冗長構成にあるのではない。それは、TrueTimeによる原子時計の同期と、Paxosアルゴリズムの極限までの最適化によって、物理的な制約を論理的な秩序で上書きしているからだ。

今回は、我々が「5つの9」という聖域をどのように維持しているのか、その内部メカニズムを解剖する。

—

1. Paxosの「外」にある非同期レプリケーションの幻想を捨てる

多くのRDBMSが追従する「非同期レプリケーション」は、可用性の観点では脆弱だ。マスターが死ねば、最後尾のトランザクションは消失（データロス）のリスクに晒される。

Spannerの核心は、「すべての書き込みはPaxosグループにおいて過半数の合意を得なければ完了しない」という厳格なルールにある。

SplitとLeader: データは「スプリット」単位で分割され、各スプリットはPaxosグループを形成する。
Leaderの責務: リーダーノードは単なる書き込み受付ではない。Paxosのログエントリをフォロワーに伝播させ、過半数（Quorum）のACKを待つ。この過程で、物理的なノード障害は「一時的なネットワーク遅延」と同等のコストで、透過的に切り離される。

ここでの肝は、フェイルオーバーの自動性だ。リーダーがダウンすれば、Paxosの心拍タイムアウトを待つことなく、即座に新しいリーダーが選出される。このプロセスにおいて、データの一貫性は数学的に保証されている。

2. TrueTime：物理の限界を超越する「絶対的時刻」

Spannerの真の強みは、Paxos単体ではなく、Googleのインフラに組み込まれたTrueTime APIにある。

分散システムにおける最大の敵は「時刻のズレ」だ。時刻がズレれば、シリアライザブルなトランザクションは崩壊する。Spannerは、GPSと原子時計を用いて、時刻の不確実性（$\epsilon$）を常に計算している。

// 概念的なTrueTimeの利用イメージ
// 読み取りは、この「不確実性の終わり」を待つことで、
// 物理的に離れたノード間でも整合性のあるスナップショットを取得する
Timestamp t = TrueTime.now();
// 読み取り要求にはこのタイムアウト値を伴い、
// 全てのレプリカがこの時刻以降の状態に到達していることを保証する

この「不確実性を管理下に置く」という設計思想こそが、地理的に分散した環境下でも、グローバルな強整合性を実現しつつ、可用性を落とさない秘訣だ。

3. メモリ最適化：Read-Onlyレプリカの戦略的配置

99.999%の可用性を維持しつつ、読み取りパフォーマンスを最大化するために、我々は「Read-Onlyレプリカ」を戦略的に配置する。

Read-Onlyの役割: これらはPaxosの投票権を持たない。つまり、書き込みのQuorum計算に参加しない。
パフォーマンスの向上: 書き込みのレイテンシを増大させることなく、読み取り専用のトラフィックをオフロードできる。
メモリの使いどころ: スプリットのリーダーは、頻繁にアクセスされるデータをメモリ内のキャッシュ（LRUベースのバッファキャッシュ）に載せるが、Read-Onlyレプリカは、物理的なディスクIOを最小化するために、より積極的にインデックスのヒントをメモリに展開する。

4. 運用という名の「静かな破壊」への耐性

5つの9を支えるのは、高度な自動化だ。Spannerのコントロールプレーンは、ノードのCPU負荷、メモリ使用率、ディスクIOPSをミリ秒単位で監視している。

仮に特定のデータセンターで障害の予兆（ハードウェアの劣化など）を検知した場合、Spannerは以下のプロセスを自動実行する。

1. プロアクティブな移行: 障害が発生する前に、スプリットを健全なノードへ移動（レプリカの再配置）。
2. Paxosグループの再構成: 現在のリーダーを安全に引き継ぎ、クライアントへの影響をゼロにする。
3. セルフヒーリング: 障害が起きたノードが復帰すれば、差分ログ（Log-structured Merge-treeの設計に基づく）を高速に同期し、再びQuorumに加える。

エンジニアへの提言

99.999%を追求するということは、「障害が起きることは前提条件である」という哲学を受け入れることだ。

もしあなたが自前でデータベースを運用し、可用性を高めようとしているなら、Paxosの再実装を夢見る前に、まずネットワークの不安定さとクロックのドリフトが、あなたの設計にどのような破壊をもたらすかを計算すべきだ。

Cloud Spannerは、それら全ての複雑性をプラットフォーム側に隠蔽した。しかし、隠蔽されているからといって、その仕組みを理解せずに使うのはエンジニアとして片手落ちだ。データが物理的なノードを離れ、Paxosの合意という論理的な宇宙に漂う様子を想像できるようになって初めて、Spannerの真価を運用に活かせるようになる。

我々が提供しているのは、単なるマネージドサービスではない。分散システムの「究極的な解答」そのものだ。