Slide 1

Slide 1 text

2024/05/08 Oracle Cloud Hangout Cafe Season 8 #4 CockroachDB は どのくらい「しぶとい」のか? #ochacafe \ コンニチハ /

Slide 2

Slide 2 text

Name: こたつ&&みかん Account: @kota2and3kan Company: Name: Scalar, Inc Product: - ScalarDB (Distributed Transaction Manager) - ScalarDL (Byzantine Fault Detection Middleware) Job: [Technical Support, Infra Engineer] Like: DB: [PostgreSQL, CockroachDB] Bouldering: 5Q Dislike: Real Cockroach Who am I.

Slide 3

Slide 3 text

※Note※ ちょっと自信が無いとこもあります!間違ってたらごめんさな い!!! また、説明を簡略化するために一部詳細を省略 / 抽象化して表現 している箇所があります!!! \ ユルシテ /

Slide 4

Slide 4 text

みなさん CockroachDB 触ったことあり ますか? \ ボクト アクシュ /

Slide 5

Slide 5 text

CockroachDB は... \ I am… /

Slide 6

Slide 6 text

名前とロゴがヤバい分散 SQL データベース https://github.com/cockroachdb/cockroach

Slide 7

Slide 7 text

What is CockroachDB? (公式の FAQ から抜粋) CockroachDB is a distributed SQL database built on a transactional and strongly-consistent key-value store. It scales horizontally; survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention; supports strongly-consistent ACID transactions; and provides a familiar SQL API for structuring, manipulating, and querying data. https://www.cockroachlabs.com/docs/stable/frequently-asked-questions.html#what-is-cockroachdb

Slide 8

Slide 8 text

今日は CockroachDB の 「しぶとさ (耐障害性 / Survivability)」 についてお話します。 \ シブトイ /

Slide 9

Slide 9 text

CockroachDB Overview \ ガイヨウ /

Slide 10

Slide 10 text

論理的に 1つの DB Node 1 Node 3 Cluster overview (3匹の場合) Node 2 ● 分散 DB なので、複数 Node で構成された Cluster で動作する。

Slide 11

Slide 11 text

どのようにデータを持っているのか \ データ /

Slide 12

Slide 12 text

データの格納 ● RDBMS なのでユーザか らは TABLE に見える。

Slide 13

Slide 13 text

データの格納 ● RDBMS なのでユーザか らは TABLE に見える。 ● TABLE は Key-Value 形 式に変換される。

Slide 14

Slide 14 text

データの格納 ● RDBMS なのでユーザか らは TABLE に見える。 ● TABLE は Key-Value 形 式に変換される。 ● Key-Value は 512MB に 分割される (Range)。 Range Range Range

Slide 15

Slide 15 text

データの格納 ● RDBMS なのでユーザか らは TABLE に見える。 ● TABLE は Key-Value 形 式に変換される。 ● Key-Value は 512MB に 分割される (Range)。 ● 各 Range を分散して 各 Node に格納する。 k1 ~ k10 k11 ~ k20 k21 ~ k30 Range Range Range

Slide 16

Slide 16 text

データの格納 ● RDBMS なのでユーザか らは TABLE に見える。 ● TABLE は Key-Value 形 式に変換される。 ● Key-Value は 512MB に 分割される (Range)。 ● 各 Range を分散して 各 Node に格納する。 ● Raft を使って Replica も 作成される (デフォルト 3 つ)。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Range Range Range Raft Group 1 Raft Group 2 Raft Group 3

Slide 17

Slide 17 text

5匹に増えた場合 ● いい感じにスケールアウトすることも可能。 ● スケールした場合、データは自動でいい感じに分散される。 ● スケールインすることも可能。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica

Slide 18

Slide 18 text

どうやって Read / Write するのか \ ヨミカキ /

Slide 19

Slide 19 text

Read / Write の仕組み (全ての Node が Coordinator) k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Tx1: Write (k15, v1) Tx2: Read (k3) Tx3: Write (k28, v2) Tx4: Read (k5) Tx5: Write (k12, v3) ● Cluster 内の Node 間に 役割の差異はない。 ● 全ての Node が Coordinator として動作 することが可能。 ● つまり、全ての Node で Read / Write の Tx を処 理可能。

Slide 20

Slide 20 text

k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Tx1: Write (k15, v1) Tx3: Write (k28, v2) ● CockroachDB では、 Coordinator Node のこと を Gateway Node と呼 ぶ。 ● Gateway Node は、処理 対象の key を持っている Node に、クエリをルー ティングする。 Read / Write の仕組み (全ての Node が Coordinator)

Slide 21

Slide 21 text

k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Tx1: Write (k15, v1) Tx3: Write (k28, v2) ● データの Read / Write は Raft の Leader で実 行される。 ● CockroachDB では、 Read / Write ができる Replica (≒ Raft Leader) のことを Leaseholder と呼ぶ。 Read / Write の仕組み (全ての Node が Coordinator)

Slide 22

Slide 22 text

k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Tx: Read (k3) Write (k15, v2) Write (k27, v3) ● Tx 内に複数の Read / Write がある場合、 Gateway Node はそれ ぞれのデータを持ってい る Node に各クエリを ルーティングする。 ● いい感じの仕組みを使っ て、Atomicity (All or Nothing) を担保してい る。 Read / Write の仕組み (全ての Node が Coordinator)

Slide 23

Slide 23 text

k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Tx: Write (k5, v2) ● Write の場合は、Raft を 使った Replica への Replication が完了して から、Client へ COMMIT OK を返す。 Read / Write の仕組み (全ての Node が Coordinator)

Slide 24

Slide 24 text

Survivability (本題) \ サバイブ /

Slide 25

Slide 25 text

単一 Node 障害発生時の動作 \ クラッシュ /

Slide 26

Slide 26 text

正常時 (5匹) ● 正常時は各 Range のデータ (Replica) をそれぞれの Node がいい感じに分散し て保持している。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ゴヒキ /

Slide 27

Slide 27 text

● 障害が発生して、Node が 1匹いなくなる。 \ サヨナラ / 障害発生 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica ~ \ アトハマカセロ / \ サラバダ... /

Slide 28

Slide 28 text

4匹に減少 ● Node が 1匹減少すると、一時的に Range の Replica や Leaseholder が足りな い状態になる。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica \ タリナイ... /

Slide 29

Slide 29 text

4匹に減少 (Leaseholder が消えてしまった場合) ● 障害が発生していた Node が Leaseholder (≒ Raft の Leader) を保持していた 場合、一時的に Read / Write ができなくなる。 ● 図の場合、”k11 ~ k20” のデータに対する Read / Write ができなくなる。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica \ デキナイ... /

Slide 30

Slide 30 text

4匹に減少 (Leaseholder が消えてしまった場合) ● Leaseholder (≒ Raft の Leader) が存在しなくなってしまった場合、生き残った Replica のどれかが新しく Leaseholder (≒ Raft の Leader) になる。 k1 ~ k10 Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ マカセロ /

Slide 31

Slide 31 text

4匹に減少 (Replica が消えてしまった場合) ● Replica 数が足りない場合は、他の Node からデータをコピーして Cluster 内の Replica 数 (デフォルト 3つ) を保つ。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ マカセロ / \ タノム /

Slide 32

Slide 32 text

4匹に減少 (自動での対処完了) ● 障害発生に伴い Node 数が減ってしまった場合であっても、Leaseholder や Replica の数が保たれるようになっている。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ヨンヒキ / \ デモ / \ ウゴク / \ ヨ! /

Slide 33

Slide 33 text

4匹に減少 ● このようにして、障害発生時でもユーザー影響を最小限にしつつ、Cluster としては 動作し続けることができる。 ● もちろん、ここから Node 数を元に戻すことも可能。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ チラッ /

Slide 34

Slide 34 text

5匹に復旧 ● 障害が発生した Node を復旧させる、もしくは新しい Node を追加することで、5匹 構成に戻すことも可能。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ コンニチハ /

Slide 35

Slide 35 text

5匹に復旧 ● 5匹構成に戻った場合、他の Node からいい感じに Replica が分散される動作に なる。 ● この動作はスケールアウト (新しい Node を追加) する時も同様。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica Replica Replica \ マカセロ /

Slide 36

Slide 36 text

5匹に復旧 ● 最終的に 5匹構成、かつデータがいい感じに分散された状態に復旧することができ る。 k1 ~ k10 Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica Replica \ フッカツ /

Slide 37

Slide 37 text

複数 Node の同時障害 \ ドウジ /

Slide 38

Slide 38 text

複数 Node の同時障害 ● Raft では過半数の Node が生きていれば処理を継続できる (Cluster 構成が “2N + 1” Node 構成の場合 “N node” の障害に耐えられる)。 ● そのため、5匹構成の Cluster であれば、一見すると 2匹障害までなら耐えられる ように見えるかもしれない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ゴヒキ /

Slide 39

Slide 39 text

● しかし、CockroachDB では、Node 単位ではなく Range 単位で Raft を利用した Replication が実行されている。 ● つまり、実際に「何 Node 障害まで耐えられるか」は Replica 数に依存するので、 注意が必要。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 \ Replica = 3 ! /

Slide 40

Slide 40 text

● 例えば、図のような構成の場合において、右側の 2匹で障害が発生すると、”k1 ~ k10” の Replica 数が “1” になってしまう (過半数を割ってしまう) ため、”k1 ~ k10” のデータに対する Read / Write はできなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) ~ ~ \ デキナイ... /

Slide 41

Slide 41 text

● 加えて、Range の Replica 数が「過半数を割った」場合、残った Replica を使って 新しい Replica を作ることは「しない」仕組みになっている。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 \ リカバリシナイ /

Slide 42

Slide 42 text

● この図の場合、”k11 ~ k20” の Range と “k21 ~ k30” の Range のデータについて は、通常通り復旧 (Leaseholder への昇格と不足した Replica の追加が実行) さ れる。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 Replica k21 ~ k30 \ リカバリ /

Slide 43

Slide 43 text

● しかし、”k1 ~ k10” の Range のデータは自動的には復旧されず、Read / Write で きない状態のままになる。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 Replica k21 ~ k30 \ ソノママ /

Slide 44

Slide 44 text

● この動作は、Node 数をさらに増やした場合でも変わらない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) \ ナナヒキ /

Slide 45

Slide 45 text

● 例えば、7匹構成の Cluster の場合であっても、Replica 数が 3 の場合は、右端の 2匹で同時に障害が発生すると、”k1 ~ k10” の Replica 数が “1” になってしまう (過半数を割ってしまう) ため、”k1 ~ k10” のデータに対する Read / Write はできな くなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) ~ ~ \ デキナイ... /

Slide 46

Slide 46 text

● そのため、Survivability を上げるためには、Node 数だけでなく、Replica 数も増や す必要がある。 ● Replica 数については、設定で変更することができる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (5 Replica) Replica Replica Replica Replica Replica Replica \ Replica = 5 ! /

Slide 47

Slide 47 text

● Replica 数が 5 であれば、2匹同時に障害が発生しても、最低 3つの Replica が 残る (過半数は残る)。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (5 Replica) Replica Replica Replica Replica Replica Replica \ ゴヒキ ダケド... / ~ ~

Slide 48

Slide 48 text

● そのため、通常の復旧処理が実行され、引き続き全てのデータの Read / Write が できる状態が保たれる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (5 Replica) Replica Replica Replica Replica Replica Replica \ マダ ダイジョウブ / Replica Replica Replica Replica Replica

Slide 49

Slide 49 text

何故 Replica 数が過半数を割ると復旧 処理が実行されないのか? \ Why…? /

Slide 50

Slide 50 text

● (ドキュメント上で明確な記載を確認できていないので) あくまで推測ではあるが、こ の「Range の Replica が過半数を割ると自動的には復旧されない」という動作は、 恐らく Split Brain を避けるためのものであると考えられる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (Split Brain 対策)

Slide 51

Slide 51 text

● ある Node における「何等かの問題」を検知した場合であっても、他の Node から その問題の原因を明確に知ることはできない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica ~ 複数 Node の同時障害 (Split Brain 対策) \ サヨナラ / ~ \ サヨナラ /

Slide 52

Slide 52 text

● 生き残った他の Node 側で明確に分かるのは「特定の (落ちたと思われる) Node との通信ができない」ことのみである。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ シンダ...? / \ ワカラン... / 複数 Node の同時障害 (Split Brain 対策) ? ? ?

Slide 53

Slide 53 text

● 「通信できない」原因として、「Node の完全停止」「ネットワーク障害」「一時的なレ スポンス遅延」等、様々な原因が考えられる。 ● 生きているのか死んでいるのか分からない、あたかも「シュレディンガーの G」状態 になってしまう。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ イキテルカモ...? / \ ニャーン / 複数 Node の同時障害 (Split Brain 対策) ? ? ?

Slide 54

Slide 54 text

● 仮に、障害の原因が「ネットワークの問題」であった場合、通信ができない 2匹は問 題なく動作していて、Client からの Read / Write を処理できる状態である可能性も ある。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (Split Brain 対策) ? ? ? \ ナンモワカラン /

Slide 55

Slide 55 text

過半数を割った Replica を復旧すると 何が起きるのか (実際には発生しない) \ スプリット /

Slide 56

Slide 56 text

● 例えば、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B に 分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B Split Brain (実際には発生しない)

Slide 57

Slide 57 text

● この状態の場合、Group A から見ると Group B の Node が全て落ちている (Cluster 内で 3匹同時障害が発生した) ように見える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? Split Brain (実際には発生しない) \ シンダ? /

Slide 58

Slide 58 text

● 同様に、Group B から見ると Group A の Node が全て落ちている (Cluster 内で 4 匹同時障害が発生した) ように見える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? Split Brain (実際には発生しない) \ シンダ? /

Slide 59

Slide 59 text

● 仮に「Replica 数が過半数を割っていても復旧処理を実行する」という動作になって いる場合、Group A 側では残っている (過半数を割っている) Replica を元に “k1 ~ k10” のデータの復旧処理が実行される。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ? ? ? Replica Replica k21 ~ k30 Replica Split Brain (実際には発生しない) \ リカバリ /

Slide 60

Slide 60 text

● Group B 側では過半数以上の Replica が残っているので、そのまま残っている Replica を元に “k1 ~ k10” のデータの復旧処理が実行される。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? Replica k1 ~ k10 Replica Replica Split Brain (実際には発生しない) \ リカバリ /

Slide 61

Slide 61 text

● このように、それぞれの Group で個別に復旧処理を実行してしまった場合... k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica Replica Replica k1 ~ k10 Replica Replica k21 ~ k30 Replica ? ? ? ? ? ? Split Brain (実際には発生しない)

Slide 62

Slide 62 text

● 最終的に、Group A / Group B の双方で、別々に「“k1 ~ k10” のデータに対する Read / Write ができる」状態になってしまう。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica Replica Replica k1 ~ k10 Replica Replica k21 ~ k30 Replica Split Brain (実際には発生しない) \ フッカツ / \ フッカツ /

Slide 63

Slide 63 text

● この状態で Group A / Group B 双方で同じデータに対して違う値を Write すると、 Cluster 内でデータの不整合 (Group A では k5 = aaa / Group B では k5 = bbb) が発生することになる。 k5 = aaa k5 = bbb k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B k5 = aaa k5 = aaa k5 = bbb k5 = bbb Replica Replica k21 ~ k30 Replica Split Brain (実際には発生しない) Tx: Write (k5, aaa) Tx: Write (k5, bbb)

Slide 64

Slide 64 text

● さらに、この状態でネットワークの障害 (分断) が復旧すると、同じ key (primary key) であるにも関わらず、Node によって異なる value が保持されている (Cluster 内で異なる value が混在している) 状態になってしまう。 k5 = aaa k5 = bbb k11 ~ k20 Replica Replica k21 ~ k30 Replica k5 = aaa k5 = aaa k5 = bbb k5 = bbb Replica Replica k21 ~ k30 Replica Split Brain (実際には発生しない) \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? /

Slide 65

Slide 65 text

過半数を割った Replica を復旧「しな い」場合の動き \ タイサク /

Slide 66

Slide 66 text

● 前述の例と同じように、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B に分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B 過半数を割った Replica を復旧しない場合の動作

Slide 67

Slide 67 text

● Group A から見ると Group B の Node が全て落ちている(Cluster 内で 3匹同時 障害が発生した) ように見える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ シンダ? / 過半数を割った Replica を復旧しない場合の動作

Slide 68

Slide 68 text

● しかし、”k1 ~ k10” のデータは「Replica 数が過半数を割っている」ので、復旧処理 は実施されない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ? ? ? \ ナニモシナイ / Replica 過半数を割った Replica を復旧しない場合の動作

Slide 69

Slide 69 text

● また、「過半数以上の Replica が残っている」“k21 ~ k30” のデータについては、復 旧処理を実行する。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ? ? ? \ リカバリ / k21 ~ k30 Replica 過半数を割った Replica を復旧しない場合の動作

Slide 70

Slide 70 text

● 同様に、Group B から見ると Group A の Node が全て落ちている (Cluster 内で 4 匹同時障害が発生した) ように見える。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ シンダ? / Replica 過半数を割った Replica を復旧しない場合の動作

Slide 71

Slide 71 text

● Group B 側では ”k1 ~ k10” のデータの「Replica が過半数以上残っている」の で、”k1 ~ k10” のデータに対する復旧処理 (Leaseholder への昇格や Replica の 追加) が実行される。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ リカバリ / Replica k1 ~ k10 過半数を割った Replica を復旧しない場合の動作

Slide 72

Slide 72 text

● 逆に、”k21 ~ k30” のデータについては、「Replica 数が過半数を割っている」の で、復旧処理は実行しない。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ ナニモシナイ / Replica k1 ~ k10 過半数を割った Replica を復旧しない場合の動作

Slide 73

Slide 73 text

● それぞれの Group で「過半数を割った Replica の復旧処理は実行しない」「過半 数以上残っている Replica のデータだけを復旧する」という動作をした場合... k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica k1 ~ k10 k21 ~ k30 Replica ? ? ? ? ? ? 過半数を割った Replica を復旧しない場合の動作

Slide 74

Slide 74 text

● 全てのデータに対して、Group A もしくは Group B の「どちらかでのみ Read / Write ができる」状態になる。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica k1 ~ k10 k21 ~ k30 Replica 過半数を割った Replica を復旧しない場合の動作

Slide 75

Slide 75 text

● この状態であれば、ネットワークの障害 (分断) が復旧しても、同じ key (primary key) に対して異なる value が保持されている状態 (いわゆる Split Brain 状態) に はならない。 ● 復旧されずに残った Leaseholder は、Raft の Term が古いので、破棄されると思 われる。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica k1 ~ k10 k21 ~ k30 Replica 過半数を割った Replica を復旧しない場合の動作

Slide 76

Slide 76 text

[再掲] 複数 Node の同時障害 \ モウイチド /

Slide 77

Slide 77 text

● CockroachDB では、たとえ Cluster が 5匹以上の構成であっても、Replica 数が 3 の場合は、2匹同時に障害が発生すると (Rplica 数が過半数を割ってしまうと)、 一部のデータ (図の例の場合は ”k1 ~ k10” のデータ) に対する Read / Write はで きなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 ~ ~ \ デキナイ... /

Slide 78

Slide 78 text

● そのため、Survivability を上げるためには、Node 数だけでなく、Replica 数も増や す必要がある。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 Replica Replica Replica Replica Replica Replica \ Replica = 5 ! /

Slide 79

Slide 79 text

Topology Patterns \ トポロジー /

Slide 80

Slide 80 text

Single Node \ イッピキ /

Slide 81

Slide 81 text

Single Node ● CockroachDB は 1匹でも動作可能。 ● App の開発や検証目的等の Survivability が不要な用途で利用可能。 k1 ~ k10 k11 ~ k20 k21 ~ k30

Slide 82

Slide 82 text

Single Node ● 1匹障害で Cluster (?) が停止してしまうので、Survivability はほぼない。 ● 駆除する場合は、スプレー缶タイプの殺虫剤や丸めた新聞紙で駆除可能。 k1 ~ k10 k11 ~ k20 k21 ~ k30

Slide 83

Slide 83 text

Cluster \ クラスタ /

Slide 84

Slide 84 text

Cluster (3匹) ● 3匹構成の Cluster にする。 ● Raft を使っているので、最低 3匹での構成が良い。 ● 本番利用で推奨される最小構成。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica

Slide 85

Slide 85 text

Cluster (3匹) ● 1匹障害には耐えられるためそこそこの Survivability はあるが、2匹以上同時に障 害が発生すると、Cluster が動作しなくなってしまう。 ● 駆除する場合は、粘着シートを使って捕獲するタイプや駆除エサ剤を使うタイプの アイテムを利用し、複数匹まとめて駆除する必要があると思われる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica

Slide 86

Slide 86 text

Single Region (Multi Zone) \ シングルリージョン /

Slide 87

Slide 87 text

Single Region (Multi Zone) ● 単一 Region 内の異なる Zone に 3匹デプロイすることで Survivability を上げるこ とができる。 ● Zone を分けることによって、単一 Zone 障害までなら生き残ることが可能。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region

Slide 88

Slide 88 text

Single Region (Multi Zone) ● 2匹以上同時に (2 Zone 以上同時に) 障害が発生すると、Cluster が動作しなく なってしまう。 ● 駆除する場合は、部屋全体に煙が充満するタイプの殺虫剤を全 Zone で同時に利 用し、まとめて駆除する必要があると思われる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region

Slide 89

Slide 89 text

Multi Region (3匹) \ マルチリージョン /

Slide 90

Slide 90 text

● 3匹構成の Cluster にて、各 Node を異なる Region に分散させる。 ● 単一 Region 障害までなら生き残ることができ る。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 91

Slide 91 text

● ただし、Region 跨ぎの構成にするとデメリット も大きくなる。 ● みんな大好き「光の速さ (299,792,458m/s) を 超えられない問題」が発生する。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 92

Slide 92 text

● Region を跨がない Read は低レイテンシで実 行可能。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Read (k15)

Slide 93

Slide 93 text

● Region を跨ぐ Read は、Cluster 内で Region 間通信が発生してしまうため、遅くなる。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Read (k5)

Slide 94

Slide 94 text

● Write の場合は、Cluster 内で Region を跨い だ Replication を実施する必要があるため、常 に遅くなる。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Write (k15, v2)

Slide 95

Slide 95 text

● Multi Region 構成にすると、単一 Region 障 害までなら生き残ることができるが、 Survivability と性能との間でトレードオフが発 生する。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 96

Slide 96 text

Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica ● また、この構成は 2匹同時障害が発生すると Cluster が停止するので、そこまで Survivability は上がってないと思われる。 ● ここから更に Survivability を上げるためには、 Node 数を増やす必要がある。

Slide 97

Slide 97 text

Multi Region (9匹) \ フエルヨ /

Slide 98

Slide 98 text

● Node 数を 9匹に増やすことによって、 Survivability を上げることができる。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 99

Slide 99 text

● 加えて、各 Region 内で異なる Zone にデプロ イすることで、さらに Survivability を上げること ができる。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 100

Slide 100 text

● ただし、この構成をよく見ると、データの Replica は 3つしかない。 ● つまり、2匹同時に Node 障害が発生すると、 一部のデータで Read / Write ができなるなる 可能性がある。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 101

Slide 101 text

● 例えば、図で示した 2匹で同時に障害が発生 すると、”k21 ~ k30” のデータの Read / Write はできなくなってしまう。 ● この構成では、9匹構成にするメリットが少な い。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica

Slide 102

Slide 102 text

Multi Region (5 Replica) \ レプリカ モ フエルヨ /

Slide 103

Slide 103 text

● Node 数 9匹の構成に加え、データの Replica 数を 5 に増やすことによって、さらに Survivability を上げることができる。 Multi Region (9匹 + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica

Slide 104

Slide 104 text

● この構成であれば、2匹同時障害が発生して も、全てのデータで「過半数の Replica が残る」 ため、障害から生き残ることができる。 Multi Region (9匹 + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica

Slide 105

Slide 105 text

● さらに、この構成であれば、単一 Region 障害 が発生しても、全てのデータで「過半数の Replica が残る」ため、Region 障害からも生き 残ることができる。 Multi Region (9匹 + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica

Slide 106

Slide 106 text

● このレベルになると、Survivability はかなり高く なる。 ● 駆除する場合は、専門の業者に依頼する必要 があると思われる。 Multi Region (9匹 + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica

Slide 107

Slide 107 text

最適化 \ オプティマイズ /

Slide 108

Slide 108 text

Regional Tables \ リージョナル /

Slide 109

Slide 109 text

● 特定の TABLE のデータを特定の Region に 紐付けて格納することができる。 ● 特定の ROW (TABLE 単位ではなく Record 単位) のデータを特定の Region に紐付けて格 納することもできる。 Regional Tables k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica k21 ~ k30 Replica Replica

Slide 110

Slide 110 text

● ユースケースとして、US のユーザーのデータ は US Region / EU のユーザーのデータは EU Region / JP のユーザーのデータは JP Region に格納する、というパターンが考えられ る。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica

Slide 111

Slide 111 text

● JP のユーザーは JP からアクセスする前提とし た場合、JP ユーザーは JP Region から (地理 的に近い Region から低いレイテンシで) デー タを Read することができる。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica Tx: Read (JP user)

Slide 112

Slide 112 text

● 同様に、JP のユーザーは JP からアクセスす る前提とした場合、JP のユーザーのデータに 対する Write は、JP Region に閉じて完了する (Region を跨がずに低レイテンシで Replication する) ことができる。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica Tx: Write (JP user)

Slide 113

Slide 113 text

● JP Region で障害が発生した場合、JP のユー ザーはデータの Read / Write ができなくなる が、US / EU のユーザーはデータの Read / Write ができる。つまり、Region 障害の影響範 囲を Region 内にとどめることができる。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica

Slide 114

Slide 114 text

Global Tables \ グローバル /

Slide 115

Slide 115 text

● CockroachDB には「Write の性能を犠牲にし て Replica から最新のデータを Read できるよ うにする機能」がある。 Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica Replica

Slide 116

Slide 116 text

● Replica から最新のデータを Read できるよう になるため、Client は常に一番近い Region か ら低レイテンシでデータを Read することができ る。 Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Tx: Read (k25) Replica Replica

Slide 117

Slide 117 text

● Write は “non-blocking transactions” と呼ば れるちょっと特殊な処理にて実施される。 ● “commit-wait” と呼ばれる処理にて、「一定時 間待ってから」COMMIT するので、Write 処理 のレイテンシが高くなる。 Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Tx: Write (k15, v3) Replica Replica

Slide 118

Slide 118 text

● Global な環境でも Read が低レイテンシで実 行できるので、Global にデータを扱う、かつ Read Heavy なワークロードの場合は、この Global Tables の利用を検討してみると良いか もしれない。 Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Tx: Read (k15) Read (k27) Replica Replica

Slide 119

Slide 119 text

● “non-blocking transactions” や “commit-wait” を説明しようとすると 3時間ぐらい かかってしまいそうな気がするので、詳細は割愛します。 ● 気になる方は公式ドキュメントや論文を読んでみてください。 ○ https://www.cockroachlabs.com/docs/v23.2/global-tables ○ https://www.cockroachlabs.com/docs/v23.2/architecture/transaction-layer #non-blocking-transactions ○ https://www.cockroachlabs.com/pdf/SIGMOD2022.pdf Global Tables \ カツアイ /

Slide 120

Slide 120 text

まとめ \ マトメ /

Slide 121

Slide 121 text

まとめ ● CockroachDB は、Node 数や Replica 数の設定に応じて、いい感じに障害から生き残ること ができる。 ● Zone 跨ぎや Region 跨ぎの構成にすることで、Survivability を上げることができる。 ● ただし、Region 跨ぎにした場合、Read / Write のレイテンシが増えるので注意が必要。 ● Survivability (いわゆる耐障害性) と Performance (主にレイテンシ) は、基本的にトレードオフ になる。 ● いくつかのパターンの最適化方法も提供されているので、ワークロードに応じて最適化も可能。

Slide 122

Slide 122 text

CockroachDB はかなりしぶとい! \ ドヤァ / まとめ

Slide 123

Slide 123 text

宣伝 \ センデン /

Slide 124

Slide 124 text

Database Engineering Meetup をやってます!!! https://scalar.connpass.com/

Slide 125

Slide 125 text

Thank you!