リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力

by Tech Leverages

Slide 1

Slide 1 text

レバテック開発部ビジネスサポートグループ前原宗太朗リソース・管理効率の向上だけでない、分散システムとしてのTiDBの魅力

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

|　© 2024 Levtech Co., Ltd. 4 ❌ 話さないこと ● レバテックがなぜTiDBを導入したのか ○ 導入背景については「TiDB User Day 2024」にて発表されています ○ 内容をざっくりまとめると、マイクロサービス化によって増えたDBクラスターを効率的に管理するためにTiDBの導入したというお話 ○ 運用の管理負荷の軽減とリソースの効率化について特に触れられている今日話すこと・話さないこと

Slide 5

Slide 5 text

|　© 2024 Levtech Co., Ltd. 5 🟢 話すこと 1. TiDBがいかにして高可用性と耐障害性を実現しているのか 2. どうやって書き込みのスケーラビリティを実現しているか TiDBの魅力はリソース効率の向上や管理負荷の軽減の向上だけではない ● TiDBを支える裏側の仕組みには技術的な面白さがある ● 書き込み負荷の高いワークロードへの対応やトランザクション・分析クエリの両立など、他の魅力も多く存在するこの発表を通して少しでもTiDBに興味を持ってもらうのが目的今日話すこと・話さないこと

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

|　© 2024 Levtech Co., Ltd. 8 Storage Cluster TiDB Cluster TiDBのアーキテクチャの外観 TiDB TiDB TiDB TiKV TiKV TiKV PD Cluster Placement Driver Placement Driver Placement Driver TiKV TiKV TiKV TiKV TiKV TiKV PD Cluster Placement Driver Placement Driver Placement Driver メタデータ管理のコンポーネント様々な管理や制御を行い、クラスター全体の「頭脳」の役割を果たす

Slide 9

Slide 9 text

|　© 2024 Levtech Co., Ltd. 9 Storage Cluster TiDBのアーキテクチャの外観 TiDB Cluster TiDB TiDB TiDB TiKV TiKV TiKV PD Cluster Placement Driver Placement Driver Placement Driver TiKV TiKV TiKV TiKV TiKV TiKV TiDB Cluster TiDB TiDB TiDB ステートレスなSQLレイヤークエリの解析や最適化、実行などを行う

Slide 10

Slide 10 text

|　© 2024 Levtech Co., Ltd. 10 TiDB Cluster TiDBのアーキテクチャの外観 TiDB TiDB TiDB PD Cluster Placement Driver Placement Driver Placement Driver Storage Cluster TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiKV Storage Cluster TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiKV TiKV データの保存を担当複数のノードにデータを分散させ、自動でデータの同期を行う今日話すのは主にデータ分散と同期の部分

Slide 11

Slide 11 text

|　© 2024 Levtech Co., Ltd. 11 TiDBの特徴の１つとして99.99%の可用性と耐障害性しかし、99.99%の可用性と言われても。。。ピンとはこない世はまさに大クラウド時代多くのケースではクラウドプロバイダーが可用性を保証してくれるし、ミッションクリティカルなシステムでない限り、そこまで意識することは少ないかもクラウドが普及する前はどのようにして可用性をあげていた？ TiDBがいかにして高可用性と耐障害性を実現しているのか

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

|　© 2024 Levtech Co., Ltd. 17 1. データを複数のノードに分散させる ○ データを分散させることで単一障害点をなくす 2. ノード間でデータを安全に同期的に複製させる ○ 非同期ではタイミングによって、失われるデータが存在する 3. 障害時に自動で素早く安全にリカバリーする ○ ダウンタイムを最小限に抑えつつ、データの一貫性も保証するこれらを実現するために分散合意アルゴリズムが使われる可用性や耐障害性を向上させるための3つのポイント ☝ 分散合意アルゴリズムはKuberneteの裏側でも使われているよ

Slide 18

Slide 18 text

|　© 2024 Levtech Co., Ltd. 18 複数のノード間で一貫性のあるステートマシンを提供するためのアルゴリズム代表的なものにPaxosとRaftがあるすべてのノードが同じログを適用すれば、必ず同じ状態になると仮定している ⇨ State Machine Replication 分散合意アルゴリズムノード A { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態ノード B { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用 ☝ Paxosは難しいと言われており、シンプルを売りにしているのがRaft。現在はRaftが主流。

Slide 19

Slide 19 text

|　© 2024 Levtech Co., Ltd. 19 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるこれにより、過半数のノードさえ生きていれば、システムはデータの一貫性を保ちながら運用を続行できるいかにして高可用性と耐障害性を実現しているのか

Slide 20

Slide 20 text

|　© 2024 Levtech Co., Ltd. 20 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるこれにより、過半数のノードさえ生きていれば、システムはデータの一貫性を保ちながら運用を続行できるいかにして高可用性と耐障害性を実現しているのか日本語でおk

Slide 21

Slide 21 text

|　© 2024 Levtech Co., Ltd. 21 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 22

Slide 22 text

|　© 2024 Levtech Co., Ltd. 22 すべてのノードが同じログを適用すれば、必ず同じ状態になると仮定している一元管理されたログを配布するノード A { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態ノード B { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用

Slide 23

Slide 23 text

|　© 2024 Levtech Co., Ltd. 23 すべてのノードが同じログを適用すれば、必ず同じ状態になると仮定している一元管理されたログを配布するノード A { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態ノード B { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用これの順番を決めるノードが必要

Slide 24

Slide 24 text

|　© 2024 Levtech Co., Ltd. 24 ノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する一元管理されたログを配布するリーダー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態フォロワー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用これ通りに適用してな〜りょ

Slide 25

Slide 25 text

|　© 2024 Levtech Co., Ltd. 25 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 26

Slide 26 text

|　© 2024 Levtech Co., Ltd. 26 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 27

Slide 27 text

|　© 2024 Levtech Co., Ltd. 27 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 28

Slide 28 text

|　© 2024 Levtech Co., Ltd. 28 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できる ⇨ 過半数のノードが最新のログを持つことが保証するために、過半数が合意したログのみを確定とするいかにして高可用性と耐障害性を実現しているのか

Slide 29

Slide 29 text

|　© 2024 Levtech Co., Ltd. 29 ステートマシンを同期する流れリーダー２つのストレージを用いる raft ● ログを保存する役割 ● 命令とデータのセット kv ● 状態を保存する役割 raft kv フォロワー raft kv フォロワー raft kv { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga }

Slide 30

Slide 30 text

Slide 31

Slide 31 text

|　© 2024 Levtech Co., Ltd. 31 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv フォロワー raft kv 1-1 クライアントからのリクエスト 1-2 エントリーログの作成

Slide 32

Slide 32 text

|　© 2024 Levtech Co., Ltd. 32 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv フォロワー raft kv 2 ログをフォロワーに送信

Slide 33

Slide 33 text

|　© 2024 Levtech Co., Ltd. 33 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } 3-1 ログを自身のノードに保存 3-2 自身の状態と比較して問題なければOKを返す

Slide 34

Slide 34 text

|　© 2024 Levtech Co., Ltd. 34 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } 4 過半数から合意を得たらログを確定（コミット）させ適用の指示を送る

Slide 35

Slide 35 text

|　© 2024 Levtech Co., Ltd. 35 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } { Key = 1, name = hoge } { Key = 1, name = hoge } { Key = 1, name = hoge } 5-1 適用の指示後に自身のKV に状態を反映 5-2 適用の指示を受け取ると自身のKVに状態を反映

Slide 36

Slide 36 text

|　© 2024 Levtech Co., Ltd. 36 ステートマシンを同期する流れリーダー具体的な流れ 1. リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } フォロワー raft kv { PUT Key = 1, name = hoge } { Key = 1, name = hoge } { Key = 1, name = hoge } { Key = 1, name = hoge } 過半数ノードが最新のログを持っていることが保証される

Slide 37

Slide 37 text

|　© 2024 Levtech Co., Ltd. 37 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 38

Slide 38 text

|　© 2024 Levtech Co., Ltd. 38 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

Slide 39

Slide 39 text

|　© 2024 Levtech Co., Ltd. 39 1. 一元管理されたログを配布することで、すべてのノードを同じ状態にすることができる a. ログを一元管理するリーダーを選出し、リーダーがログの順序を決定する 2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できる ⇨ 障害時もログの一貫性を保つためにリーダー選びが重要いかにして高可用性と耐障害性を実現しているのか

Slide 40

Slide 40 text

|　© 2024 Levtech Co., Ltd. 40 障害時のリーダー選出前提過半数の合意が得られたデータしか確定しない過半数のノードには最新のログが存在する ⇨ 過半数のノードと一致するログを持っていれば、最新のログを持っているとしてリーダーになることできるリーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9

Slide 41

Slide 41 text

|　© 2024 Levtech Co., Ltd. 41 障害時のリーダー選出前提過半数の合意が得られたデータしか確定しない過半数のノードには最新のログが存在する ⇨ 過半数のノードと一致するログを持っていれば、最新のログを持っているとしてリーダーになることできるこの場合はフォロワー1と2がリーダーになることができるリーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 term1 1 2 3 4 5 term2 6 7 8 9 フォロワー 2

Slide 42

Slide 42 text

|　© 2024 Levtech Co., Ltd. 42 障害時のリーダー選出用語の説明ターム ● リーダーの任期を表す数値 ● 1つのタームでは、1人のリーダーしか存在しない ● リーダー選挙が行われるたびに、このタームの値が1つ増加するログインデックス ● 現在のログがどの位置まで進んでいるかを示す ● 新しいログが追加されるたびに、インデックスが 1つずつ増加するリーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9

Slide 43

Slide 43 text

|　© 2024 Levtech Co., Ltd. 43 障害時のリーダー選出リーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙

Slide 44

Slide 44 text

|　© 2024 Levtech Co., Ltd. 44 障害時のリーダー選出リーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 0 リーダーはフォロワーに対して一定間隔でハートビートを送っている

Slide 45

Slide 45 text

|　© 2024 Levtech Co., Ltd. 45 障害時のリーダー選出リーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 1-1 リーダーがクラッシュするとハートビートが途絶える

Slide 46

Slide 46 text

|　© 2024 Levtech Co., Ltd. 46 障害時のリーダー選出リーダーキャンディデートフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 1-2 フォロワーは各自election timeoutを持っており、タイムアウトを検知するとキャンディデートとして立候補する

Slide 47

Slide 47 text

|　© 2024 Levtech Co., Ltd. 47 障害時のリーダー選出リーダーキャンディデートフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 1-3 候補者は自分に一票を入れた上で、他のフォロワーに自分に投票してくださいとリクエストを送る。その際にtermを一つ進めるリクエストにはタームとログインデックスを含める term: 2 index: 9 term: 2 index: 9 term: 2 index: 9

Slide 48

Slide 48 text

|　© 2024 Levtech Co., Ltd. 48 障害時のリーダー選出リーダーキャンディデートフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 term: 2 index: 9 RequestVote 2 フォロワーはタームとログインデックスを比較して、自分と同じか最新のログを持っていると判断できた場合は投票を行う投票投票投票

Slide 49

Slide 49 text

|　© 2024 Levtech Co., Ltd. 49 障害時のリーダー選出リーダーリーダーフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙投票投票 3-1 過半数の投票をもらうとリーダーに昇格する投票

Slide 50

Slide 50 text

|　© 2024 Levtech Co., Ltd. 50 障害時のリーダー選出リーダーリーダーフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 3-2 新しいリーダーはリーダーになったことをフォロワーに通知する最新のエントリに追いついていないフォロワーがいた場合はログの再送を行う 9 8 term2 6 7 8 9 term2 6 7

Slide 51

Slide 51 text

|　© 2024 Levtech Co., Ltd. 51 障害時のリーダー選出リーダーキャンディデートフォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 キャンディデート term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 4-1 たまたまタイムアウトのタイミングが被ってしまうと候補者が複数発生して票が割れることがある ☝ 実際は衝突を軽減するためにランダムなタイムアウトを割り当てているよ投票投票

Slide 52

Slide 52 text

|　© 2024 Levtech Co., Ltd. 52 障害時のリーダー選出リーダーフォロワー 1 フォロワー 3 フォロワー 4 term1 1 2 3 4 5 term2 6 7 8 9 term1 1 2 3 4 5 term2 6 7 term2 6 7 8 term2 6 7 8 9 term1 1 2 3 4 5 term1 1 2 3 4 5 フォロワー 2 term1 1 2 3 4 5 term2 6 7 8 9 具体的な流れ 1. リーダーのダウンを検知したフォロワーがキャンディデートとして立候補 2. フォロワーが、自分と同じか新しいログを持つ候補者にのみ投票 3. 過半数の投票を得たキャンディデートがリーダーに昇格 4. 票が割れた場合は再選挙 4-2 タームを更新して全員がフォロワーに戻る複数の立候補者がでにくいようにランダムでタイムアウトを割り当てる timeout: 150ms timeout: 130ms timeout: 170ms timeout: 180ms

Slide 53

Slide 53 text

|　© 2024 Levtech Co., Ltd. 53 前半まとめ過半数の合意が得られたデータしか確定しない ⇨ 確定したデータは過半数の合意を得ていることを保証できる耐障害性はどうやって保証しているのか？ ⇨ 過半数のノードと一致するログを持つノードをリーダーに選出することで、障害時もログの一貫性を保証することができるリーダーの選出は自動で素早く行われるため、運用負荷なしに高い可用性と耐障害性を手に入れることができる ☝ コミット->適用の間に障害が起きたらとか、クラッシュしたリーダーが復帰したら？など細かい話もあるけど、今日は割愛！

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

|　© 2024 Levtech Co., Ltd. 63 ノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する一元管理されたログを配布するリーダー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態フォロワー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用これ通りに適用してな〜りょノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する

Slide 64

Slide 64 text

|　© 2024 Levtech Co., Ltd. 64 ノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する一元管理されたログを配布するリーダー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態フォロワー { PUT Key = 1, name = hoge } { PUT Key = 2, name = fuga } { PUT Key = 1, name = piyo } { Key = 1, name = piyo } { Key = 1, name = fuga } ログ状態適用適用これ通りに適用してな〜りょノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する ⇨ 全ての処理はリーダーに依存する

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

|　© 2024 Levtech Co., Ltd. 67 Storage Cluster Multi Raft Group TiDB では、データを「リージョン」という細かい単位に分割し、リージョンごとにリーダーを割り当てる TiKV node 1 Region 1 Region 3 Region 4 Region n ・・・ Region 2 TiKV node 3 Region 3 Region 4 Region n ・・・ TiKV node 4 Region 1 Region 2 Region 4 Region n ・・・ Region 3 TiKV node 2 Region 1 Region 2 Region n ・・・

Slide 68

Slide 68 text

|　© 2024 Levtech Co., Ltd. 68 Multi Raft Group TiDB では、データを「リージョン」という細かい単位に分割し、リージョンごとにリーダーを割り当てる ● 1つのノードに書き込み負荷が集中せず、書き込みをスケールさせることができる ○ シャーディングと同様の考え方 ● ノード間でデータの同期が保証されているため、実現できるリージョンにデータはどうやって割り当てる？

Slide 69

Slide 69 text

|　© 2024 Levtech Co., Ltd. 69 Multi Raft Group TiDB では、データを「リージョン」という細かい単位に分割し、リージョンごとにリーダーを割り当てる ● 1つのノードに書き込み負荷が集中せず、書き込みをスケールさせることができる ○ シャーディングと同様の考え方 ● ノード間でデータの同期が保証されているため、実現できるリージョンにデータはどうやって割り当てる？ ⇨ Placement Driverの出番

Slide 70

Slide 70 text

|　© 2024 Levtech Co., Ltd. 70 Multi Raft Group Placement Driverの役割 ● リージョンの分割とマージ ○ リージョンには上限のサイズ（デフォルトは96 MiB）が決められている ○ あるリージョンのサイズが上限を超える場合、自動でリージョンを分割する ○ 逆に、データ量が少なくなりすぎたリージョンをマージさせる場合もある ● ホットスポットの回避 ○ クラスタ全体の負荷状況をモニタリングし、特定ノードへ負荷が集中しないように管理 ○ リーダーの再配置や、リージョンの配置換えを行い、ホットスポットを分散する

Slide 71

Slide 71 text

|　© 2024 Levtech Co., Ltd. 71 後半まとめどうやって書き込みのスケーラビリティを実現しているか ● データを「リージョン」という細かい単位に分割し、リージョンごとにリーダーを割り当てる Multi Raft Groupを採用 ○ 書き込みのノードを分散させることで書き込みの負荷を分散させている ● Placement Driverによるデータの再配置(スプリット・マージ）とホットスポット回避のためのバランシングによって、自動でスケーリングを実現

Slide 72

Slide 72 text

|　© 2024 Levtech Co., Ltd. 72 他にもあるよ！TiDBの魅力 ● 分散アルゴリズムを支えるストレージ要件 ○ 耐障害性 (WAL, LSM-Tree)、読み込み最適化 (Bloom Filter, Block Cache) ● 分散トランザクション (MVCC + Percolator) ○ 大量の並行処理が可能な二段階コミット方式を採用し、整合性を確保 ● HTAP 構成 ○ TiFlash(列指向ストレージ) とのリアルタイム同期 ○ DeltaTreeで書き込み性能と圧縮効率を両立 ○ MPPによる大規模分析クエリの高速化なんとPingCap公式で無料で公開されている！

Slide 73

Slide 73 text

|　© 2024 Levtech Co., Ltd. 73 まとめ TiDBがいかにして高可用性と耐障害性を実現しているのか ● 分散合意アルゴリズムによって、一度確定したデータは過半数の合意を得ていることが保証される ● 過半数のノードと一致するログを持つノードをリーダーに選出することで、障害発生時もログの一貫性を維持できる ● リーダーの選出は自動で素早く行われるため、運用負荷をかけずに高可用性と耐障害性を確保できるどうやって書き込みのスケーラビリティを実現しているか ● データを「リージョン」という細かい単位に分割し、リージョンごとにリーダーを割り当てる Multi Raft Groupを採用 ○ 書き込みのノードを分散させることで書き込みの負荷を分散させている ● Placement Driverによるデータの再配置(スプリット・マージ）とホットスポット回避のためのバランシングによって、自動でスケーリングを実現