Raft 状態遷移図

3状態と遷移を引き起こす3つの引き金

Raft では、クラスタ内の各ノードが常に Follower・Candidate・Leader のいずれか1つの状態にいます。状態の全体像と詳しい合意の原理は分散合意アルゴリズム（Paxos / Raft）で扱いました。本稿はその続きとして、どの条件でどの状態へ移るのかという遷移そのものを精密に追います。

まず押さえるべきは、状態を切り替える引き金が次の3種類しかないことです。

• 選挙タイムアウト（election timeout）: 一定時間 Leader から有効な通信が来ないと発火する。
• 過半数の獲得（majority vote）: Candidate が floor(N/2)+1 票を集めた瞬間に発火する。
• より大きい term の観測: 自分の term より大きい term を持つメッセージを見た瞬間に発火する。

この3つだけで、Raft の全遷移が説明できます。逆に言えば、ここに当てはまらない理由で勝手に状態が変わることはありません。

状態遷移の全分岐

各状態を起点に、どの引き金でどこへ向かうかを一覧にします。

注目点は、Leader からの遷移先が Follower しか無いことです。Leader が Candidate に直接戻る経路はありません。一度 Leader になったノードは、より新しい term を見て降格するか、自分が落ちるまで Leader であり続けます。

起動から定常までの順序

ノードが起動してからの流れを、時系列で追います。

1. 全ノードは Follower として起動する。Leader も Candidate もいない初期状態。
2. どの Follower も Leader からの心拍を受けないため、最初にタイムアウトしたノードが Candidate へ。term を 0→1 に上げ、自分に1票投じ、全ノードへ RequestVote(term=1) を送る。
3. 他ノードは「同じ term でまだ誰にも投票していなければ賛成」という規則（1 term 1票）に従い投票する。
4. Candidate が過半数の票を集めれば Leader へ昇格。直ちに空の AppendEntries（心拍）を送り、自分が Leader だと全員に知らせる。
5. 心拍を受けた他ノードは Follower のままタイマーをリセットし、定常状態に入る。

起動直後の選挙（N=3, 過半数=2）
全員 Follower
   │ 最初に election timeout したノードX
   ▼
X: Candidate (term 0→1, 自分に1票)
X ──RequestVote(term=1)──▶ Y, Z
Y, Z: この term で未投票 → 賛成
X: 2票（自分+Y）= 過半数 → Leader 確定
X ──AppendEntries(heartbeat)──▶ Y, Z
Y, Z: Follower のままタイマーリセット

選挙が決着しないときの再選挙ループ

票が割れた場合の遷移が、状態遷移図でつまずきやすい点です。Candidate は3つの結末を持ちます。

• 過半数を得る → Leader へ昇格。
• 別 Leader を見つける（同等以上の term の AppendEntries を受信）→ Follower へ降格。
• どちらも起きないまま再びタイムアウト → term を更に+1してもう一度 Candidate として選挙をやり直す。

3番目が「Candidate → Candidate」の自己ループです。これは無限ループに見えますが、タイムアウトがランダム化されているため、繰り返すうち最初に立候補した1ノードだけが他より早く動く確率が高まり、いずれ過半数が成立して抜け出します。

スプリットボートと再選挙
term=2: A も B も同時に Candidate
A → A,? の票, B → B,? の票  （3台目が割れる/未着）
どちらも過半数(2)未満 → 両者タイムアウト
A: term 2→3 で再立候補（ランダムに先んじる）
A が過半数 → Leader、B は A の心拍で term=3 を観測し Follower へ

Leader の定常動作：心拍とログ複製は同じ経路

Leader になったノードの動作は、状態遷移を「維持する」働きと「データを進める」働きを1つのメッセージ AppendEntries に統合している点が要点です。

• 空の AppendEntries = 心拍。Follower のタイマーをリセットし、選挙タイムアウトの発火を防いで Leader の地位を保つ。
• エントリ入りの AppendEntries = ログ複製。クライアントのコマンドをログ末尾に追記して送り、過半数に複製された時点でコミットとする。

つまり Leader は「自分の正当性の維持」と「ログの前進」を別チャネルに分けず、同じ仕組みで回します。Follower 側から見れば、有効な AppendEntries が届く限りタイマーは切れず、状態は Follower のまま安定します。ログ複製の整合規則（Log Matching）の詳細は分散合意アルゴリズム（Paxos / Raft）を参照してください。コミット済みエントリを耐久化する先行書き込みの考え方は先行書き込みログ（WAL）と地続きです。

定常状態のログ複製
Client ──command──▶ Leader
Leader: ログ末尾に (term, index, command) を追記
Leader ──AppendEntries(entries=[...])──▶ Followers
Followers: 直前エントリの (term, index) が一致 → 追記しACK
Leader: 過半数のACK → そのindexを committed に
Leader: 状態機械に適用しClientへ結果返却（次の心拍でcommitIndexを伝搬）

なぜ Leader → Candidate の直接遷移が無いのか

この非対称性は安全性の帰結です。Leader が「自分は古いかもしれない」と疑う唯一の根拠は、より大きい term の観測です。そしてより大きい term を観測したノードは、定義上まず Follower に戻って term を同期しなければなりません。Candidate になるには改めて選挙タイムアウトを待つ必要があり、いきなり立候補はできません。

もし Leader が Follower を経ずに Candidate へ飛べると、term の同期前に新たな選挙を始めてしまい、古い情報のまま二重 Leader を生むリスクが出ます。「降格は必ず Follower 経由」という制約が、term 同期を強制し、安全性を守っています。

まとめ