13. 理解しづらいことによる問題点
正しい Paxos が実装されない
そもそもどう実装すると正しくなるのか分からない
論文で語られていない詳細も多い
結果として、勘で実装した部分が正しいか保証できない
Multi-Paxos の実装すら同じものが存在しないレベル
Chubby も・・・
“There are significant gaps between the description of the Paxos
algorithm and the needs of a real-world system.... the final system will
be based on an un- proven protocol” (Paxos made live)
コンセンサスが正しく取れていることを仮定して構築されているシ
ステムの信頼性が崩壊!
13
21. Leader と Term
Raft 内では Term という論理時間が使われる
Term とは特定の Leader が連続して活動していた期間
Term には単調増加する ID が割り振られる
各 Term は Leader の選出から始まる
各 Term には 0 人か 1 人の Leader がいる
Leader がいなくなったら新しい Candidate が次の Term を開始
は Leader 選出期間
は通常稼働中の期間
21
Term 1 Term 2 T 3 Term 4
23. 投票開始
Current term number
各プロセスは current term number を持つ
Leader 、 Candidate のリクエストは current term number を含む
Current term number は新しい値を受け取る度に更新される
Follower は Candidate になったタイミングで、
1. 自身の Current term number を増やす
2. RequestVote RPC を全メンバに送信する
23
24. RequestVote API
引数
term: Candidate が観測している現在の term
candidateId: Candidate のクラスタ内での ID
lastLogIndex, lastLogTerm: ログレプリケーションのときに説明
Candidate が持つ情報の新しさを判定するために利用
Follower からの返値
term: Follower が観測している term
voteGranted: bool 値。 true なら Follower が投票したことを表す。
24
25. 投票と集計
Follower は一番最初に受け取った有効リクエストに対して投票する
ただし、後ほど安全性を保証するために条件を追加
Follower は 1 term で 1 回までしか投票しない
これにより 1 term で 1 Leader しか選出されない
Candidate はクラスタの半数以上から投票されたら Leader になる
自分は自分に投票する ( これも 1 term 1 回に含まれる )
25
Follower Candidate Leader
Start up
Times out,
starts election
Receives votes from
majority of servers
26. 投票終了
Leader になった Candidate はハートビートを全員に送信
Follower はハートビートを受け取ったら Leader の情報を更新
Candidate はハートビートを受け取ったら Follower に戻る
ただし、ハートビートの current term number が古かったら拒否!
そのまま Candidate の状態を維持
26
Follower Candidate Leader
Start up
Times out,
starts election
Receives votes from
majority of servers
Discovers the current
leader
27. 古い Leader 、 Candidate の扱い
Current term number を使って古い Leader 、 Candidate を検出
新しい current term number のリクエストを受け取ることで検知
Follower が Leader より新しい current term number を持つことも
通信障害などで、旧 Leader が知らない場所で新しい Leader が誕生
古い Leader や Candidate は、検出次第すぐに Follower に戻る
Follower は古い Leader や Candidate からのリクエストを拒否する
27
Follower Candidate Leader
Start up
Times out,
starts election
Receives votes from
majority of servers
Discovers a process
with higher term
Discovers the current
leader or new term
31. ログの持ち方
ログはすべて Leader からの AppendEntries RPC により複製される
31
1
x 3←
1
x 3←
1
x 3←
1
x 3←
1
x 3←
1
y 1←
1
y 1←
1
y 1←
1
y 1←
1
y 1←
1
y 9←
1
y 9←
1
y 9←
1
y 9←
2
x 2←
2
x 2←
2
x 2←
2
x 2←
3
x 0←
3
x 0←
3
x 0←
3
x 0←
3
y 7←
3
y 7←
3
y 7←
3
x 5←
3
x 5←
3
x 5←
3
x 4←
3
x 4←
1 2 3 4 5 6 7 8 log index
leader
followers
term number
(a)
(b)
(c)
(e)
(f)
32. AppendEntries RPC
引数
term: Leader の term number
leaderId: Leader のクラスタ内での ID
prevLogIndex, prevLogTerm: 1 個古いエントリのバージョン情報
entries[]: ログエントリ ( 配列 ) 、空だと heartbeat
leaderCommit: Leader がコミット済みの index number
返値
term: Follower が観測している term number
success: prevLogIndex/Term が一致したかどうか
false だったら古いログの再送が必要
もしくは Leader が古くなってる
32
63. Replicated State Machine のスナップショット
ハッシュテーブルを利用した簡単なインメモリ KVS を考える
オペレーション : キーに値を設定
内部表現 : JSON のオブジェクトみたいなもの
63
x 3 y 1 y 9 x 2 x 0 y 7 x 5
last included index: 5
last included term: 3
{
x: 0
y: 9
}
1 2 3 4 5 6 7
y 7 x 5
6 7
Index 5 の段階で取ったスナップショット
+ 残りのログ
元ログ
64. スナップショットとログ
スナップショットを取ったところまでのログは消せる
スナップショットに index/term number を含める
term number は consistency check で使われる
スナップショットのその他の使われ方
障害復旧後や、新規参入したプロセスを追いつかせる処理
ログだけだと復旧できないのでスナップショットを転送
InstallSnapshot RPC
64