MeerkatがRaftを選ばなかった理由――変動の大きい広域ネットワークでの安定性向上を狙った実験的な合意アルゴリズム選定
Cloudflareが、実験的な合意サービス「Meerkat」で、RaftでもPaxosでもなく2023年発表の新しい合意アルゴリズム「QuePaxa」を採用したと明らかにしました。特定のリーダーが止まっても処理を続けられる設計だといいます。採用理由は、インターネット経由でレプリカ同士がつながるMeerkatの構成では、固定リーダーへの依存がボトルネックになりやすいからです。実績十分なRaftを捨ててまで新顔を選んだ判断の中身を見ていきます。
Cloudflareが抱えていた課題とQuePaxaという選択
Cloudflareは、世界中のデータセンターから読み書きされる小規模なコントロールプレーン情報を管理するため、Meerkatという実験的な分散合意サービスを開発しています。コントロールプレーン情報とは、たとえばどのサーバーが現在のリーダーか、どのレプリカがリースを持っているか、といったシステム運用上のメタデータのことです。利用者のデータそのものではなく、システムを正しく動かすための「裏方の記録」だと考えると分かりやすいかもしれません。
Meerkatの核になっているのが、研究者Tennage & Băsescu氏らが2023年に発表した合意アルゴリズム「QuePaxa」です。合意アルゴリズムとは、複数台のマシンが一つの共有された真実に同意する仕組みのことで、一部のマシンが壊れたり通信が切れたりしても、各マシンの記録が食い違わないことを保証します。Cloudflare Blogによれば、Consulやetcd、Apache ZooKeeperといった類似システムは存在するものの、Meerkatはこれらと違い、大陸をまたいで分散し、しかも遅延が高く不安定になりがちな回線でつながる環境向けに設計されています。
一般的な合意アルゴリズムであるRaftや(Multi-)Paxos、Viewstamped Replicationは、実績があり実装も成熟しています。ただしこれらは、単一のリーダープロセスが利用可能で、かつ予測可能な遅延で動くことを前提にしています。リーダーが停止したり、普段より遅延が大きくなったり、ネットワークから切り離されたりすると、リーダーが交代するまでシステム全体が遅くなるか、使えなくなります。Cloudflareは、この挙動がMeerkatには受け入れられないと判断しました。インターネットのように変動の大きいネットワークでは、リーダー依存の方式が頻繁に揺さぶられることになるからです。
QuePaxaでは、特定のリーダーだけでなく、どのレプリカからでも合意形成を開始できる仕組みになっています。リーダーという役割自体は存在しますが、それは正しさや処理の進行に必須の存在ではなく、正常時に往復回数を減らすための最適化にすぎません。Cloudflareはこれを、QuePaxaが初めてグローバル規模で産業利用される事例にすることを目指しているとしています。
この選択はCloudflare自身も「less-traveled path」と表現しているとおり、RaftやPaxosほど実戦で鍛えられてはいません。さらにCloudflareは、元の「クラッシュして止まるだけ」の設計を拡張し、クラッシュからの復旧にも対応させています。そのため、通常のシステムよりも慎重な設計と、正しさを裏付ける強い証拠が必要になるといいます。Cloudflareは、QuePaxaの実装とMeerkat全体を形式的に検証する作業を、シミュレーションや障害注入テストと並行して進めているとしています。
QuePaxaが解決しようとしている遅延・障害の構造的な問題
なぜリーダー依存がそれほど問題になるのか。ここで手がかりになるのが、分散システムの障害について書かれたMarc Brooker氏のブログにある「メタ安定性(metastability)」という考え方です。これは、Bronson氏らの論文「Metastable Failures in Distributed Systems」を引きながら説明されているもので、かみ砕いて言えば「一度悪い状態に入ると、原因が取り除かれてもその悪い状態のまま居座ってしまう」現象を指します。
分かりやすい例がキューの滞留です。何らかの短い障害や負荷の急増が起きると、システム内のキューに処理待ちがたまり、レイテンシが上がります。レイテンシが上がるとクライアントがタイムアウトしてしまい、結果を待たずに次のリクエストを送ってきます。システムは律儀に処理を続けますが、クライアントはもう結果を待っていないので、その処理はすべて無駄になります。処理件数（throughput）は高いままなのに、実際に役立った処理件数（goodput）はゼロになる、という逆説的な状態です。brooker.co.zaは、この種の障害がハイパースケールな分散システムの運用者には「よく知られている」としつつ、リトライや、キャッシュ、遅いエラー処理経路、ロードバランシングの振る舞いなど、システムの効率や信頼性を高めるはずの仕組みそのものが引き金になりうると指摘しています。
Meerkatの文脈に戻すと、固定リーダー方式の合意アルゴリズムは、リーダーに障害が起きた瞬間にシステム全体が停止または遅延するという、分かりやすい単一障害点を抱えています。QuePaxaが目指しているのは、この単一障害点をなくし、過半数のレプリカに到達できる限りは処理を続けられるようにすることです。ここで比較の物差しとして使えるのが、HashiCorpが提供するConsulの推奨構成です。developer.hashicorp.comによれば、Consulは3つのアベイラビリティゾーンに分散した5ノード構成を推奨しており、この構成はクラスタ内2ノードの喪失、またはアベイラビリティゾーン一つ丸ごとの喪失に耐えられるとしています。ただしConsulが使うRaftは、単一リージョン内、低遅延ネットワークでの運用を前提とした設計です。実際、HashiCorpの資料は、単一のConsulクラスタを複数リージョンにまたがらせることは、ネットワーク遅延の問題から推奨されないと明記しています。
重要なのは、Meerkatが解決しようとしているのは「ConsulのRaftが壊れている」という話ではなく、Raftのような固定リーダー型アルゴリズムが前提とする運用環境と、Cloudflareが必要とする大陸をまたぐ分散環境との間にあるミスマッチだという点です。出典が説明しているのはここまでで、QuePaxaが実際にどの程度このミスマッチを解消できるかという定量的な比較は、今回確認できた記事には含まれていません。
用語補足：線形化可能性(linearizability)
線形化可能性とは、分散システムの複数の操作が、まるで実時間上のどこか一点で瞬時に起きたように見えることを指す整合性の水準です。ある書き込みが完了したあとに始まった読み取りは、その書き込み以前の値を返してはいけません。プログラマーから見れば、分散システムを「一台のマシン上の単一スレッドのメモリ」のように扱えることを意味します。Meerkatが目標とするのはこの線形化可能性であり、その上に載るトランザクショナルなKVストアは、複数の処理の結果が何らかの直列実行と等価になることを保証する直列化可能性(serializability)も提供するとされています。ただし、この直列化可能性をどう実装しているかの詳細は、今回確認できた出典には記載がありません。
注目ニュース
Meerkatが想定する障害モデルと現在の開発段階
Meerkatは、2f + 1台のレプリカがあればf台までの障害を許容する、過半数ベースのクラッシュ障害モデルを採用しています。クライアントは特定のレプリカやリーダーに到達する必要はなく、過半数につながる健全なレプリカであればどれでもよいという可用性を目指しています。ただし、侵害されたノードが意図的に虚偽のメッセージを送るようなビザンチン障害は扱わず、各ノードは悪意を持たずバグもないという前提に立っています。クライアントが過半数と接続されたレプリカに到達できないネットワーク分断では、線形化可能な読み書きは完了できません。2026年7月8日時点でMeerkatはまだ本番投入されておらず、最大50レプリカを世界中に配置した複数のPoCでリーダーを継続的に故障させる試験を実施し、エラー率の増加はなかったとされていますが、本番環境での長期運用実績ではありません。zenn.dev
NVIDIA、フアン氏が辞任しクレスCFOが暫定CEOに
米NVIDIAは11月12日（現地時間）、1993年の共同創業以来同社を率いてきたジェンスン・フアン氏が社長兼CEOと取締役を即日辞任したと発表しました。CFOのコレット・クレス氏が暫定CEOに就任し、取締役会は社内外から正式なCEOを選ぶとしています。取締役会は、米Synopsysの元CEOで取締役のHarvey C. Jones氏を、NVIDIA初の取締役会議長にも任命しました。フアン氏を巡っては、親密な関係にあった実業家が中国の情報機関に協力していた疑いを米情報当局が把握していたと米New York Timesなどが報じ、本人は8日に従業員向けメッセージで妻への不貞を認めて謝罪、同紙は11日に直属の部下との不倫関係も報じていました。四半期決算は予定通り17日に発表するとされています。なお、NVIDIAを巡っては、中国向けH20輸出規制で55億ドル（約8,780億円）の損失見込みも別途報じられています。ITmedia NEWS
編集後記：リーダー不要という設計が運用現場で何を変えるのか
QuePaxaの要点は、Raftより強い整合性を提供することではありません。Raftも正しく構成すれば線形化可能なログを提供できます。違いは、過半数ベースの安全性を保ちながら、合意を進める権限を一台の必須リーダーに集中させない点にあります。QuePaxaのリーダーは速度のために存在しますが、停止しても別のレプリカがより多くの往復通信を使って処理を続けられる設計です。その代わり、非リーダー経路は通常3往復以上を要し、グローバル配置では読み書きの遅延が増えます。つまりMeerkatは、高スループットな汎用データベースを狙ったものではなく、広域ネットワークでリーダー選挙の停止を避けたい、小規模で重要なコントロールプレーン状態に用途を絞った設計です。今回確認できた出典が説明しているのはここまでで、本番投入後にこのトレードオフがどう評価されるかは、続報を待つ必要がありそうです。