Last Update 2022.03.16 仕組みを理解して知る得意不得意 db tech showcase 2025 LT9 NewSQLや分散データベースを支える Raftの仕組み 

2 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

3 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

4 ● 多くのNewSQLや分散データベースでRaftが採用されています。 ● Raftの仕組みを知ることは次のメリットがあります。 ○ Raftを用いた分散データベースの... ■ 内部の仕組みについて詳しくなれる（非ブラックボックス化） ■ 得意なワークロードを知る ■ 苦手なワークロードを知る ● 本発表を聞き終わったときに以下を目指します ○ Raftについて一定の理解 ○ Raftを使ったデータベースの制約について知る ○ Raftの特性について理解し、分散データベースを運用に活かせる この発表の目的 

5 この発表は以下のスライドとほぼ同じです。 本日の発表は、以前私が登壇した資料を手直ししているものとなっております。 こちらの内容をご存知の方は、重複した内容となることをご了承ください。 

6 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

7 自己紹介 経歴（前略） ○ 2018年~2021年: Supership株式会社 　スマホ向け大量配信システムの開発/運用 　検索・検索連動広告 開発/運用 ○ 2021年~2023年: 株式会社プレイド 　大量配信システムの刷新 　分散システム周りの相談窓口 ○ 2023年~2024年: btj.systems合同会社 　RaftベースのElasticsearch互換検索エンジンの作成 ○ 2024年~: 株式会社hacomono プリンシパル分散システムエンジニア マイクロサービス化のための共通システムを設計/開発 @bootjp 上田義明 株式会社hacomono プリンシパル分散システム エンジニア 

8 自己紹介 経歴（前略） ○ 2018年~2021年: Supership株式会社 　スマホ向け大量配信システムの開発/運用 　検索・検索連動広告 開発/運用 ○ 2021年~2023年: 株式会社プレイド 　大量配信システムの刷新 　分散システム周りの相談窓口 ○ 2023年~2024年: btj.systems合同会社 　RaftベースのElasticsearch互換検索エンジンの作成 ○ 2024年~: 株式会社hacomono プリンシパル分散システムエンジニア マイクロサービス化のための共通システムを設計/開発 @bootjp 上田義明 株式会社hacomono プリンシパル分散システム エンジニア 

9 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

10 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー・ ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール ウェルネス施設の手続きをすべてデジタル化 ウェルネス産業を、新次元へ。 

9,500店舗・施設での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング 

12 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

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

14 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

15 なぜRaftが必要なのか？ ● Tho Phase Commitはダメ？ ● Jepsen Test ○ Redis Sentinel の事例 

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

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

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

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

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

26 なぜRaftが必要なのか？＞ Jepsen Test ● Jepsen Test ○ オープンソースのテストフレームワーク ○ 分散システムの一貫性と信頼性を検証 ○ 意図的に故障を起こし故障時の一貫性や耐障害性を検証する ○ 検証内容 ■ ネットワークパーティション ● 意図的にネットワークを分断させて、分断時の動作を確認する ■ クラッシュ ● ノードやプロセスを意図的にクラッシュさせる ● クラッシュ時やクラッシュからの復帰時に不整合がないかをみる ■ クロックスキュー ● 意図的に時刻ずらす ● ノードの時刻が正しいことに依存しているシステムを洗い出す ■ 壊れたファイルシステム 本日はLTのため、 ここを深堀りすることはできません が、興味がありましたら 「分散システムにおける一貫した時 刻の取り扱いの課題と解決策」につ いて書いた記事もご覧ください。 

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

31 ここまでのまとめ ● Two Phase Commit による不整合が起きるケースがある ● Jepsen Testの結果 ○ Redis Sentinelのネットワーク分断によるデータロスト ● ここからは以下を説明します ○ Raftはなにをしてくれるのか？ ○ Raftの仕組み（ざっくり） ○ Raftの得意と不得意 

32 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

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

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

38 今日のアジェンダ ● この発表の目的 ● 自己紹介 ● 弊社についての紹介 ● Raft？ ● なぜRaftが必要なのか ● Raftはなにをしてくれるのか？ ● Raftの仕組み（ざっくり） ● Raftの得意と不得意 

39 Raftの仕組み（ざっくり） > 用語 ● ノードの役割は3つ ○ リーダー(leader) ■ クライアントからのリクエストを受け取るノード ■ フォロワーに命令を送信するノード ○ フォロワー(follower) ■ リーダーからの命令を受け取るノード ■ 主に可用性や冗長化のために存在する ○ 候補者（candidate) ■ リーダー候補者 ■ リーダーからのハートビートが届かなかった場合に遷移する 

40 Raftの仕組み（ざっくり） > 用語 ● ターム（term） ○ 論理時計、単調増加する数値、投票が行われる際に増加する ● ログ・インデックス（log index） ○ 単調増加するログのインデックスを示す数値 ○ ターム+ログ・インデックスで一意のログを示すことができる ● コミットインデックス（commit index） ○ ログ・インデックスがどこまでコミット済みかを示す ■ コミットには過半数のノードへの保存が必要 

41 Raftの仕組み（ざっくり） > リーダー選出 ● リーダーは必ず1つしか選出されない ○ 2つ以上になることはない ○ 1つもいないことはある ■ リーダーがクラッシュし、新たなリーダー選出されるまでの間 ■ リーダー選出までの間Raftはリーダー選出以外を行えない 

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

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

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

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

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

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

48 ● 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-syst em ● 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/ 出典 

ご清聴いただき ありがとうございました 49 

Multi-Raftの図 50