Cloudflare Meerkat - グローバル分散コンセンサス

Meerkatの紹介：グローバル分散コンセンサス 2026-07-08 James Larisch Bob Halley João Pedro Leite 12 分で読めます Cloudflareの多くの内部サービスでは、330以上のグローバルデータセンター間で同じコントロールプレーンの状態を読み取り、変更する必要があります。これらのサービスは、異なるリーダーが決して一貫性のない状態を見ないこと、そして一部のデータセンターやリンクがダウンしてもシステムが書き込みのために利用可能であり続けることを保証する必要があります。しかし、Cloudflareのネットワークはインターネット全体に展開されており、インターネットは予測不可能な場所です。サーバーやデータセンターはダウンします。キューは満杯になります。リンクやケーブルは切断されます。これらの条件は、分散システムレプリカが互いにデータを確実に同期することを妨げるため、強力な一貫性（例：すべてのリーダーがすべての先行する書き込みを読み取ることが保証されること）を保証するグローバルに利用可能なデータシステムを実行することを困難にします。 悪影響のあるネットワーク条件下でも安全にデータを同期する1つの方法は、コンセンサスアルゴリズムを介することです。これは、多数のマシンが生存し、通信可能である限り、キー・バリュー・ストアのプットおよびゲット操作のような値の同じシーケンスに合意することを可能にします。残念ながら、Raftのような一般的に展開されているコンセンサスアルゴリズムは、リーダーとタイムアウトに依存しているため、Cloudflareのような広域ネットワークでは苦戦します。リーダーは書き込みを許可される唯一のレプリカであり、クラッシュやネットワークの劣化によりリーダーが失敗した場合、他のレプリカがタイムアウトして新しいリーダーが選出されるまでシステムは利用できなくなります。そして、これらのタイムアウト値は、予測不可能なレイテンシを持つネットワークでは設定が困難です。 私たちは、コンセンサス駆動型システムにおける利用不可能なリーダーに起因する複数のインシデントを経験しました。 そのため、過去1年間、Cloudflareの研究チームは、2023年にEPFLの研究者によって公開されたQuePaxaというコンセンサスアルゴリズムを搭載した、Meerkatという新しい分散コンセンサスサービスを構築してきました。QuePaxaはRaftとは異なり、すべてのレプリカが常に書き込みを実行でき、タイムアウトによる進行停止が決してないため、Cloudflareのネットワークに適しています。私たちは、トランザクションキー・バリュー・ストアやリーシングシステムのようなアプリケーションを、Meerkatのコンセンサスログの上にレイヤー化しています。私たちの知る限り、これはQuePaxaのグローバル規模での最初の産業展開となるでしょう。 Meeerkkatはまだ開発中の実験的なコンセンサスサービスです。当初は、コントロールプレーンの小さな状態（例：レプリケートされたデータベースのリーダーシップ）を管理するように設計されており、当面は内部専用となります。この記事ではMeerkatを紹介し、今後のMeerkat関連のブログ記事の基礎を築きます。 グローバルなコントロールプレーンデータシステムに求められるもの Cloudflareの多くのサービスは、世界中の複数のマシンから、そのサービスが正しく動作するのを助けるデータであるコントロールプレーンデータを読み書きします。コントロールプレーンデータの1つの例は、配置情報です。つまり、特定の（AIモデルインスタンスのような）リソースがどこに保存されているかです。もう1つの例は、リーダーシップ情報です。つまり、現在どのマシンがデータベースへの書き込みを実行することを許可されているかです。コントロールプレーンデータは、強力に一貫性があり、特定の種類の障害が発生してもアクセス可能でなければなりません。 このセクションでは、Cloudflareのコンセンサスサービスに対する一貫性と耐障害性の要件を正確に説明します。他のアプリケーション（例：分散リース/ロック）も可能ですが、ここではコンセンサスサービスの上に実行されるアプリケーションの実行例としてキー・バリュー・ストアを使用します。 強力な一貫性 分散データシステムの整合性レベルは、並行する読み書きが発生した場合にシステムがどのような奇妙な動作を許容できるかを記述します。単一の数値 x = 6 を複数のノードに保存する分散キー・バリュー・ストアを考えます。また、以下の書き込みシーケンスを考えます。これらの書き込みは、ベストエフォートで異なるノードに送信され、任意の順序で到着する可能性があります。 x = x + 1 x = x / 2 システムの整合性レベルは、これらの書き込みの後でクライアントが x を読み取ったときに、どのような値が見えるかを示します。異なる整合性レベルの下でのさまざまな実行順序と可能な結果を考えます。 弱い整合性レベルでは、書き込みの順序が入れ替わることがあります。より強い整合性モデルでは、書き込みの順序は入れ替わりませんが、読み取りは入れ替わることがあります。可能な限り最も強い整合性レベルでは、操作は実際に行われた順序とまったく同じ順序で実行されます。このプロパティは線形化可能性と呼ばれます。 Cloudflareでは、多くのサービスが線形化可能性を求めています。弱い整合性とは異なり、線形化可能性はプログラマーにデータシステムが示す可能性のある奇妙な動作のすべてを考える必要がないようにします。代わりに、単一スレッドマシン上のローカルメモリのように分散システムを推論できます。つまり、書き込み後のすべての読み取りはその書き込みを反映します。弱い整合性の危険性に関する追加の資料については、Marc Brookerによるこの記事を参照してください。 （もし疑問に思っているなら、Meerkatのキー・バリュー・ストアは直列化可能性も提供しており、これについては将来の記事で書きます。） 耐障害性 システムの耐障害性レベルは、破局的な事態が発生する前にシステムがどのような種類の障害を処理できるかを記述します。破局的な事態とは、通常、システムが維持しようとするプロパティ（例：同じキーに対する介入的な書き込みなしの2つの連続した読み取りが異なる値を見ることはない、またはシステムが書き込みのために利用可能であり続けること）の違反です。障害には、ネットワーク障害や遅延、マシンのクラッシュ、マシンの再起動が含まれます。システムは通常、一部の障害を明示的に処理しますが、他の障害は処理しません（宇宙が熱的死に達する可能性があるので、すべての障害を処理することはできません）。例えば、一部のキー・バリュー・ストアは、システム内の3分の2のマシンが通信可能でクラッシュしない限り、書き込みのために利用可能であることを保証するかもしれませんが、マシンが侵害されて悪意のあるメッセージを送信し始めた場合は何も約束しません。 私たちが望む耐障害性のプロパティは次のとおりです。 第一に、システム内の多数のマシンが生存し、互いに通信できる限り、クライアントは私たちのデータセンターのいずれかから読み書きのためにシステムを利用できる必要があります。（形式的には、2f + 1 マシンのシステムで f の障害を許容します）。 クライアントは、生存している多数のマシンに接続されているシステム内の任意のマシンに連絡できる必要があります。 これは、単一のマシン障害や単一リンクのネットワーク劣化がシステムの可用性に影響しないことを意味します。このプロパティは、後述するようにRaftベースのシステムでは提供されません。 第二に、システム内のどの主体も積極的に悪意がない限り（そしてもちろん、バグがない限り）、データシステムは正しく動作し続けます。私たちは後にコンセンサス安全性に関して正しさを定義しますが、緩やかに言えば、これは最新の状態にある2つのマシンが世界について決して意見が一致しないことを意味します（例：一方は key1=1 だと思い、もう一方は key1=2 だと思う）。 要約すると、マシンがクラッシュしたり、再起動したり、ネットワークが故障または劣化したり、データセンターがダウンしたりしても、システムは正しく動作し続けなければなりません（ただし、Raftベースのシステムと同様に、ビザンチン障害は処理しません）。 Meeerkkatの紹介 Meeerkkatは、キー・バリュー（KV）ストアのような上記のプロパティ（強力な一貫性と耐障害性）を示すアプリケーションを構築できるコンセンサスサービスです。Meerkatがどのように機能するかを理解するために、まずMeerkatの一般的なアーキテクチャの概要を説明し、次にMeerkatのコンセンサスアルゴリズムの選択が強力な一貫性と耐障害性を提供するのにどのように役立つかを説明します。 Meeerkkatを使用するサービスの開発者は、Meerkatレプリカのクラスタを要求します。各レプリカは他のすべてのレプリカに接続されています。各レプリカはコンセンサスアルゴリズムに参加し、読み書きの両方を受信できます。開発者は、どのデータセンターがレプリカをホストすることを許可されるかを指定でき、Meerkatがそれらを自動的に配置します。 クラスタと対話するために、開発者のクライアントは、クラスタ内の任意のレプリカにアプリケーション固有のリクエストを送信します。単一のレプリカは