合意アルゴリズム
分散システムでの一貫性を保証する仕組み
合意アルゴリズムは、複数のノードが障害やネットワーク分断があっても同じ値に合意するための仕組み。分散システムの一貫性を保証する基盤技術。
リーダー選出
1. 通常時: リーダーがリクエストを処理
👑
Leader
→ replicate→ replicate
Follower
Follower
2. リーダー障害発生
💥
Leader Down
✕ no heartbeat✕ no heartbeat
Follower?
Follower?
3. 新リーダー選出（投票）
⬜
Old Leader
← vote← vote
New Leader 👑
Follower
Raft アルゴリズム
Raftは理解しやすさを重視した合意アルゴリズム。 etcd、Consul、CockroachDBなどで採用。
ノードの3つの状態
Follower
受動的に複製
timeout
→
Candidate
投票を要求
過半数獲得
→
Leader
ログを複製
ログ複製の流れ
1クライアントがLeaderに書き込みリクエスト
2Leaderがログエントリを追加
3Followerにログを複製（AppendEntries RPC）
4過半数が応答したらコミット
5クライアントに成功を返す
Quorum（定足数）
Quorum = 過半数のノードの合意。 N個のノードで (N/2)+1 以上の合意が必要。
3ノード
Quorum = 2
1障害まで許容
5ノード
Quorum = 3
2障害まで許容
7ノード
Quorum = 4
3障害まで許容
なぜ奇数？偶数だとスプリットブレインのリスク。3ノードと4ノードの耐障害性は同じ（1障害）。
主な実装
etcd
Kubernetes のバックエンドストア。Raftベース。 キーバリューストア、Watch機能。
ZooKeeper
Apache製。ZAB（Paxos派生）ベース。 Kafka、Hadoop等で使用。
Consul
HashiCorp製。Raftベース。 サービスディスカバリ、KVストア。
CockroachDB
分散SQL DB。Raftベース。 強い一貫性を持つNewSQL。
SRE/インフラ観点
クラスタ構成
- • 本番は最低3ノード（推奨5ノード）
- • 異なるAZ/ラックに配置
- • 偶数ノードは避ける
監視項目
- • リーダー選出の頻度（頻繁は問題のサイン）
- • コミットレイテンシ
- • Followerの遅延
- • ディスク使用量（WALログ）
注意点
- • ネットワーク遅延が性能に直結
- • ディスクI/Oが重要（SSD推奨）
- • スプリットブレインの防止設定を確認