Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

● 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

Slide 36

Slide 36 text

質疑応答 36

Slide 37

Slide 37 text

Multi-Raftの図 37