理念と共に、最も困難で狂気の選択を考え続けて諦めない

世の中わからないことだらけだ.少し確かなことは検証をしたことだけ

etcd を奇数台にする理由は「スプリットブレイン対策」なのか

etcd の構成について調べると、「スプリットブレインを防ぐために奇数台にする」と説明されることがあります。

この説明は、運用上の結論だけを短く言うなら理解できます。

etcd では奇数台構成が推奨されます。

また、etcd が使う Raft は、矛盾する状態が複数の分断側でコミットされることを避けるように設計されています。

そのため、入門記事や運用記事で「スプリットブレインを避けるために奇数台にする」と短く説明されること自体は自然です。

ただし、この説明をそのまま Raft の仕組みとして読むと、奇数台構成と quorum の役割を取り違えやすくなります。

この記事は、既存の記事を否定するためのものではありません。

むしろ、既存の記事が伝えている「etcd では quorum が重要であり、奇数台構成が推奨される」という実用上の結論を前提に、その理由を Raft の動作に沿って少し精密化するものです。

より正確には、次のように整理できます。

etcd / Raft でスプリットブレイン不整合を防ぐ直接の仕組みは、奇数台構成ではなく、Raft の多数派に基づくリーダー選出とコミットの規則である。etcd の文書では、この多数派を quorum と呼ぶ。奇数台構成が推奨される主な理由は、障害許容性、quorum 効率、コスト効率、ネットワーク分断時の可用性にある。

既存記事が伝えている重要な点

たとえば、次の記事では、etcd のノード数や quorum がスプリットブレイン防止と結びつけて説明されています。

これらの記事は、etcd の構成を考えるうえで重要な点を説明しています。

quorum が必要であること、etcd で奇数台構成が推奨されること、3 台、4 台、5 台における quorum と障害許容性の関係は、いずれも etcd の説明と整合しています。

特に、運用者に対して「etcd は多数派を必要とするため、3 台や 5 台のような奇数台で構成するのが基本」と伝えることは実用上重要です。

この記事で補足したいのは、その運用上の結論ではありません。

補足したいのは、「スプリットブレイン不整合を直接防いでいる仕組みは何か」という点です。

「奇数台だからスプリットブレインを防げる」と読むと、奇数台構成そのものが安全性の直接の仕組みであるように見えます。

しかし、Raft の観点では、スプリットブレイン不整合を防ぐ直接の仕組みは majority quorum です。

スプリットブレイン不整合

ここでいうスプリットブレインは、単なるネットワーク分断ではありません。

ネットワーク分断は現実に起きます。

Raft や etcd は、ネットワーク分断そのものを防ぐわけではありません。

問題になるのは、複数の分断されたグループが、それぞれ正当なクラスタとして矛盾する書き込みをコミットし続ける状態です。

この記事では、この状態を スプリットブレイン不整合 と呼びます。

etcd が使う Raft の前提下で、正しく実装され、正しく運用されている etcd では、この意味でのスプリットブレイン不整合は起きません。

リーダー選出にも書き込みのコミットにも、多数派が必要だからです。

スプリットブレイン不整合を防ぐのは quorum

etcd の quorum は、Raft でいう多数派です。

投票権付きメンバー数を N とすると、quorum は次の式で決まります。

quorum = floor(N / 2) + 1

ここでの N は投票権付きメンバー数です。

learner は投票権を持たないため、quorum の計算には含めません。

投票権付きメンバー数 quorum 許容できる障害数
3 2 1
4 3 1
5 3 2
6 4 2

4 台構成を考えます。

4 台のクラスタが 2 台ずつに分断された場合、それぞれのグループには 2 台しかありません。

しかし、4 台構成の quorum は 3 です。

そのため、どちらのグループも quorum を満たせません。

election が始まっても多数派票を得られないため、新しいリーダーは選出されず、新規書き込みもコミットできません。

既存リーダーが quorum を満たさない側で、しばらく自分をリーダーだと認識し続けることはあります。

しかし、そのリーダーは多数派の応答を得られないため、新規書き込みをコミットできません。

これはスプリットブレイン不整合ではありません。

quorum 喪失による可用性低下です。

奇数台が推奨される理由

奇数台構成が推奨される主な理由は、投入するノード数に対する障害許容性の効率がよいからです。

3 台と 4 台を比較します。

3 台: quorum 2, 許容できる障害数 1
4 台: quorum 3, 許容できる障害数 1

4 台に増やしても、許容できる障害数は 3 台構成と同じです。

一方で、ノード数は増えます。

リーダーが複製する相手も増え、コミットに必要な応答数も増えます。

3 台構成では、リーダー自身のログに加えてフォロワー 1 台に複製できれば、多数派に達します。

4 台構成では、リーダー自身のログに加えてフォロワー 2 台に複製する必要があります。

一方、4 台から 5 台に増やすと、quorum は 3 のまま、2 台障害まで許容できます。

4 台: quorum 3, 許容できる障害数 1
5 台: quorum 3, 許容できる障害数 2

奇数台から 1 台増やして偶数台にしても、直前の奇数台構成と比べて追加の障害許容性は得られません。

このため、etcd では通常、3 台、5 台、7 台のような奇数台構成が選ばれます。

ただし、これは「奇数台でないとスプリットブレイン不整合に対する安全性が成立しない」という意味ではありません。

奇数台構成は、全ノードが二つのグループだけに分断される場合には、一方が必ず多数派になるという可用性上の利点を持ちます。

一方で、5 台が 2-2-1 に分かれるような多分割のネットワーク分断や、同時ノード障害まで含めれば、奇数台でも多数派側が常に残るわけではありません。

Raft のリーダー選出

Raft では、候補者がリーダーになるには、同一 term において現在の投票構成の多数派票を得る必要があります。

各ノードは、同一 term で最大 1 つの候補者にしか投票しません。

そのため、同一 term でリーダー選出に勝てる候補者は最大 1 つです。

ここで、「いかなる瞬間にも複数リーダーが絶対に存在しない」と言い切ると雑になります。

ネットワーク分断中には、古いリーダーが少数派側で自分をリーダーだと認識し続け、別の多数派側でより新しい term のリーダーが選ばれることがあります。

しかし、少数派側の古いリーダーは多数派の応答を得られないため、新規書き込みをコミットできません。

複数の分断されたグループが、それぞれ独立に正当なリーダーとして矛盾する書き込みをコミットし続けることはできません。

この性質が、etcd と Raft におけるスプリットブレイン不整合の防止です。

投票割れはスプリットブレインではない

Raft のリーダー選出では、投票割れが起きることがあります。

複数ノードがほぼ同時に候補者になると、票が割れて誰も多数派票を得られない場合があります。

この場合、リーダーが複数成立するのではありません。

リーダーが決まらないだけです。

Raft では、選挙タイムアウト後に新しい term で再選挙されます。

また、ランダム化された選挙タイムアウトによって、投票割れが繰り返されにくいように設計されています。

投票割れ:
  誰も多数派票を取れず、リーダーが決まらない

スプリットブレイン不整合:
  複数の分断されたグループが、矛盾する書き込みをコミットし続ける

前者はリーダー選出の遅延や可用性の問題です。

後者は安全性の問題です。

前提条件

ここまでの話は、Raft の通常の障害モデルの範囲に限られます。

Raft はビザンチン障害耐性を持つ合意アルゴリズムではありません。

想定しているのは、クラッシュ、復旧、パケットロス、遅延、ネットワーク分断などの非ビザンチン障害です。

結論

「etcd はスプリットブレインを防ぐために奇数台にする」という説明は、運用上の短い説明としては理解できます。

実際、etcd では奇数台構成が推奨されます。この実用上の結論は変わりません。

ただし、Raft の動作として見ると、スプリットブレイン不整合を防ぐ直接の仕組みは、奇数台構成そのものではありません。

より正確には、次のように説明できます。

etcd / Raft でスプリットブレイン不整合を防ぐ直接の仕組みは、奇数台構成ではなく、Raft の多数派に基づくリーダー選出とコミットの規則である。 etcd の文書では、この多数派を quorum と呼ぶ。 リーダー選出と書き込みのコミットは多数派に基づくため、正しい Raft の前提下では、複数の分断されたグループが矛盾する書き込みをコミットし続けることはできない。 奇数台構成が推奨される主な理由は、障害許容性、quorum 効率、コスト効率、ネットワーク分断時の可用性にある。

つまり、既存の記事が伝えている「etcd は奇数台で構成するのがよい」という結論はそのまま有効です。

この記事で補足したかったのは、その理由づけです。

奇数台構成は有効な構成ですが、スプリットブレイン不整合に対する安全性の直接の必要条件ではありません。

その安全性は、奇数台という慣習ではなく、Raft の多数派に基づくリーダー選出とコミットの規則によって担保されています。

参考