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

Transcript

1. 2024/05/08 Oracle Cloud Hangout Cafe Season 8 #4 CockroachDB は どのくらい「しぶとい」のか？ #ochacafe \ ｺﾝﾆﾁﾊ /
2. 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.
3. ※Note※ ちょっと自信が無いとこもあります！間違ってたらごめんさな い！！！ また、説明を簡略化するために一部詳細を省略 / 抽象化して表現 している箇所があります！！！ \ ﾕﾙｼﾃ /
4. みなさん CockroachDB 触ったことあり ますか？ \ ﾎﾞｸﾄ ｱｸｼｭ /
5. CockroachDB は... \ I am… /
6. 名前とロゴがヤバい分散 SQL データベース https://github.com/cockroachdb/cockroach
7. 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
8. 今日は CockroachDB の 「しぶとさ (耐障害性 / Survivability)」 についてお話します。 \ ｼﾌﾞﾄｲ /
9. CockroachDB Overview \ ｶﾞｲﾖｳ /
10. 論理的に 1つの DB Node 1 Node 3 Cluster overview (3匹の場合) Node 2 • 分散 DB なので、複数 Node で構成された Cluster で動作する。
11. どのようにデータを持っているのか \ ﾃﾞｰﾀ /
12. データの格納 • RDBMS なのでユーザか らは TABLE に見える。
13. データの格納 • RDBMS なのでユーザか らは TABLE に見える。 • TABLE は Key-Value 形 式に変換される。
14. データの格納 • RDBMS なのでユーザか らは TABLE に見える。 • TABLE は Key-Value 形 式に変換される。 • Key-Value は 512MB に 分割される (Range)。 Range Range Range
15. データの格納 • RDBMS なのでユーザか らは TABLE に見える。 • TABLE は Key-Value 形 式に変換される。 • Key-Value は 512MB に 分割される (Range)。 • 各 Range を分散して 各 Node に格納する。 k1 ~ k10 k11 ~ k20 k21 ~ k30 Range Range Range
16. データの格納 • 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
17. 5匹に増えた場合 • いい感じにスケールアウトすることも可能。 • スケールした場合、データは自動でいい感じに分散される。 • スケールインすることも可能。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica
18. どうやって Read / Write するのか \ ﾖﾐｶｷ /
19. 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 を処 理可能。
20. 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)
21. 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)
22. 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)
23. 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)
24. Survivability (本題) \ ｻﾊﾞｲﾌﾞ /
25. 単一 Node 障害発生時の動作 \ ｸﾗｯｼｭ /
26. 正常時 (5匹) • 正常時は各 Range のデータ (Replica) をそれぞれの Node がいい感じに分散し て保持している。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ｺﾞﾋｷ /
27. • 障害が発生して、Node が 1匹いなくなる。 \ ｻﾖﾅﾗ / 障害発生 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica ~ \ ｱﾄﾊﾏｶｾﾛ / \ ｻﾗﾊﾞﾀﾞ... /
28. 4匹に減少 • Node が 1匹減少すると、一時的に Range の Replica や Leaseholder が足りな い状態になる。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica \ ﾀﾘﾅｲ... /
29. 4匹に減少 (Leaseholder が消えてしまった場合) • 障害が発生していた Node が Leaseholder (≒ Raft の Leader) を保持していた 場合、一時的に Read / Write ができなくなる。 • 図の場合、”k11 ~ k20” のデータに対する Read / Write ができなくなる。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica \ ﾃﾞｷﾅｲ... /
30. 4匹に減少 (Leaseholder が消えてしまった場合) • Leaseholder (≒ Raft の Leader) が存在しなくなってしまった場合、生き残った Replica のどれかが新しく Leaseholder (≒ Raft の Leader) になる。 k1 ~ k10 Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ﾏｶｾﾛ /
31. 4匹に減少 (Replica が消えてしまった場合) • Replica 数が足りない場合は、他の Node からデータをコピーして Cluster 内の Replica 数 (デフォルト 3つ) を保つ。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ﾏｶｾﾛ / \ ﾀﾉﾑ /
32. 4匹に減少 (自動での対処完了) • 障害発生に伴い Node 数が減ってしまった場合であっても、Leaseholder や Replica の数が保たれるようになっている。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ﾖﾝﾋｷ / \ ﾃﾞﾓ / \ ｳｺﾞｸ / \ ﾖ! /
33. 4匹に減少 • このようにして、障害発生時でもユーザー影響を最小限にしつつ、Cluster としては 動作し続けることができる。 • もちろん、ここから Node 数を元に戻すことも可能。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ﾁﾗｯ /
34. 5匹に復旧 • 障害が発生した Node を復旧させる、もしくは新しい Node を追加することで、5匹 構成に戻すことも可能。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ｺﾝﾆﾁﾊ /
35. 5匹に復旧 • 5匹構成に戻った場合、他の Node からいい感じに Replica が分散される動作に なる。 • この動作はスケールアウト (新しい Node を追加) する時も同様。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica Replica Replica \ ﾏｶｾﾛ /
36. 5匹に復旧 • 最終的に 5匹構成、かつデータがいい感じに分散された状態に復旧することができ る。 k1 ~ k10 Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica Replica \ ﾌｯｶﾂ /
37. 複数 Node の同時障害 \ ﾄﾞｳｼﾞ /
38. 複数 Node の同時障害 • Raft では過半数の Node が生きていれば処理を継続できる (Cluster 構成が “2N + 1” Node 構成の場合 “N node” の障害に耐えられる)。 • そのため、5匹構成の Cluster であれば、一見すると 2匹障害までなら耐えられる ように見えるかもしれない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ｺﾞﾋｷ /
39. • しかし、CockroachDB では、Node 単位ではなく Range 単位で Raft を利用した Replication が実行されている。 • つまり、実際に「何 Node 障害まで耐えられるか」は Replica 数に依存するので、 注意が必要。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 \ Replica = 3 ! /
40. • 例えば、図のような構成の場合において、右側の 2匹で障害が発生すると、”k1 ~ k10” の Replica 数が “1” になってしまう (過半数を割ってしまう) ため、”k1 ~ k10” のデータに対する Read / Write はできなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) ~ ~ \ ﾃﾞｷﾅｲ... /
41. • 加えて、Range の Replica 数が「過半数を割った」場合、残った Replica を使って 新しい Replica を作ることは「しない」仕組みになっている。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 \ ﾘｶﾊﾞﾘｼﾅｲ /
42. • この図の場合、”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 \ ﾘｶﾊﾞﾘ /
43. • しかし、”k1 ~ k10” の Range のデータは自動的には復旧されず、Read / Write で きない状態のままになる。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 Replica k21 ~ k30 \ ｿﾉﾏﾏ /
44. • この動作は、Node 数をさらに増やした場合でも変わらない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) \ ﾅﾅﾋｷ /
45. • 例えば、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) ~ ~ \ ﾃﾞｷﾅｲ... /
46. • そのため、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 ! /
47. • 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 \ ｺﾞﾋｷ ﾀﾞｹﾄﾞ... / ~ ~
48. • そのため、通常の復旧処理が実行され、引き続き全てのデータの 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
49. 何故 Replica 数が過半数を割ると復旧 処理が実行されないのか？ \ Why…? /
50. • (ドキュメント上で明確な記載を確認できていないので) あくまで推測ではあるが、こ の「Range の Replica が過半数を割ると自動的には復旧されない」という動作は、 恐らく Split Brain を避けるためのものであると考えられる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (Split Brain 対策)
51. • ある Node における「何等かの問題」を検知した場合であっても、他の Node から その問題の原因を明確に知ることはできない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica ~ 複数 Node の同時障害 (Split Brain 対策) \ ｻﾖﾅﾗ / ~ \ ｻﾖﾅﾗ /
52. • 生き残った他の Node 側で明確に分かるのは「特定の (落ちたと思われる) Node との通信ができない」ことのみである。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ｼﾝﾀﾞ...? / \ ﾜｶﾗﾝ... / 複数 Node の同時障害 (Split Brain 対策) ？ ？ ？
53. • 「通信できない」原因として、「Node の完全停止」「ネットワーク障害」「一時的なレ スポンス遅延」等、様々な原因が考えられる。 • 生きているのか死んでいるのか分からない、あたかも「シュレディンガーの G」状態 になってしまう。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ｲｷﾃﾙｶﾓ...? / \ ﾆｬｰﾝ / 複数 Node の同時障害 (Split Brain 対策) ？ ？ ？
54. • 仮に、障害の原因が「ネットワークの問題」であった場合、通信ができない 2匹は問 題なく動作していて、Client からの Read / Write を処理できる状態である可能性も ある。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (Split Brain 対策) ？ ？ ？ \ ﾅﾝﾓﾜｶﾗﾝ /
55. 過半数を割った Replica を復旧すると 何が起きるのか (実際には発生しない) \ ｽﾌﾟﾘｯﾄ /
56. • 例えば、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B に 分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B Split Brain (実際には発生しない)
57. • この状態の場合、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 (実際には発生しない) \ ｼﾝﾀﾞ? /
58. • 同様に、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 (実際には発生しない) \ ｼﾝﾀﾞ? /
59. • 仮に「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 (実際には発生しない) \ ﾘｶﾊﾞﾘ /
60. • 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 (実際には発生しない) \ ﾘｶﾊﾞﾘ /
61. • このように、それぞれの 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 (実際には発生しない)
62. • 最終的に、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 (実際には発生しない) \ ﾌｯｶﾂ / \ ﾌｯｶﾂ /
63. • この状態で 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)
64. • さらに、この状態でネットワークの障害 (分断) が復旧すると、同じ 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 (実際には発生しない) \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? /
65. 過半数を割った Replica を復旧「しな い」場合の動き \ ﾀｲｻｸ /
66. • 前述の例と同じように、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B に分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B 過半数を割った Replica を復旧しない場合の動作
67. • Group A から見ると Group B の Node が全て落ちている(Cluster 内で 3匹同時 障害が発生した) ように見える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ？ ？ ？ \ ｼﾝﾀﾞ? / 過半数を割った Replica を復旧しない場合の動作
68. • しかし、”k1 ~ k10” のデータは「Replica 数が過半数を割っている」ので、復旧処理 は実施されない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ？ ？ ？ \ ﾅﾆﾓｼﾅｲ / Replica 過半数を割った Replica を復旧しない場合の動作
69. • また、「過半数以上の Replica が残っている」“k21 ~ k30” のデータについては、復 旧処理を実行する。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ？ ？ ？ \ ﾘｶﾊﾞﾘ / k21 ~ k30 Replica 過半数を割った Replica を復旧しない場合の動作
70. • 同様に、Group B から見ると Group A の Node が全て落ちている (Cluster 内で 4 匹同時障害が発生した) ように見える。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ？ ？ ？ \ ｼﾝﾀﾞ? / Replica 過半数を割った Replica を復旧しない場合の動作
71. • 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 を復旧しない場合の動作
72. • 逆に、”k21 ~ k30” のデータについては、「Replica 数が過半数を割っている」の で、復旧処理は実行しない。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ？ ？ ？ \ ﾅﾆﾓｼﾅｲ / Replica k1 ~ k10 過半数を割った Replica を復旧しない場合の動作
73. • それぞれの Group で「過半数を割った Replica の復旧処理は実行しない」「過半 数以上残っている Replica のデータだけを復旧する」という動作をした場合... k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica k1 ~ k10 k21 ~ k30 Replica ？ ？ ？ ？ ？ ？ 過半数を割った Replica を復旧しない場合の動作
74. • 全てのデータに対して、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 を復旧しない場合の動作
75. • この状態であれば、ネットワークの障害 (分断) が復旧しても、同じ 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 を復旧しない場合の動作
76. [再掲] 複数 Node の同時障害 \ ﾓｳｲﾁﾄﾞ /
77. • CockroachDB では、たとえ Cluster が 5匹以上の構成であっても、Replica 数が 3 の場合は、2匹同時に障害が発生すると (Rplica 数が過半数を割ってしまうと)、 一部のデータ (図の例の場合は ”k1 ~ k10” のデータ) に対する Read / Write はで きなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 ~ ~ \ ﾃﾞｷﾅｲ... /
78. • そのため、Survivability を上げるためには、Node 数だけでなく、Replica 数も増や す必要がある。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 Replica Replica Replica Replica Replica Replica \ Replica = 5 ! /
79. Topology Patterns \ ﾄﾎﾟﾛｼﾞｰ /
80. Single Node \ ｲｯﾋﾟｷ /
81. Single Node • CockroachDB は 1匹でも動作可能。 • App の開発や検証目的等の Survivability が不要な用途で利用可能。 k1 ~ k10 k11 ~ k20 k21 ~ k30
82. Single Node • 1匹障害で Cluster (?) が停止してしまうので、Survivability はほぼない。 • 駆除する場合は、スプレー缶タイプの殺虫剤や丸めた新聞紙で駆除可能。 k1 ~ k10 k11 ~ k20 k21 ~ k30
83. Cluster \ ｸﾗｽﾀ /
84. Cluster (3匹) • 3匹構成の Cluster にする。 • Raft を使っているので、最低 3匹での構成が良い。 • 本番利用で推奨される最小構成。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica
85. Cluster (3匹) • 1匹障害には耐えられるためそこそこの Survivability はあるが、2匹以上同時に障 害が発生すると、Cluster が動作しなくなってしまう。 • 駆除する場合は、粘着シートを使って捕獲するタイプや駆除エサ剤を使うタイプの アイテムを利用し、複数匹まとめて駆除する必要があると思われる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica
86. Single Region (Multi Zone) \ ｼﾝｸﾞﾙﾘｰｼﾞｮﾝ /
87. Single Region (Multi Zone) • 単一 Region 内の異なる Zone に 3匹デプロイすることで Survivability を上げるこ とができる。 • Zone を分けることによって、単一 Zone 障害までなら生き残ることが可能。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region
88. Single Region (Multi Zone) • 2匹以上同時に (2 Zone 以上同時に) 障害が発生すると、Cluster が動作しなく なってしまう。 • 駆除する場合は、部屋全体に煙が充満するタイプの殺虫剤を全 Zone で同時に利 用し、まとめて駆除する必要があると思われる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region
89. Multi Region (3匹) \ ﾏﾙﾁﾘｰｼﾞｮﾝ /
90. • 3匹構成の Cluster にて、各 Node を異なる Region に分散させる。 • 単一 Region 障害までなら生き残ることができ る。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
91. • ただし、Region 跨ぎの構成にするとデメリット も大きくなる。 • みんな大好き「光の速さ (299,792,458m/s) を 超えられない問題」が発生する。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
92. • Region を跨がない Read は低レイテンシで実 行可能。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Read (k15)
93. • Region を跨ぐ Read は、Cluster 内で Region 間通信が発生してしまうため、遅くなる。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Read (k5)
94. • Write の場合は、Cluster 内で Region を跨い だ Replication を実施する必要があるため、常 に遅くなる。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Write (k15, v2)
95. • Multi Region 構成にすると、単一 Region 障 害までなら生き残ることができるが、 Survivability と性能との間でトレードオフが発 生する。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
96. Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica • また、この構成は 2匹同時障害が発生すると Cluster が停止するので、そこまで Survivability は上がってないと思われる。 • ここから更に Survivability を上げるためには、 Node 数を増やす必要がある。
97. Multi Region (9匹) \ ﾌｴﾙﾖ /
98. • Node 数を 9匹に増やすことによって、 Survivability を上げることができる。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
99. • 加えて、各 Region 内で異なる Zone にデプロ イすることで、さらに Survivability を上げること ができる。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
100. • ただし、この構成をよく見ると、データの Replica は 3つしかない。 • つまり、2匹同時に Node 障害が発生すると、 一部のデータで Read / Write ができなるなる 可能性がある。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
101. • 例えば、図で示した 2匹で同時に障害が発生 すると、”k21 ~ k30” のデータの Read / Write はできなくなってしまう。 • この構成では、9匹構成にするメリットが少な い。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
102. Multi Region (5 Replica) \ ﾚﾌﾟﾘｶ ﾓ ﾌｴﾙﾖ /
103. • 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
104. • この構成であれば、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
105. • さらに、この構成であれば、単一 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
106. • このレベルになると、Survivability はかなり高く なる。 • 駆除する場合は、専門の業者に依頼する必要 があると思われる。 Multi Region (9匹 + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica
107. 最適化 \ ｵﾌﾟﾃｨﾏｲｽﾞ /
108. Regional Tables \ ﾘｰｼﾞｮﾅﾙ /
109. • 特定の TABLE のデータを特定の Region に 紐付けて格納することができる。 • 特定の ROW (TABLE 単位ではなく Record 単位) のデータを特定の Region に紐付けて格 納することもできる。 Regional Tables k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica k21 ~ k30 Replica Replica
110. • ユースケースとして、US のユーザーのデータ は US Region / EU のユーザーのデータは EU Region / JP のユーザーのデータは JP Region に格納する、というパターンが考えられ る。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica
111. • 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)
112. • 同様に、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)
113. • 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
114. Global Tables \ ｸﾞﾛｰﾊﾞﾙ /
115. • CockroachDB には「Write の性能を犠牲にし て Replica から最新のデータを Read できるよ うにする機能」がある。 Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica Replica
116. • 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
117. • 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
118. • 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
119. • “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 \ ｶﾂｱｲ /
120. まとめ \ ﾏﾄﾒ /
121. まとめ • CockroachDB は、Node 数や Replica 数の設定に応じて、いい感じに障害から生き残ること ができる。 • Zone 跨ぎや Region 跨ぎの構成にすることで、Survivability を上げることができる。 • ただし、Region 跨ぎにした場合、Read / Write のレイテンシが増えるので注意が必要。 • Survivability (いわゆる耐障害性) と Performance (主にレイテンシ) は、基本的にトレードオフ になる。 • いくつかのパターンの最適化方法も提供されているので、ワークロードに応じて最適化も可能。
122. CockroachDB はかなりしぶとい！ \ ﾄﾞﾔｧ / まとめ
123. 宣伝 \ ｾﾝﾃﾞﾝ /
124. Database Engineering Meetup をやってます！！！ https://scalar.connpass.com/
125. Thank you!