Raftとは？ 仕組みから考える得意なこと/苦手なこと 2024/06/13 大規模データベース移行の技術的チャレンジと実践例 btj.systems合同会社 @bootjp / ぶーと

今日のアジェンダ ● この発表の目的 ● 自己紹介 ● Raft？ ● なぜRaftが必要なのか ○ Two Phase Commitでいいじゃん！ ○ Jepsen Testとは ○ Jepsen Testが破壊してきたDBたち ● Raftがこのような問題に対して何をしてくれるのか ○ 自動フェイルオーバー（リーダー障害時の自動リーダー選出） ○ データの自動同期（ログレプリケーション） ○ 一貫性の維持や分断に対する耐性 ● Raftの仕組み（ざっくり） ○ リーダー選出 ○ ログレプリケーション(ログの複製) ○ 安全性 ● Raftの得意と不得意 2

この発表の目的 多くのNewSQLデータベースがRaftを採用しています。 本日はそのRaftの概要をご説明します。 Raftがどのように動作するかを理解することで、得意なワー クロードと苦手なワークロードを把握することが目的です。 また、仕組みを知ることで発生しうるトラブルを事前に予測 することも目的です。 3

自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp 上田義明 btj.systems合同会社 代表社員 4

自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp btj.systems合同会社 代表社員 5 全然「ブトジシステム」って読めないです が、そのように登記されています。 変な名前で登記すると電話の時に困るので よくないですよ！（実体験） @bootjp 上田義明

自己紹介 HN: ぶーと 中学生の頃にレンタルサーバー事業を立ち 上げ、その後、数社を経てSupership株式 会社や株式会社プレイドで大量のリクエス トを低レイテンシーで効率的に処理するア プリケーションの開発に携わってきまし た。 現在はbtj.systems合同会社を立ち上げ、 Raftベースの分散ストレージを開発してい ます。 最近、技術書典16で「Go言語で作って理解 する Raftベース Redis互換KVS」という書 籍を執筆しました。 @bootjp btj.systems合同会社 代表社員 6 @bootjp 上田義明

Raft？ ● 昨今のNewSQLや一部のKVSで使われている分散合意アルゴリズム ○ TiDB（MySQL互換のRDBMS） ○ CockroachDB（PostgreSQL互換のRDBMS） ○ YugabyteDB（PostgreSQL/Cassandra互換のRDBMS） ○ RQLite（SQLiteをRaftでレプリケーションするもの） ○ etcd（Kubernetesのコントールプレーンなどで使われる） ○ Consul（hashicorp社製のサービスディスカバリなどを行う） ● Raftがやってくれること（後でしっかり説明します） ○ 自動フェイルオーバー ○ いい感じのデータのレプリケーション ○ 一貫性を保ってくれる ● なぜRaftが使われているんでしょうか？ 7

Raftを使ったデータベース？ ● TiDB ○ MySQL互換のDB ● CockroachDB ○ PostgreSQL互換 ● YugabyteDB ○ PostgreSQL/Cassandra互換 ● RQLite ● etcd ● Consul 8

なぜRaftが必要なのか？ そもそもなぜRaftが必要なのでしょうか？ ● Two Phase Commitではだめなのか？ ● Jepsen Test ○ Redis Sentinel の事例 ○ MongoDB v3 の事例 9

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 10 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 11 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 12 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 13 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 14 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 15 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 16 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Two Phase Commitでいいじゃん！ 17 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Jepsen Test 18 引用元: 分散システムについて語らせ てくれ https://www.docswell.com/s /kumagi/ZXYYLN-let-me-talk -about-distributed-system 2017年08月の資料 2017年08月 当時の資料

なぜRaftが必要なのか？＞Jepsen Test ● Jepsen Test ○ オープンソースのテストフレームワーク ○ 分散システムの一貫性と信頼性を検証 ○ 検証内容 ■ ネットワークパーティション ● 意図的にネットワークを分断させて、分断時の動作を確認する ■ クラッシュ ● ノードやプロセスを意図的にクラッシュさせる ● クラッシュ時やクラッシュからの復帰時に不整合がないかをみる ■ クロックスキュー ● 意図的に時刻ずらす ● ノードの時刻が正しいことに依存しているシステムを洗い出す ○ 意図的に故障を起こし故障時の一貫性や耐障害性を検証する 19

なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 20 引用元: 本当は恐ろしい分散システム の話 https://www.docswell.com/s /kumagi/K24LXG-dreadful-di stributed-systems 2017年10月 当時の資料 2017年10月 当時の資料

なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 21 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4

なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 22 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4

なぜRaftが必要なのか？＞Jepsen Testが破壊してきたDBたち 23 引用元: Jepsen: MongoDB 3.6.4 https://jepsen.io/analyses /mongodb-3-6-4

ここまでのまとめ ● Two Phase Commit による不整合が起きるケース ● Jepsen Testの結果 ○ Redis Sentinelのネットワーク分断によるデータロスト ○ write concernが過半数未満の場合のMongoDB3系のデータロスト ● ここからは以下を説明します ○ Raftがこのような問題に対して何をしてくれるのか ○ Raftがどのように動くか ○ Raftが得意なこと/苦手なこと 24

Raftはなにをしてくれるのか ● Raftは以下の機能を提供します。 ○ 自動フェイルオーバー ○ データの自動同期 ○ 一貫性の維持や分断に対する耐性 25

Raftはなにをしてくれるのか ● Raftは以下の機能を提供します。 ○ 自動フェイルオーバー ■ ノードがクラッシュしても自動でリカバリーする ○ データの自動同期 ■ Raftではログレプリケーションと言います。 ■ アプリケーションログとは違いStateMachineへの命令です。 ○ 一貫性の維持や分断に対する耐性 ■ リーダーを必ず経由するモデルを取ることで一貫性を維持している ● 例えば、各ノードの時刻を用いて命令を並び変えると時刻のズレが問 題になる ○ それ以外にも通信のラグとかもある ● ネットワーク分断時にも過半数のノードが存在する側が動く 26

Raftの仕組み（ざっくり）> 用語 ● ノードの役割は3つ ○ リーダー(leader) ■ クライアントからのリクエストを受け取るノード ■ フォロワーに命令を送信するノード ○ フォロワー(follower) ■ リーダーからの命令を受け取るノード ■ 主に可用性や冗長化のために存在する ○ 候補者（Candidate) ■ リーダー候補 ■ リーダーからのハートビートが届かなかった場合に遷移する ■ 候補者になる時にtermをインクリメントする ● ターム（term） ○ 今のリーダーが何代目のリーダーかを表す ● ログ・インデックス ○ 今のリーダーにおける何個目の命令かを示す 27

Raftの仕組み（ざっくり）> 用語 ● コミットインデックス(commit index) ○ リーダーがコミットした最新のログエントリのインデックスを示す。 ■ コミットには過半数のノードへの保存が必要 28

Raftの仕組み（ざっくり）> リーダー選出 ● リーダーは1つしか選出されない ○ 2つ以上になることはない ○ 1つもいないことはある ■ リーダーがクラッシュし、新たなリーダー選出されるまで ● 選出の流れ（次のスライドにアニメーションがあります） ○ 選挙タイムアウト ■ ハートビートを受け取るとタイムアウトはリセットされる ○ 候補者の立候補 ■ 自らのtermを一つ増やし、自分に投票した上で他のノードに投票を求める ○ 投票 ■ 他のノードは以下を満たす場合に投票する ● そのtermで投票をしていない ● 候補者のtermが自分以上 ● 候補者のログが自分と同じかより新しい 29

Raftの仕組み（ざっくり）> リーダー選出 30 引用元: Raft - The Secret Lives of Data https://thesecret livesofdata.com/r aft/

Raftの仕組み（ざっくり）＞ログレプリケーション 31 引用元: Raft - The Secret Lives of Data https://thesecret livesofdata.com/r aft/

Raftの得意と不得意 ● 得意 ○ 強い一貫性（強整合性）の維持 ○ ノードのクラッシュやクラッシュ後の復帰に対する安全性 ○ ネットワーク分断の環境下での正常な動作 32

Raftの得意と不得意 ● 苦手 ○ レイテンシー ■ 過半数のノードの書き込みを待つため ■ 合意形成のための通信オーバーヘッドが大きい ○ スケーラビリティ/スループット ■ リーダーノードが処理できる上限値 = スケーラビリティの上限 ■ これの対策として、データを分割し分割範囲毎にRaftを立てる ● 時間があれば解説します（多分ない） ○ リーダー障害時の可用性の低下 ■ 新しいリーダーが選出されるまで、データの読み書きができない時間が生 じる 33

まとめ ● 分散システムは難しい ● Two Phase Commitや不十分なレプリケーションはデータが消えうる ● Raftは以下の機能を達成してくれる ○ 自動フェイルオーバー（リーダー障害時の自動リーダー選出） ○ データの自動同期（ログレプリケーション） ○ 一貫性の維持 ○ ネットワーク分断に対する耐性 ● Raftは以下ことが苦手 ○ 小さなレイテンシーでレスポンスを返すこと ○ スループットが要求される時 ■ これに対する改善としてMultiRaftやParallelRaft ● TiDBやCockroachDB ○ リーダー障害時の可用性の低下 34

● 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

Multi-Raftの図 37