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

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

|　© 2024 Levtech Co., Ltd. 2 レバテック開発部前原宗太朗 SOTARO
MAEHARA 2022年6月入社レバテック開発部ビジネスサポートグループバックエンドエンジニア出身: 鹿児島言語: C++/Go/Python/TypeScript/PHP/Rust 趣味: League of Legends adcメインのp3

|　© 2024 Levtech Co., Ltd. 3 MySQL互換を謳うオープンソースのNew SQLデータベース特徴 •
99.99%の可用性と耐障害性 • 書き込みを含めた水平方向の拡張性 • トランザクション・分析クエリの両方をサポートするHTAP構成の実現 TiDBとは

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

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

|　© 2024 Levtech Co., Ltd. 7 TiDBのアーキテクチャの外観 Storage Cluster TiDB
Cluster TiDB TiDB TiDB TiKV TiKV TiKV PD Cluster Placement Driver Placement Driver Placement Driver TiKV TiKV TiKV TiKV TiKV TiKV

|　© 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 メタデータ管理のコンポーネント様々な管理や制御を行い、クラスター全体の「頭脳」の役割を果たす

|　© 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レイヤークエリの解析や最適化、実行などを行う

|　© 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 データの保存を担当複数のノードにデータを分散させ、自動でデータの同期を行う今日話すのは主にデータ分散と同期の部分

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

|　© 2024 Levtech Co., Ltd. 12 アプリケーションが、データベースに対してデータの読み書きを行うシチュエーションクラウドが普及する前の話 Master
読み書き

|　© 2024 Levtech Co., Ltd. 13 マスター・スレーブの構成をとって、リーダーがダウンした時にはスレーブを昇格させるクラウドが普及する前の話通常時
Replicate Master Slave 読み書き

|　© 2024 Levtech Co., Ltd. 14 マスター・スレーブの構成をとって、リーダーがダウンした時にはスレーブを昇格させるクラウドが普及する前の話 Replicate
Master Slave 障害時 Clash!

|　© 2024 Levtech Co., Ltd. 15 マスター・スレーブの構成をとって、リーダーがダウンした時にはスレーブを昇格させるクラウドが普及する前の話 Replicate
Master Slave ⇩ Master 障害時 Clash! 読み書き

|　© 2024 Levtech Co., Ltd. 16 耐障害性 • 非同期レプリケーションになるため、マスターのコミット ≠
スレーブへの適用が保証されるわけではない • 障害時にスレーブが最新データを保持していない可能性があるダウンタイム • スレーブ昇格時に数十秒のダウンタイム発生運用負荷 • 構成によっては手動でフェールオーバーが必要問題点

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

|　© 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が主流。

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

2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるこれにより、過半数のノードさえ生きていれば、システムはデータの一貫性を保ちながら運用を続行できるいかにして高可用性と耐障害性を実現しているのか日本語でおk

2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できるいかにして高可用性と耐障害性を実現しているのか

|　© 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 } ログ状態適用適用

|　© 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 } ログ状態適用適用これの順番を決めるノードが必要

|　© 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 } ログ状態適用適用これ通りに適用してな〜りょ

2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できる ⇨ 過半数のノードが最新のログを持つことが保証するために、過半数が合意したログのみを確定とするいかにして高可用性と耐障害性を実現しているのか

|　© 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 }

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

リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv フォロワー raft kv 1-1 クライアントからのリクエスト 1-2 エントリーログの作成

リーダーがエントリーログの作成 2. リーダーがログをフォロワーへ送信 3. フォロワーがログの保存と検証、合意 4. リーダーがログをコミットし適用の指示 5. リーダー、フォロワーがログを適用 raft kv { PUT Key = 1, name = hoge } フォロワー raft kv フォロワー raft kv 2 ログをフォロワーに送信

リーダーがエントリーログの作成 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を返す

リーダーがエントリーログの作成 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 過半数から合意を得たらログを確定（コミット）させ適用の指示を送る

リーダーがエントリーログの作成 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に状態を反映

リーダーがエントリーログの作成 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 } 過半数ノードが最新のログを持っていることが保証される

2. リーダーが故障して交代する場合でも、過半数が合意したログのみを確定とすることで、一貫したログの確定が行われる 3. 過半数のノードが最新のログを持つことが保証されるので、リーダー故障時でも過半数の同意を得られる新しいリーダーを選び、継続してログを更新できる ⇨ 障害時もログの一貫性を保つためにリーダー選びが重要いかにして高可用性と耐障害性を実現しているのか

|　© 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

|　© 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

|　© 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

|　© 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. 票が割れた場合は再選挙

フォロワー 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 リーダーはフォロワーに対して一定間隔でハートビートを送っている

フォロワー 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 リーダーがクラッシュするとハートビートが途絶える

|　© 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を持っており、タイムアウトを検知するとキャンディデートとして立候補する

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

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 フォロワーはタームとログインデックスを比較して、自分と同じか最新のログを持っていると判断できた場合は投票を行う投票投票投票

|　© 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 過半数の投票をもらうとリーダーに昇格する投票

|　© 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

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 たまたまタイムアウトのタイミングが被ってしまうと候補者が複数発生して票が割れることがある ☝ 実際は衝突を軽減するためにランダムなタイムアウトを割り当てているよ投票投票

フォロワー 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

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

99.99%の可用性と耐障害性 • 書き込みを含めた水平方向の拡張性 • トランザクション・分析クエリの両方をサポートするHTAP構成の実現 TiDBとは（再掲）

|　© 2024 Levtech Co., Ltd. 59 書き込みはプライマリーにしかできないため、書き込みを行うクライアントが増えた時にプライマリーがボトルネックになる書き込みのスケールは難しい Primary
Replicate Read Replica

|　© 2024 Levtech Co., Ltd. 60 書き込みを分散させるためにシャーディングという手法があるが、アプリケーションで制御するため、運用の負荷が高い書き込みのスケールは難しい Primary
Primary ID: 1~1000 ID: 1001~2000 ☝ シャーディングの方法にも色々あるよ！この例ではレンジベースのシャーディング

{ 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 } ログ状態適用適用これ通りに適用してな〜りょノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する

{ 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 } ログ状態適用適用これ通りに適用してな〜りょノードをリーダーとフォロワーに分けて、リーダーがログの順序を決定するフォロワーは順番通りにログを適用する ⇨ 全ての処理はリーダーに依存する

|　© 2024 Levtech Co., Ltd. 66 Raftとスケーラビリティ Raft単体では書き込みのスケーラビリティは実現できない ⇨ 全ての処理がリーダーに依存するため
リーダーに依存するのであればリーダーを増やせばいいじゃないの〜 ⇨ Multi Raft Group

|　© 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 ・・・

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

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

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

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

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

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

|　© 2024 Levtech Co., Ltd. 74 最後に TiDBは、一見するとすごい技術で、その中身を知らないとまるで魔法のように見えますしかし、その実態は先人たちが、数々の課題を乗り越えてきた知識の積み重ねになります仕組みを学び、理解することで、私たちも「魔法のように」問題を解決する手段を手に入れるこ
とができますこの発表が、TiDBの内部構造に興味を持つきっかけになれば嬉しいです

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

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

More Decks by Tech Leverages

Featured

Transcript