CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?

by kota2and3kan

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!