最終更新:
分散合意・Raftの仕組みとは？過半数とログ複製を図解
ひよこ 複数のサーバーは、何に合意するの？
ペンギン先生 Raftでは、同じ位置のログに異なる操作を確定しないようにするんだ。確定した操作を同じ順番で実行することで、複製された状態をそろえる。全サーバーの値が常に同時に更新される、という意味ではないよ。
ひよこ 単純な多数決ではダメなの？
ペンギン先生 過半数は大事だけれど、それだけでは不十分なんだ。リーダーが交代しても確定済みの履歴を失わないよう、任期とログの新しさ、投票のルールを組み合わせる必要があるよ。
ひよこ PaxosとRaftはどう違うの？
ペンギン先生 どちらもクラッシュ故障を想定した合意の代表例だよ。Raftは理解しやすさを目標に、リーダー選出・ログ複製・安全性を分けて説明する設計になっている。このページではRaftの基本を追ってみよう。
ひよこ リーダーはどう選ぶの？
ペンギン先生 フォロワーが一定時間連絡を受け取れないと、任期を進めて候補者になるよ。同じ任期では各サーバーが最大1票を投じ、ログの新しさも確認する。候補者は自分を含む過半数の票を得るとリーダーになるんだ。
ひよこ 連絡が来ないなら故障したってこと？
ペンギン先生 ひよこ 書き込みは何台に届けば確定できる？
ペンギン先生 固定メンバーの基本Raftでは、リーダーを含む全投票サーバーの過半数だよ。3台なら2台、5台なら3台。ただしログの複製数から直接確定するのは現在の任期のエントリで、過去の任期のログには追加の安全性ルールがあるんだ。
ひよこ 5台が3台と2台に分断されたら？
ペンギン先生 条件を満たすリーダーがいる3台側は書き込みを進められる。2台側は過半数がないので新しい書き込みを確定できないよ。分断すると全サーバーが必ず停止するわけではないし、古いリーダーが自称していても確定権限があるとは限らないんだ。
ひよこ これならどんな障害でも大丈夫？
ペンギン先生 基本のRaftは悪意ある投票やデータ改ざんをする参加者への対策ではないよ。また、通信がいつまでも安定しなければ進行は保証できない。安全性を保つことと、処理が進むことを分けて考えるのが大切なんだ。
過半数はフォロワーだけで数えない
固定の投票メンバー数をNとすると、過半数はfloor(N / 2) + 1です。
| 投票サーバー数 | 必要な過半数 | 残りが正常・相互通信可能な場合に許容する停止台数 |
|---|---|---|
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
たとえば5台では「リーダー1台＋フォロワー2台」で3台です。これは基本の固定構成の例で、メンバー変更中の合意規則まで表していません。
複製・コミット・適用の違い
- 複製：リーダーが操作をログに追記し、フォロワーに送ります。
- コミット：現在の任期のエントリが過半数に複製されるなど、安全性の条件を満たして確定します。
- 適用：確定したログを順に状態機械へ反映します。遅れているフォロワーは後で追いつきます。
したがって「1台に保存された」だけでは確定ではありません。逆に、確定時にすべてのフォロワーの適用が終わっている必要もありません。最新の値を読むには読み取り側にも適切な手続きが必要で、任意のフォロワーから読むだけでは古い値が返る可能性があります。
FLPは「実用的な合意が作れない」という意味ではない
完全非同期のモデルでは、クラッシュの可能性があると決定的な合意の終了を常には保証できません。Raftのランダム化は選挙競合を減らしますが、無期限の通信遅延まで解消しません。原論文は進行に必要なタイミングの条件を説明しており、ランダムな待ち時間だけで不可能性定理を無条件に回避するという説明は不正確です。
参考資料
確認日：2026年9月26日。製品の仕様・料金・対応環境は導入時にも確認してください。
-
Raft原論文: In Search of an Understandable Consensus Algorithm：選挙、過半数、現在の任期のコミット、安全性・進行条件。
-
Fischer・Lynch・Paterson原論文：非同期モデルと故障がある場合の終了保証の限界。