Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

kota2and3kan

May 08, 2024
Tweet

More Decks by kota2and3kan

Other Decks in Technology

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. 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
  4. 論理的に 1つの DB Node 1 Node 3 Cluster overview (3匹の場合)

    Node 2 • 分散 DB なので、複数 Node で構成された Cluster で動作する。
  5. データの格納 • RDBMS なのでユーザか らは TABLE に見える。 • TABLE は

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

    Key-Value 形 式に変換される。 • Key-Value は 512MB に 分割される (Range)。 • 各 Range を分散して 各 Node に格納する。 k1 ~ k10 k11 ~ k20 k21 ~ k30 Range Range Range
  7. データの格納 • 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
  8. 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 を処 理可能。
  9. 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)
  10. 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)
  11. 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)
  12. 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)
  13. 正常時 (5匹) • 正常時は各 Range のデータ (Replica) をそれぞれの Node がいい感じに分散し

    て保持している。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ゴヒキ /
  14. • 障害が発生して、Node が 1匹いなくなる。 \ サヨナラ / 障害発生 k1 ~

    k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica ~ \ アトハマカセロ / \ サラバダ... /
  15. 4匹に減少 • Node が 1匹減少すると、一時的に Range の Replica や Leaseholder

    が足りな い状態になる。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica \ タリナイ... /
  16. 4匹に減少 (Leaseholder が消えてしまった場合) • 障害が発生していた Node が Leaseholder (≒ Raft

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

    Replica のどれかが新しく Leaseholder (≒ Raft の Leader) になる。 k1 ~ k10 Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ マカセロ /
  18. 4匹に減少 (Replica が消えてしまった場合) • Replica 数が足りない場合は、他の Node からデータをコピーして Cluster 内の

    Replica 数 (デフォルト 3つ) を保つ。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ マカセロ / \ タノム /
  19. 4匹に減少 (自動での対処完了) • 障害発生に伴い Node 数が減ってしまった場合であっても、Leaseholder や Replica の数が保たれるようになっている。 k1

    ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica \ ヨンヒキ / \ デモ / \ ウゴク / \ ヨ! /
  20. 5匹に復旧 • 5匹構成に戻った場合、他の Node からいい感じに Replica が分散される動作に なる。 • この動作はスケールアウト

    (新しい Node を追加) する時も同様。 k1 ~ k10 Replica Replica Replica Replica k21 ~ k30 Replica k11 ~ k20 Replica Replica Replica \ マカセロ /
  21. 複数 Node の同時障害 • Raft では過半数の Node が生きていれば処理を継続できる (Cluster 構成が

    “2N + 1” Node 構成の場合 “N node” の障害に耐えられる)。 • そのため、5匹構成の Cluster であれば、一見すると 2匹障害までなら耐えられる ように見えるかもしれない。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica \ ゴヒキ /
  22. • しかし、CockroachDB では、Node 単位ではなく Range 単位で Raft を利用した Replication が実行されている。

    • つまり、実際に「何 Node 障害まで耐えられるか」は Replica 数に依存するので、 注意が必要。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 \ Replica = 3 ! /
  23. • 例えば、図のような構成の場合において、右側の 2匹で障害が発生すると、”k1 ~ k10” の Replica 数が “1” になってしまう

    (過半数を割ってしまう) ため、”k1 ~ k10” のデータに対する Read / Write はできなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) ~ ~ \ デキナイ... /
  24. • 加えて、Range の Replica 数が「過半数を割った」場合、残った Replica を使って 新しい Replica を作ることは「しない」仕組みになっている。

    k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 \ リカバリシナイ /
  25. • この図の場合、”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 \ リカバリ /
  26. • しかし、”k1 ~ k10” の Range のデータは自動的には復旧されず、Read / Write で

    きない状態のままになる。 k1 ~ k10 k11 ~ k20 Replica Replica Replica 複数 Node の同時障害 (3 Replica) Replica Replica Replica k21 ~ k30 Replica k21 ~ k30 \ ソノママ /
  27. • この動作は、Node 数をさらに増やした場合でも変わらない。 k1 ~ k10 Replica Replica k11 ~

    k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (3 Replica) \ ナナヒキ /
  28. • 例えば、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) ~ ~ \ デキナイ... /
  29. • そのため、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 ! /
  30. • 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 \ ゴヒキ ダケド... / ~ ~
  31. • そのため、通常の復旧処理が実行され、引き続き全てのデータの 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
  32. • (ドキュメント上で明確な記載を確認できていないので) あくまで推測ではあるが、こ の「Range の Replica が過半数を割ると自動的には復旧されない」という動作は、 恐らく Split Brain

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

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

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

    k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica 複数 Node の同時障害 (Split Brain 対策) ? ? ? \ ナンモワカラン /
  36. • 例えば、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B

    に 分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B Split Brain (実際には発生しない)
  37. • この状態の場合、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 (実際には発生しない) \ シンダ? /
  38. • 同様に、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 (実際には発生しない) \ シンダ? /
  39. • 仮に「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 (実際には発生しない) \ リカバリ /
  40. • 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 (実際には発生しない) \ リカバリ /
  41. • このように、それぞれの 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 (実際には発生しない)
  42. • 最終的に、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 (実際には発生しない) \ フッカツ / \ フッカツ /
  43. • この状態で 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)
  44. • さらに、この状態でネットワークの障害 (分断) が復旧すると、同じ 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 (実際には発生しない) \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? / \ ??? /
  45. • 前述の例と同じように、ネットワークの障害 (分断) が発生し、Cluster が Group A と Group B

    に分かれてしまった場合を考える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B 過半数を割った Replica を復旧しない場合の動作
  46. • Group A から見ると Group B の Node が全て落ちている(Cluster 内で

    3匹同時 障害が発生した) ように見える。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ シンダ? / 過半数を割った Replica を復旧しない場合の動作
  47. • しかし、”k1 ~ k10” のデータは「Replica 数が過半数を割っている」ので、復旧処理 は実施されない。 k1 ~ k10

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

    k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B ? ? ? \ リカバリ / k21 ~ k30 Replica 過半数を割った Replica を復旧しない場合の動作
  49. • 同様に、Group B から見ると Group A の Node が全て落ちている (Cluster

    内で 4 匹同時障害が発生した) ように見える。 k1 ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Group A Group B ? ? ? \ シンダ? / Replica 過半数を割った Replica を復旧しない場合の動作
  50. • 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 を復旧しない場合の動作
  51. • 逆に、”k21 ~ k30” のデータについては、「Replica 数が過半数を割っている」の で、復旧処理は実行しない。 k1 ~ k10

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

    ~ k10 Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Group A Group B Replica k1 ~ k10 k21 ~ k30 Replica ? ? ? ? ? ? 過半数を割った Replica を復旧しない場合の動作
  53. • 全てのデータに対して、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 を復旧しない場合の動作
  54. • この状態であれば、ネットワークの障害 (分断) が復旧しても、同じ 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 を復旧しない場合の動作
  55. • CockroachDB では、たとえ Cluster が 5匹以上の構成であっても、Replica 数が 3 の場合は、2匹同時に障害が発生すると (Rplica

    数が過半数を割ってしまうと)、 一部のデータ (図の例の場合は ”k1 ~ k10” のデータ) に対する Read / Write はで きなくなる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 ~ ~ \ デキナイ... /
  56. • そのため、Survivability を上げるためには、Node 数だけでなく、Replica 数も増や す必要がある。 k1 ~ k10 Replica

    Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica [再掲] 複数 Node の同時障害 Replica Replica Replica Replica Replica Replica \ Replica = 5 ! /
  57. Cluster (3匹) • 3匹構成の Cluster にする。 • Raft を使っているので、最低 3匹での構成が良い。

    • 本番利用で推奨される最小構成。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica
  58. Single Region (Multi Zone) • 単一 Region 内の異なる Zone に

    3匹デプロイすることで Survivability を上げるこ とができる。 • Zone を分けることによって、単一 Zone 障害までなら生き残ることが可能。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region
  59. Single Region (Multi Zone) • 2匹以上同時に (2 Zone 以上同時に) 障害が発生すると、Cluster

    が動作しなく なってしまう。 • 駆除する場合は、部屋全体に煙が充満するタイプの殺虫剤を全 Zone で同時に利 用し、まとめて駆除する必要があると思われる。 k1 ~ k10 Replica Replica k11 ~ k20 Replica Replica k21 ~ k30 Replica Replica Region
  60. • 3匹構成の Cluster にて、各 Node を異なる Region に分散させる。 • 単一

    Region 障害までなら生き残ることができ る。 Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
  61. • Region を跨がない Read は低レイテンシで実 行可能。 Multi Region (3匹) Replica

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

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

    Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Tx: Write (k15, v2)
  64. Multi Region (3匹) Replica Replica k21 ~ k30 k1 ~

    k10 Replica Replica Replica k11 ~ k20 Replica • また、この構成は 2匹同時障害が発生すると Cluster が停止するので、そこまで Survivability は上がってないと思われる。 • ここから更に Survivability を上げるためには、 Node 数を増やす必要がある。
  65. • 加えて、各 Region 内で異なる Zone にデプロ イすることで、さらに Survivability を上げること ができる。

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

    Read / Write ができなるなる 可能性がある。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
  67. • 例えば、図で示した 2匹で同時に障害が発生 すると、”k21 ~ k30” のデータの Read / Write

    はできなくなってしまう。 • この構成では、9匹構成にするメリットが少な い。 Multi Region (9匹) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica
  68. • 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
  69. • この構成であれば、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
  70. • さらに、この構成であれば、単一 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
  71. • このレベルになると、Survivability はかなり高く なる。 • 駆除する場合は、専門の業者に依頼する必要 があると思われる。 Multi Region (9匹

    + 5 replica) Replica Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica
  72. • 特定の TABLE のデータを特定の Region に 紐付けて格納することができる。 • 特定の ROW

    (TABLE 単位ではなく Record 単位) のデータを特定の Region に紐付けて格 納することもできる。 Regional Tables k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica k21 ~ k30 Replica Replica
  73. • ユースケースとして、US のユーザーのデータ は US Region / EU のユーザーのデータは EU

    Region / JP のユーザーのデータは JP Region に格納する、というパターンが考えられ る。 Regional Tables US users Replica Replica Replica JP Users Replica EU users Replica Replica
  74. • 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)
  75. • 同様に、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)
  76. • 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
  77. • CockroachDB には「Write の性能を犠牲にし て Replica から最新のデータを Read できるよ うにする機能」がある。

    Global Tables Replica k21 ~ k30 k1 ~ k10 Replica Replica Replica k11 ~ k20 Replica Replica Replica Replica Replica Replica Replica Replica
  78. • 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
  79. • 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
  80. • 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
  81. • “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 \ カツアイ /
  82. まとめ • CockroachDB は、Node 数や Replica 数の設定に応じて、いい感じに障害から生き残ること ができる。 • Zone

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