Raftとは？ 仕組みから考える得意なこと苦手なこと/What is Raft? Strengths and Weaknesses Based on Its Mechanism

Findy さんの大規模データベース移行の技術的チャレンジと実践例 ( https://findy.connpass.com/event/320871/ ) にて登壇した際の資料になります。

この登壇ではデータベースの移行そのものではないものの、Raftの動作についての解説を行い、Raftへの理解を深め、Raftの得意な部分と苦手なワークロードを理解することで、Raftを用いたNewSQLの運用やトラブルを未然に防ぐことを目的としています。

スライド内に動画が使われている部分があり、スライド内では閲覧いただくことはできません。
以下にURLを掲載します。

https://drive.google.com/file/d/1XbJWAKTabMQJqrPPWn6LNi1IYA6omfGh/view?usp=sharing
https://drive.google.com/file/d/1Eu8rRDMxl3LQy6KM6MRuJrvhobe3AF9c/view?usp=sharing

-- 追記--

> termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？
https://x.com/11Takanori/status/1801212885873602681

termは必ずしもリーダーを示すものではなく、また票割れや投票前の段階ではリーダーを指すとは限りません。

Raftの論文では
> Terms are numbered with consecutive integers.
といっており、リーダーかどうかは問いません

> log indexは単にlog entriesの中の当該logの位置を示すものなので、「今のリーダー」に言及しないほうが良さそう

https://x.com/komamitsu_tw/status/1801250356221104497
ログインデックスは今のリーダーにおけるものを指すわけではないため、正確には「何個目の命令か」となります。

-- 追記おわり--

Transcript

1. Raftとは？ 仕組みから考える得意なこと/苦手なこと 2024/06/13 大規模データベース移行の技術的チャレンジと実践例 btj.systems合同会社 @bootjp / ぶーと
2. 今日のアジェンダ • この発表の目的 • 自己紹介 • Raft？ • なぜRaftが必要なのか ◦ Two Phase Commitでいいじゃん！ ◦ Jepsen Testとは ◦ Jepsen Testが破壊してきたDBたち • Raftがこのような問題に対して何をしてくれるのか ◦ 自動フェイルオーバー（リーダー障害時の自動リーダー選出） ◦ データの自動同期（ログレプリケーション） ◦ 一貫性の維持や分断に対する耐性 • Raftの仕組み（ざっくり） ◦ リーダー選出 ◦ ログレプリケーション(ログの複製) ◦ 安全性 • Raftの得意と不得意 2
3. この発表の目的 多くのNewSQLデータベースがRaftを採用しています。 本日はそのRaftの概要をご説明します。 Raftがどのように動作するかを理解することで、得意なワー クロードと苦手なワークロードを把握することが目的です。 また、仕組みを知ることで発生しうるトラブルを事前に予測 することも目的です。 3
4. 自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp 上田義明 btj.systems合同会社 代表社員 4
5. 自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp btj.systems合同会社 代表社員 5 全然「ブトジシステム」って読めないです が、そのように登記されています。 変な名前で登記すると電話の時に困るので よくないですよ！（実体験） @bootjp 上田義明
6. 自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp btj.systems合同会社 代表社員 6 @bootjp 上田義明
7. Raft？ • 昨今のNewSQLや一部のKVSで使われている分散合意アルゴリズム ◦ TiDB（MySQL互換のRDBMS） ◦ CockroachDB（PostgreSQL互換のRDBMS） ◦ YugabyteDB（PostgreSQL/Cassandra互換のRDBMS） ◦ RQLite（SQLiteをRaftでレプリケーションするもの） ◦ etcd（Kubernetesのコントールプレーンなどで使われる） ◦ Consul（hashicorp社製のサービスディスカバリなどを行う） • Raftがやってくれること（後でしっかり説明します） ◦ 自動フェイルオーバー ◦ いい感じのデータのレプリケーション ◦ 一貫性を保ってくれる • なぜRaftが使われているんでしょうか？ 7
8. Raftを使ったデータベース？ • TiDB ◦ MySQL互換のDB • CockroachDB ◦ PostgreSQL互換 • YugabyteDB ◦ PostgreSQL/Cassandra互換 • RQLite • etcd • Consul 8
9. なぜRaftが必要なのか？ そもそもなぜRaftが必要なのでしょうか？ • Two Phase Commitではだめなのか？ • Jepsen Test ◦ Redis Sentinel の事例 ◦ MongoDB v3 の事例 9
10. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 10 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
11. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 11 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
12. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 12 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
13. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 13 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
14. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 14 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
15. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 15 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
16. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 16 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
17. なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 17 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
18. なぜRaftが必要なのか？＞Jepsen Test 18 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料
19. なぜRaftが必要なのか？＞Jepsen Test • Jepsen Test ◦ オープンソースのテストフレームワーク ◦ 分散システムの一貫性と信頼性を検証 ◦ 検証内容 ▪ ネットワークパーティション • 意図的にネットワークを分断させて、分断時の動作を確認する ▪ クラッシュ • ノードやプロセスを意図的にクラッシュさせる • クラッシュ時やクラッシュからの復帰時に不整合がないかをみる ▪ クロックスキュー • 意図的に時刻ずらす • ノードの時刻が正しいことに依存しているシステムを洗い出す ◦ 意図的に故障を起こし故障時の一貫性や耐障害性を検証する 19
20. なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 20 引用元: 本当は恐ろしい分散システム の話 https://www.docswell.com/s /kumagi/K24LXG-dreadful-di stributed-systems 2017年10月 当時の資料 2017年10月 当時の資料
21. なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 21 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4
22. なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 22 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4
23. なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 23 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4
24. ここまでのまとめ • Two Phase Commit による不整合が起きるケース • Jepsen Testの結果 ◦ Redis Sentinelのネットワーク分断によるデータロスト ◦ write concernが過半数未満の場合のMongoDB3系のデータロスト • ここからは以下を説明します ◦ Raftがこのような問題に対して何をしてくれるのか ◦ Raftがどのように動くか ◦ Raftが得意なこと/苦手なこと 24
25. Raftはなにをしてくれるのか • Raftは以下の機能を提供します。 ◦ 自動フェイルオーバー ◦ データの自動同期 ◦ 一貫性の維持や分断に対する耐性 25
26. Raftはなにをしてくれるのか • Raftは以下の機能を提供します。 ◦ 自動フェイルオーバー ▪ ノードがクラッシュしても自動でリカバリーする ◦ データの自動同期 ▪ Raftではログレプリケーションと言います。 ▪ アプリケーションログとは違いStateMachineへの命令です。 ◦ 一貫性の維持や分断に対する耐性 ▪ リーダーを必ず経由するモデルを取ることで一貫性を維持している • 例えば、各ノードの時刻を用いて命令を並び変えると時刻のズレが問 題になる ◦ それ以外にも通信のラグとかもある • ネットワーク分断時にも過半数のノードが存在する側が動く 26
27. Raftの仕組み（ざっくり）> 用語 • ノードの役割は3つ ◦ リーダー(leader) ▪ クライアントからのリクエストを受け取るノード ▪ フォロワーに命令を送信するノード ◦ フォロワー(follower) ▪ リーダーからの命令を受け取るノード ▪ 主に可用性や冗長化のために存在する ◦ 候補者（Candidate) ▪ リーダー候補 ▪ リーダーからのハートビートが届かなかった場合に遷移する ▪ 候補者になる時にtermをインクリメントする • ターム（term） ◦ 今のリーダーが何代目のリーダーかを表す • ログ・インデックス ◦ 今のリーダーにおける何個目の命令かを示す 27
28. Raftの仕組み（ざっくり）> 用語 • コミットインデックス(commit index) ◦ リーダーがコミットした最新のログエントリのインデックスを示す。 ▪ コミットには過半数のノードへの保存が必要 28
29. Raftの仕組み（ざっくり）> リーダー選出 • リーダーは1つしか選出されない ◦ 2つ以上になることはない ◦ 1つもいないことはある ▪ リーダーがクラッシュし、新たなリーダー選出されるまで • 選出の流れ（次のスライドにアニメーションがあります） ◦ 選挙タイムアウト ▪ ハートビートを受け取るとタイムアウトはリセットされる ◦ 候補者の立候補 ▪ 自らのtermを一つ増やし、自分に投票した上で他のノードに投票を求める ◦ 投票 ▪ 他のノードは以下を満たす場合に投票する • そのtermで投票をしていない • 候補者のtermが自分以上 • 候補者のログが自分と同じかより新しい 29
30. Raftの仕組み（ざっくり）> リーダー選出 30 引用元: Raft - The Secret Lives of Data https://thesecret livesofdata.com/r aft/
31. Raftの仕組み（ざっくり）＞ログレプリケーション 31 引用元: Raft - The Secret Lives of Data https://thesecret livesofdata.com/r aft/
32. Raftの得意と不得意 • 得意 ◦ 強い一貫性（強整合性）の維持 ◦ ノードのクラッシュやクラッシュ後の復帰に対する安全性 ◦ ネットワーク分断の環境下での正常な動作 32
33. Raftの得意と不得意 • 苦手 ◦ レイテンシー ▪ 過半数のノードの書き込みを待つため ▪ 合意形成のための通信オーバーヘッドが大きい ◦ スケーラビリティ/スループット ▪ リーダーノードが処理できる上限値 = スケーラビリティの上限 ▪ これの対策として、データを分割し分割範囲毎にRaftを立てる • 時間があれば解説します（多分ない） ◦ リーダー障害時の可用性の低下 ▪ 新しいリーダーが選出されるまで、データの読み書きができない時間が生 じる 33
34. まとめ • 分散システムは難しい • Two Phase Commitや不十分なレプリケーションはデータが消えうる • Raftは以下の機能を達成してくれる ◦ 自動フェイルオーバー（リーダー障害時の自動リーダー選出） ◦ データの自動同期（ログレプリケーション） ◦ 一貫性の維持 ◦ ネットワーク分断に対する耐性 • Raftは以下ことが苦手 ◦ 小さなレイテンシーでレスポンスを返すこと ◦ スループットが要求される時 ▪ これに対する改善としてMultiRaftやParallelRaft • TiDBやCockroachDB ◦ リーダー障害時の可用性の低下 34
35. • In Search of an Understandable Consensus Algorithm (Extended Version) ◦ https://raft.github.io/raft.pdf • kumagi: 分散システムについて語らせてくれ ◦ https://www.docswell.com/s/kumagi/ZXYYLN-let-me-talk-about-distributed-system • kumagi: 本当は恐ろしい分散システムの話 ◦ https://www.docswell.com/s/kumagi/K24LXG-dreadful-distributed-systems • MongoDB 3.6.4 ◦ https://jepsen.io/analyses/mongodb-3-6-4 • Raft - The Secret Lives of Data ◦ https://thesecretlivesofdata.com/raft/ 出典 35
36. 質疑応答 36
37. Multi-Raftの図 37