etcdとRaftアルゴリズム: Kubernetes Control Planeの信頼性の解剖 / etcd and raft algorithm

2023/12/11 に行われた CNDT2023 「etcdとRaftアルゴリズム: Kubernetes Control Planeの信頼性の解剖」で使用したスライドです。

Transcript

1. etcdとRaftアルゴリズム: Kubernetes Control Planeの信頼性の解剖 @shukawam/@ystkfujii 1
2. 2 Shuhei Kawamura(X: @shukawam) Job: CSP - Cloud Architect (Cloud Native, AuthNZ, AI/ML) ひとこと: 早く雪山にこもりたい Yoshitaka Fujii(X: @ystkfujii) Job: 何でも屋（Terraform/k8s/Golang) ひとこと: 来年のガンダムの映画が楽しみ
3. はじめに 3 ▪ 目標 ▫ RaftとetcdにおけるRaft実装を”完全理解”すること ▪ 話すこと ▫ Raftとはなにか ▫ etcdのRaftの実装を読む ▪ 話さないこと ▫ etcdのRaft以外の実装
4. Kubernetes Components 4 … Control Plane Node Node 参考: https://kubernetes.io/ja/docs/concepts/overview/components
5. Kubernetes Components 5 … Control Plane Node Node 参考: https://kubernetes.io/ja/docs/concepts/overview/components
6. What is etcd? ▪ 分散システムの最も重要なデータのための信頼性の高いKVS ▫ Simple - 明確に定義されたユーザー向けのAPI(gRPC) ▫ Secure - (optional)クライアント証明書認証による自動TLS ▫ Fast - 10,000 writes/secの書き込み ▫ Reliable - Raftを用いた適切な分散 ▪ Kubernetesでは全てのクラスター情報の保存場所として利用 6 参考: https://github.com/etcd-io/etcd
7. 7 引用: https://github.com/etcd-io/etcd
8. Replicated state machines 8 ▪ 分散システムで障害耐性を持つために、同じ状態(State)のマシンを複 製(Replicated)するアプローチのこと ▪ 各State machineが実行するべき一連のコマンド（ログ）を複製すること で同じ状態を複製する ▪ コンセンサス・アルゴリズムは、複製されたログの一貫性を保つ
9. 9 引用: https://github.com/etcd-io/etcd Replicated state machines
10. What is Raft? ▪ コンセンサス・アルゴリズムの一種（Raft, Paxos, …） ▪ Paxosと比べ耐障害性や性能を維持しつつ、理解しやすいよう設計 ▪ 採用されている代表的なサービス／プロダクト ▫ etcd, Kafka(KRaft), CockroachDB, … 10
11. Raft basics ▪ 各ノードは、Leader, Follower, Candidateいずれかの役割を持つ ▪ 主な動作は2つだけ ▫ Leader election（リーダー選挙） - RequestVote RPC ▫ Log replication（ログ複製） - AppendEntries RPC ▪ Raftクラスタは奇数台(3, 5, 7)のノード構成を推奨 ▫ 偶数台／奇数台の場合で障害許容ノード数は変わらないが、障害 耐性が下がるため ▫ 参考: https://etcd.io/docs/v3.6/faq/#what-is-failure-tolerance 11
12. Leader election - Term ▪ 任意の長さに分割された時間のこと ▪ Termは選挙で始まり、最大で1つのLeaderがいることを保証する 12 引用: https://raft.github.io/raft.pdf
13. Leader election - State transition ▪ 各ノードは、Leader, Follower, Candidateいずれかの役割を持つ ▫ 起動直後 → Follower ▫ 選挙開始 → Candidate ▫ 選挙勝利 → Leader 13 引用: https://raft.github.io/raft.pdf
14. Leader election flow 14 Candidate Follower F F Leader RequestVote RPC Increment Term Starts election Vote myself voteGranted: true win!! Become Leader AppendEntries RPC
15. Leader election flow 15 Candidate Follower F F Leader Increment Term Starts election Vote myself voteGranted: true win!! Become Leader RequestVote RPC AppendEntries RPC
16. 16 RequestVote RPC term 候補者のTerm candidateId 投票をリクエストしている候補者 lastLogIndex 候補者の最後のログエントリのインデックス lastLogTerm 候補者の最後のログエントリのターム term currentTerm、候補者が自分自身を更新する voteGranted 候補者が票を得た場合 true Arguments: Results: 引用: https://raft.github.io/raft.pdf
17. 17 AppendEntries RPC - 1/2 term リーダーのTerm leaderId リーダーのID prevLogIndex 新しいエントリの直前のログエントリのインデックス prevLogTerm prevLogIndex のターム entries[] 保存するログエントリ （ハートビートの場合は空 ; 効率のために複数送信も可） leaderCommit リーダーのcommitIndex Arguments: 引用: https://raft.github.io/raft.pdf
18. 18 term currentTerm、リーダーが自分自身を更新する success フォロワーがprevLogIndexとprevLogTermに一致するエント リを含んでいた場合は true Results: AppendEntries RPC - 2/2 引用: https://raft.github.io/raft.pdf
19. Log replication ▪ Leader → FollowerへLogを複製し、各Followerはそれらを順序通りに 処理し、その実行結果をクライアントに返す ▫ Logの複製には、AppendEntries RPCが用いられる 19 引用: https://raft.github.io/raft.pdf
20. 20 Log replication flow Client Leader F F Messages Append to local log entries AppendEntries RPC success: true Commit log entries AppendEntries RPC w/ Leader committed index Success
21. 21 Cluster membership changes オンラインでクラスターの構成変更を実施する上での考慮事項 ▪ 移行中の同一タームに2人のリーダーが選出されてはならない ▪ Raftでは、2段階の合意プロセスで構成移行を実施 ▫ Phase1. 新旧両方の構成を組み合わせた構成に移行 ▫ Joint Consensus ▫ Phase2. 新しい構成に移行 ▪ 安全性の観点から、一度に1つのサーバーしかクラスタに追加、削除で きないようにRaftでは制限を設けている
22. 22 Cluster membership changes flow A(Leader) C D B AppendEntries RPC Config of {old, new} success: true 新旧全てのノードに 構成変更ログを複製 新旧構成ともに 過半数の合意 AppendEntries RPC Config of {new} success: true 新構成から 過半数の同意 Phase 1 C_old ↓ C_old, new Phase 2 C_old, new ↓ C_new C_old = {A, B, C}, C_new = {A, B, C, D}
24. 24 ▪ 対象のバージョンはetcd v3.5.10 ▪ 細かい点は省いています ▪ コードに修正を加えている部分があります 諸注意
25. Raftの立ち位置 25 Client Write Workflow MVCC: Multi-Version Concurrency Control MVCC Write Ahead Log BoltDB EtcdServer Raft １：書き込みリクエスト ２：Raftにフォワード ７：コミットを通知 ８：DBへの書き込み ６：コミット ３：WALに書き込み Raft Write Ahead Log Raftのコアロジックをライブラリとして分離 • 受け取ったリクエストに対する処理 • Peerへの依頼内容 • コミット管理　など EtcdServer ３：Peerへ書き込み依頼 ５：書き込み完了報告 ４：WALに書き込み（６の後にコミット
26. Basic action 26 ▪ etcdのノードがどのStateなのか？ ▪ そのStateの処理は何か？ ▪ その処理のトリガーは何か？
27. Basic action: Which state ? 27 ▪ Nodeの状態はraft構造体のstateで管理されている ▪ becomeXXX関数でstateを変更する 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
28. Basic action: Processing of state 28 ▪ 定期実行の処理　-> 　tickXXX関数 ▪ State毎の処理　 -> 　stepXXX関数 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
29. Basic action: Processing of state 29 ▪ 定期実行の処理　-> 　tickXXX関数 ▪ State毎の処理　 -> 　stepXXX関数 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
30. Basic action: Message 30 ▪ MessageはNodeへの入力をまとめた もの ▫ 種類/送付先/エントリーなど ▪ MessageTypeの使い分け ▫ MsgProp　　 : ログ追加の提案 ▫ MsgVote　　 : 投票要求 ▫ MsgVoteResp: 投票要求への応答 など 参考: https://pkg.go.dev/go.etcd.io/raft/v3#hdr-MessageType
31. Basic action: Triggers for processing 31 Message Receive Run loop If Message Appears Send Message To Peers Step Func Tick Func If Ready ? Yes No 参考: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/node.go#L300
32. Basic action: Summary 32 Leader Candidate Follower becomeFollower becomeCandidate becomeLeader becomeCandidate stepFollower stepCandidate stepLeader tickElection tickHeartbeat tickElection 定期的に実行 Message受信で実行
33. Leader election flow 33 Candidate Follower F F Leader RequestVote RPC Increment Term Starts election Vote myself voteGranted: true win!! Become Leader AppendEntries RPC
34. Vote myself win!! voteGranted: true Leader election flow 34 Follower F F Leader Increment Term RequestVote RPC Become Leader Candidate Starts election
35. Leader election: Candidate Side 35 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
36. Leader election: Candidate Side 36 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go Candidateになる
37. Leader election: Candidate Side 37 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go 投票者のIDでループ
38. Leader election: Candidate Side 38 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go MsgVoteを投票者に送付 実際には、msgsにappendされるのみ
39. Leader election: Candidate Side 39 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go 投票結果を集計
40. Leader election: Candidate Side 40 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go 勝てば 負ければ Followerになる Leaderになる VotePendingの場合は何もしない
41. Become Leader Leader election flow 41 Candidate Follower Leader Increment Term Starts election Vote myself win!! AppendEntries RPC RequestVote RPC voteGranted: true F F
42. Leader election: Follower side 42 まだ誰にも投票していないかつリーダーが分からない場合 デフォルトはStateFuncの実行 送付元が投票先の場合 投票しない 投票する 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
43. Leader election flow 43 Candidate Follower F F RequestVote RPC Increment Term Starts election Vote myself voteGranted: true win!! Become Leader Leader AppendEntries RPC
44. Leader election: bcastAppend 44 ← toがここの場合 Followerのlogの状況を取得 引用: https://raft.github.io/raft.pdf
45. 45 Log replication flow Client Leader F F Messages Append to local log entries AppendEntries RPC success: true Commit log entries AppendEntries RPC w/ Leader committed index Success
46. Implementation for log replication 46 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go
47. Implementation for log replication 47 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go Followerに書き込まれた場合、 Leaderに転送
48. Implementation for log replication 48 参照: https://github.com/etcd-io/etcd/blob/v3.5.10/raft/raft.go Peerに送付 Entriesを追加 LeaderからのMessageでAppend
49. Summary 49 ▪ etcdの信頼性を担っているのはRaft ▪ Raftのアルゴリズムについて説明した ▪ 具体的な実装をetcdのコードベースで説明した
50. 50 FIN