NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意

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

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

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

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

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 プリンシパル分散システムエンジニア

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

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

13 Raft？ • NewSQLやKVSで採用されている分散合意アルゴリズム ◦ TiDB（MySQL互換のRDBMS） ◦ CockroachDB（PostgreSQL互換のRDBMS） ◦ YugabyteDB（PostgreSQL/Cassandra互換のRDBMS）
◦ RQLite（SQLiteをRaftでレプリケーションするもの） ◦ etcd（Kubernetesのコントールプレーンなどで使われる） ◦ Consul（hashicorp社製のサービスディスカバリなどを行う） • 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月当時の資料

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の得意と不得意

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

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

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

NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意

NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意

More Decks by hacomono Inc.

Other Decks in Technology

Featured

Transcript