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

CockroachDB から覗く形式手法の世界 #JTF2021w / July Tech Festa 2021 winter

y_taka_23
January 24, 2021

CockroachDB から覗く形式手法の世界 #JTF2021w / July Tech Festa 2021 winter

July Tech Festa 2021 winter で使用したスライドです。

バグのない分散システムの設計は果たして可能でしょうか? この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。

イベント概要:https://techfesta.connpass.com/event/193966/
ブログ記事:https://ccvanishing.hateblo.jp/entry/2021/01/24/185819
録画:https://www.youtube.com/watch?v=T26-viZnrE0

y_taka_23

January 24, 2021
Tweet

More Decks by y_taka_23

Other Decks in Technology

Transcript

  1. チェシャ猫 (@y_taka_23)
    July Tech Festa 2021 Winter (24th Jan. 2021)

    View Slide

  2. View Slide

  3. 形式手法ツール
    TLA+ により「証明」済

    View Slide

  4. ● CockroachDB の概要
    ○ スケーラビリティを実現するアーキテクチャ
    ○ 生じた課題と Parallel Commit による解決
    ● 形式手法ツール TLA+ の概要
    ○ 理論はともかく、ツールとしての雰囲気
    ○ CockroachDB の挙動をどう表現・検証するか

    View Slide

  5. How Does CockroachDB Construct Transactions?

    View Slide

  6. ● Spanner 系の分散データベース
    ○ インタフェースとして SQL をサポート
    ○ 強い一貫性を持ったトランザクションをサポート
    ○ 旧来の RDB と異なりスケールアウト可能
    ● データは Node 間で冗長化される
    ○ 一定規模以下の Node 障害時でもデータを守れる

    View Slide

  7. View Slide

  8. クライアントから見た
    処理の流れ

    View Slide

  9. SQL を Key-Value 命令に変換
    トランザクション管理(本日メイン)
    適切な Node に命令をルーティング
    Node 間でデータを冗長化
    データをディスクに永続化(省略)

    View Slide

  10. SQL を Key-Value 命令に変換

    View Slide

  11. id (PK) author like
    1 alice 4
    2 alice 8
    3 bob 5

    View Slide

  12. id (PK) author like
    1 alice 4
    2 alice 8
    3 bob 5
    /posts/2/author
    /posts/2/like
    /posts/3/id
    /posts/3/author
    /posts/3/like
    /posts/1/id
    /posts/1/author
    /posts/1/like
    /posts/2/id
    key
    alice
    8
    _
    bob
    5
    _
    alice
    4
    _
    value

    View Slide

  13. 適切な Node に命令をルーティング

    View Slide

  14. key value

    View Slide

  15. key value

    View Slide

  16. View Slide

  17. PUT k1 = v1 (k1 ∈ Range 1)

    View Slide

  18. View Slide

  19. View Slide

  20. Node 間でデータを冗長化

    View Slide

  21. ● 合意 (Consensus) プロトコル
    ○ 一度、合意が得られればその値は覆らない
    ● Leader Election
    ○ 見本となる Node (Leader, LeaseHolder) を選択
    ● Log Replication
    ○ 操作列について合意し LeaseHolder の状態を複製

    View Slide

  22. View Slide

  23. (LH = LeaseHolder)

    View Slide

  24. k1 = v1
    PUT k1 = v1 (k1 ∈ Range 1)

    View Slide

  25. k1 = v1 k1 = v1 k1 = v1

    View Slide

  26. k1 = v1 k1 = v1 k1 = v1
    Ack Success

    View Slide

  27. View Slide

  28. k1 = v1
    PUT k1 = v1 (k1 ∈ Range 1)

    View Slide

  29. k1 = v1
    PUT k1 = v1 (k1 ∈ Range 1)

    View Slide

  30. k1 = v1
    PUT k1 = v1 (k1 ∈ Range 1)
    ● 各 Range は Raft で可用性と一貫性が
    保たれた一塊の DB とみなせる
    ● Range 間にはコミュニケーションの
    仕組みがない

    View Slide

  31. INSERT INTO table VALUES (k1, v1), (k2, v2);

    View Slide

  32. INSERT INTO table VALUES (k1, v1), (k2, v2);
    PUT k1 = v1 + PUT k2 = v2

    View Slide

  33. k1 = v1 k2 = v2

    View Slide

  34. k1 = v1’
    k2 = v2’ (合意待ち)
    k2 = v2

    View Slide

  35. k1 = v1’ k2 = v2
    v1’ + v2 (?)

    View Slide

  36. View Slide

  37. トランザクション管理(本日メイン)

    View Slide

  38. 1. トランザクション開始時、Key-Value データと同様に
    Pending 状態の Transaction Record を書き込む
    2. データを書き込む際は上書きする代わりに、
    Intent と呼ばれるマーカをつけ、Record を参照
    3. 全てのデータ書き込みが成功したら Record の状態を
    Committed に変更することでコミット

    View Slide

  39. k1 = v1 k2 = v2

    View Slide

  40. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending
    Round-1
    Consensus

    View Slide

  41. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending
    Round-1
    Consensus

    View Slide

  42. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = committed
    Round-2
    Consensus

    View Slide

  43. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = committed
    Round-2
    Consensus

    View Slide

  44. 1. データを読み込もうとした際、Intent を見つけたら
    まず対応する Transaction Record の状態を確認
    2. Record が Pending 状態であれば元の値を採用
    3. Record が Committed 状態であれば Intent として
    保持されている値を採用

    View Slide

  45. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending

    View Slide

  46. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending

    View Slide

  47. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending

    View Slide

  48. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = pending
    v1 + v2

    View Slide

  49. ● CockroachDB のアーキテクチャ
    ○ Range ごとに Raft Group を構成し合意
    ● 分散トランザクションの必要性
    ○ SQL に伴う Raft Group をまたいだ操作
    ● Transaction Record による実装
    ○ データ + Transaction Record で 2 回の合意

    View Slide

  50. As a database that prides itself on
    geo-distributed use cases, we must strive
    to reduce the latency incurred by common
    OLTP transactions to near the theoretical
    minimum: the sum of all read latencies plus
    one consensus latency.
    CockroachDB RFC: Parallel Commits

    View Slide

  51. View Slide

  52. How Do Formal Methods Handle the Complexity?

    View Slide

  53. View Slide

  54. 1. DB から現在の Like の個数を取得
    2. ローカルでその値を + 1 する
    3. DB に新しい値を書き戻す

    View Slide

  55. View Slide

  56. 0

    View Slide

  57. 0
    0
    0
    0

    View Slide

  58. 0
    1
    1
    0
    0
    0

    View Slide

  59. 0
    1
    1
    0
    0
    0 1
    1

    View Slide

  60. 0
    1
    1
    0
    0
    0 1
    1

    View Slide

  61. View Slide

  62. 決定的・直線的な振る舞い

    View Slide

  63. 非決定的・木構造的な振る舞い

    View Slide

  64. View Slide

  65. View Slide

  66. ● 並行性の問題
    ○ 動作する順番の全組み合わせを考える必要がある
    ● 故障の問題
    ○ 個々の Node の動作にもランダム性がある
    ● ネットワークの問題
    ○ 通信は遅延・消失し、順番も保証されない

    View Slide

  67. View Slide

  68. View Slide

  69. View Slide

  70. ● 運用環境であえて障害を発生させる
    ○ サービス不能状態に陥らないか
    ○ 意図したリカバリがちゃんと発動するか
    ● 予測困難な「未知なる問題」を炙り出す
    ○ 比較対象となる「通常の動作」を定義
    ○ 障害を注入し、発生した差分から問題を発見

    View Slide

  71. View Slide

  72. View Slide

  73. Formal Methods

    View Slide

  74. ● システムを数学的対象により表現
    ○ 対象として何を選択するかでツールの特性が出る
    ● エンドユーザ視点のメリット
    ○ システムの挙動や仕様を曖昧さなく表現できる
    ○ ケースの抜けや漏れが原理的に生じない
    ○ 実装ではなく仕様・設計に対して検査できる

    View Slide

  75. View Slide

  76. ● AWS DynamoDB
    ○ AWS での最初の採用、後に S3 などにも横展開
    ○ 「ゼロから 2-3 週間で習得可能」
    ○ 「設計をデバッグする」と表現し浸透を図る
    ● Azure Cosmos DB
    ○ 5 つの整合性レベルの仕様を厳密に記述

    View Slide

  77. ● TiDB / TiKV
    ○ Percolator、Multi-Raft Merge、TiCDC など
    ○ Chaos Mesh との両面から分散システムを検証
    ● Elasticsearch
    ○ レプリケーション、クラスタのメタデータ管理
    ○ 「3 日間のモデリングでバグを発見できた」

    View Slide

  78. 形式手法ツール
    TLA+ により「証明」済

    View Slide

  79. ● Temporal Logic of Actions と呼ばれる論理が基盤
    ○ IDE (TLA Toolbox) とセットで配布
    ○ Lamport (Paxos の人) が中心となって開発
    ● システムを状態遷移系として表現
    ○ 擬似プログラミング言語 PlusCal から生成可能
    ○ AWS の事例では PlusCal の有効性を強調

    View Slide

  80. View Slide

  81. View Slide

  82. プロセス alice と bob が並行に動く

    View Slide

  83. ラベルが一つの実行ステップを表し
    その間では他プロセスの割り込みが入る

    View Slide

  84. View Slide

  85. View Slide

  86. 検査したい条件

    View Slide

  87. View Slide

  88. ● 分散システムをテストするのは難しい
    ○ タイミングに依存したバグの再現性
    ● TLA+ による問題の発見
    ○ 状態遷移系を網羅的に探索して条件を確認
    ● TLA+ が使用された事例
    ○ CockroachDB、Cosmos DB、TiDB など

    View Slide

  89. How Does the Protocol Reduce the Latencies?

    View Slide

  90. View Slide

  91. 1. データと Transaction Record を並列で書き込み
    2. ただしこの時点での Record の状態は Staging とし、
    トランザクションに属するキーのリストも付ける
    3. データと Record が合意して戻ってきたら
    クライアントにトランザクション完了通知を出す
    4. 最後に Record の状態を Committed に変更

    View Slide

  92. k1 = v1 k2 = v2

    View Slide

  93. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2
    Round-1
    Consensus

    View Slide

  94. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2
    Round-1
    Consensus

    View Slide

  95. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = committed
    : k1, k2
    Round-2
    Consensus

    View Slide

  96. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = committed
    : k1, k2
    Round-2
    Consensus

    View Slide

  97. View Slide

  98. 1. Intent を発見したら Transaction Record を確認
    2. その Record が Staging だった場合、リストされている
    キーについて Intent が書き込み成功かどうか確認
    3. 全キーが OK なら Record を Committed に変更
    4. まだ書き込まれていないキーを見つけた場合は
    Conflict と判断して Record を Aborted に変更

    View Slide

  99. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  100. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  101. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  102. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = staging
    : k1, k2
    v1’ + v2’

    View Slide

  103. k1 = v1 k2 = v2
    k1 = v1’ (t1) k2 = v2’ (t1)
    t1 = committed
    : k1, k2

    View Slide

  104. View Slide

  105. k1 = v1 k2 = v2
    k1 = v1’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  106. k1 = v1 k2 = v2
    k1 = v1’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  107. k1 = v1 k2 = v2
    k1 = v1’ (t1)
    t1 = staging
    : k1, k2

    View Slide

  108. k1 = v1 k2 = v2
    k1 = v1’ (t1)
    t1 = staging
    : k1, k2
    (No k2 intent)

    View Slide

  109. k1 = v1 k2 = v2
    k1 = v1’ (t1)
    t1 = aborted
    : k1, k2
    v1 + v2

    View Slide

  110. View Slide

  111. ● 暗黙的コミット済み状態(読み取り可能状態)
    ○ Transaction Record が Staging 状態
    ○ かつ全てのキーについて Intent が書き込み成功
    ● 明示的コミット済み状態
    ○ Transaction Record が Committed 状態
    ○ Parallel Commit 導入前と同じ、安全側の条件

    View Slide

  112. View Slide

  113. 論理式の「かつ」

    View Slide

  114. 任意の key ∈ KEYS に対し

    View Slide

  115. ● トランザクション完了通知の正しさ
    ○ 完了通知の際は必ずコミット済みである
    ○ ただし暗黙的コミット済みの段階で構わない
    ● 暗黙的コミット済み状態の妥当性
    ○ 暗黙的にコミットされればいずれ明示的にもされる
    ○ 仮に Node が故障した場合であっても保証したい

    View Slide

  116. ● 安全性 (Safety)
    ○ 何か悪いことが「起こらない」ことを要求
    ○ 実行中、常に有効なアサーションのようなもの
    ● 活性 (Liveness)
    ○ 何か良いことがいつかは「起こる」ことを要求
    ○ 何もしないシステムは無意味なので検証には必須

    View Slide

  117. View Slide

  118. True True
    False False

    View Slide

  119. True
    False
    True True
    False False

    View Slide

  120. View Slide

  121. ● 通常の論理式に以下の記号を追加した体系
    ○ □A:現在の状態から先では常に A が真
    ○ ◇A:現在の状態から A が真になるルートが存在
    ● 状態の「列」に対して真偽が決まる
    ○ 一連の実行の様子に対して条件を定義できる
    ○ 真偽の与え方は CTL、LTL などいくつか存在

    View Slide

  122. View Slide

  123. False
    True

    View Slide

  124. True
    False
    False
    True

    View Slide

  125. View Slide

  126. 安全性

    View Slide

  127. 活性

    View Slide

  128. 一度 A が成立すると
    その後いつか B も成立

    View Slide

  129. View Slide

  130. ● 公平性なし(TLA+ のデフォルト)
    ○ まったく動かない可能性がある
    ● 弱い公平性の仮定(fair をつけた場合)
    ○ 常に動ける状態ならいつか必ず動く
    ● 強い公平性の仮定
    ○ 動ける瞬間が無限回来るならいつか必ず動く

    View Slide

  131. View Slide

  132. トランザクションの持ち主のプロセスが
    任意のタイミングで Stall する

    View Slide

  133. それ以外のプロセスは、動ける状況が続けば
    必ずどこかのタイミングでは動く

    View Slide

  134. View Slide

  135. View Slide

  136. 二つのパターンのうち
    どちらが選ばれるかを両方考えて
    分岐を生成
    / / 更新
    変数に変化無し

    View Slide

  137. 書き込みが成功したパターン
    / / 更新
    変数に変化無し

    View Slide

  138. / / 更新
    変数に変化無し
    書き込みが失敗したパターン

    View Slide

  139. View Slide

  140. View Slide

  141. Key を一つ取り出す際、
    すべての「取り出し方」を
    網羅して分岐を生成

    View Slide

  142. ● 分散システムに特有な非決定的な動作の扱い
    ○ 通信の失敗:成功・失敗でランダムに分岐
    ○ 通信の非順序性:値をランダムに取り出す
    ● E2E テストと違い、実際に実行するわけではない
    ○ 全ての可能性を考慮して状態遷移を分岐させる
    ○ 起こりうる全てのランダム性が考慮できる

    View Slide

  143. ● Parallel Commits のプロトコル
    ○ Staging 状態の導入と Transaction Recovery
    ● 時相論理式の導入
    ○ 時間的な幅を持った実行列に関する仕様を検証
    ● ランダム実行ではなく分岐の網羅
    ○ 障害の際にもプロトコルが正しく動くかを検証

    View Slide

  144. Wrap Up the Session!

    View Slide

  145. ● CockroachDB と Parallel Commit
    ○ 一貫性を保ったままパフォーマンスを改善したい
    ● 分散システムのテスト困難性
    ○ 動作順・故障・通信のランダムネス
    ● 形式手法を利用したシステムの記述や検証
    ○ より厳密な仕様の理解と膨大なパターン網羅

    View Slide

  146. We found that the process of writing this
    specification gave us more confidence in
    the Parallel Commit protocol itself and in
    its integration into CockroachDB.
    Parallel Commits: An Atomic Commit Protocol For
    Globally Distributed Transactions

    View Slide

  147. Presented by チェシャ猫 (@y_taka_23)

    View Slide