Slide 1
Slide 1 text
チェシャ猫 (@y_taka_23)
July Tech Festa 2021 Winter (24th Jan. 2021)
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
形式手法ツール
TLA+ により「証明」済
Slide 4
Slide 4 text
● CockroachDB の概要
○ スケーラビリティを実現するアーキテクチャ
○ 生じた課題と Parallel Commit による解決
● 形式手法ツール TLA+ の概要
○ 理論はともかく、ツールとしての雰囲気
○ CockroachDB の挙動をどう表現・検証するか
Slide 5
Slide 5 text
How Does CockroachDB Construct Transactions?
Slide 6
Slide 6 text
● Spanner 系の分散データベース
○ インタフェースとして SQL をサポート
○ 強い一貫性を持ったトランザクションをサポート
○ 旧来の RDB と異なりスケールアウト可能
● データは Node 間で冗長化される
○ 一定規模以下の Node 障害時でもデータを守れる
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
クライアントから見た
処理の流れ
Slide 9
Slide 9 text
SQL を Key-Value 命令に変換
トランザクション管理（本日メイン）
適切な Node に命令をルーティング
Node 間でデータを冗長化
データをディスクに永続化（省略）
Slide 10
Slide 10 text
SQL を Key-Value 命令に変換
Slide 11
Slide 11 text
id (PK) author like
1 alice 4
2 alice 8
3 bob 5
Slide 12
Slide 12 text
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
Slide 13
Slide 13 text
適切な Node に命令をルーティング
Slide 14
Slide 14 text
key value
Slide 15
Slide 15 text
key value
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
PUT k1 = v1 (k1 ∈ Range 1)
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
Node 間でデータを冗長化
Slide 21
Slide 21 text
● 合意 (Consensus) プロトコル
○ 一度、合意が得られればその値は覆らない
● Leader Election
○ 見本となる Node (Leader, LeaseHolder) を選択
● Log Replication
○ 操作列について合意し LeaseHolder の状態を複製
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
(LH = LeaseHolder)
Slide 24
Slide 24 text
k1 = v1
PUT k1 = v1 (k1 ∈ Range 1)
Slide 25
Slide 25 text
k1 = v1 k1 = v1 k1 = v1
Slide 26
Slide 26 text
k1 = v1 k1 = v1 k1 = v1
Ack Success
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
k1 = v1
PUT k1 = v1 (k1 ∈ Range 1)
Slide 29
Slide 29 text
k1 = v1
PUT k1 = v1 (k1 ∈ Range 1)
Slide 30
Slide 30 text
k1 = v1
PUT k1 = v1 (k1 ∈ Range 1)
● 各 Range は Raft で可用性と一貫性が
保たれた一塊の DB とみなせる
● Range 間にはコミュニケーションの
仕組みがない
Slide 31
Slide 31 text
INSERT INTO table VALUES (k1, v1), (k2, v2);
Slide 32
Slide 32 text
INSERT INTO table VALUES (k1, v1), (k2, v2);
PUT k1 = v1 + PUT k2 = v2
Slide 33
Slide 33 text
k1 = v1 k2 = v2
Slide 34
Slide 34 text
k1 = v1’
k2 = v2’ (合意待ち)
k2 = v2
Slide 35
Slide 35 text
k1 = v1’ k2 = v2
v1’ + v2 (?)
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
トランザクション管理（本日メイン）
Slide 38
Slide 38 text
1. トランザクション開始時、Key-Value データと同様に
Pending 状態の Transaction Record を書き込む
2. データを書き込む際は上書きする代わりに、
Intent と呼ばれるマーカをつけ、Record を参照
3. 全てのデータ書き込みが成功したら Record の状態を
Committed に変更することでコミット
Slide 39
Slide 39 text
k1 = v1 k2 = v2
Slide 40
Slide 40 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
Round-1
Consensus
Slide 41
Slide 41 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
Round-1
Consensus
Slide 42
Slide 42 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = committed
Round-2
Consensus
Slide 43
Slide 43 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = committed
Round-2
Consensus
Slide 44
Slide 44 text
1. データを読み込もうとした際、Intent を見つけたら
まず対応する Transaction Record の状態を確認
2. Record が Pending 状態であれば元の値を採用
3. Record が Committed 状態であれば Intent として
保持されている値を採用
Slide 45
Slide 45 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
Slide 46
Slide 46 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
Slide 47
Slide 47 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
Slide 48
Slide 48 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = pending
v1 + v2
Slide 49
Slide 49 text
● CockroachDB のアーキテクチャ
○ Range ごとに Raft Group を構成し合意
● 分散トランザクションの必要性
○ SQL に伴う Raft Group をまたいだ操作
● Transaction Record による実装
○ データ + Transaction Record で 2 回の合意
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
How Do Formal Methods Handle the Complexity?
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
1. DB から現在の Like の個数を取得
2. ローカルでその値を + 1 する
3. DB に新しい値を書き戻す
Slide 55
Slide 55 text
No content
Slide 56
Slide 56 text
0
Slide 57
Slide 57 text
0
0
0
0
Slide 58
Slide 58 text
0
1
1
0
0
0
Slide 59
Slide 59 text
0
1
1
0
0
0 1
1
Slide 60
Slide 60 text
0
1
1
0
0
0 1
1
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
決定的・直線的な振る舞い
Slide 63
Slide 63 text
非決定的・木構造的な振る舞い
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
No content
Slide 66
Slide 66 text
● 並行性の問題
○ 動作する順番の全組み合わせを考える必要がある
● 故障の問題
○ 個々の Node の動作にもランダム性がある
● ネットワークの問題
○ 通信は遅延・消失し、順番も保証されない
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
No content
Slide 70
Slide 70 text
● 運用環境であえて障害を発生させる
○ サービス不能状態に陥らないか
○ 意図したリカバリがちゃんと発動するか
● 予測困難な「未知なる問題」を炙り出す
○ 比較対象となる「通常の動作」を定義
○ 障害を注入し、発生した差分から問題を発見
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
No content
Slide 73
Slide 73 text
Formal Methods
Slide 74
Slide 74 text
● システムを数学的対象により表現
○ 対象として何を選択するかでツールの特性が出る
● エンドユーザ視点のメリット
○ システムの挙動や仕様を曖昧さなく表現できる
○ ケースの抜けや漏れが原理的に生じない
○ 実装ではなく仕様・設計に対して検査できる
Slide 75
Slide 75 text
No content
Slide 76
Slide 76 text
● AWS DynamoDB
○ AWS での最初の採用、後に S3 などにも横展開
○ 「ゼロから 2-3 週間で習得可能」
○ 「設計をデバッグする」と表現し浸透を図る
● Azure Cosmos DB
○ 5 つの整合性レベルの仕様を厳密に記述
Slide 77
Slide 77 text
● TiDB / TiKV
○ Percolator、Multi-Raft Merge、TiCDC など
○ Chaos Mesh との両面から分散システムを検証
● Elasticsearch
○ レプリケーション、クラスタのメタデータ管理
○ 「3 日間のモデリングでバグを発見できた」
Slide 78
Slide 78 text
形式手法ツール
TLA+ により「証明」済
Slide 79
Slide 79 text
● Temporal Logic of Actions と呼ばれる論理が基盤
○ IDE (TLA Toolbox) とセットで配布
○ Lamport (Paxos の人) が中心となって開発
● システムを状態遷移系として表現
○ 擬似プログラミング言語 PlusCal から生成可能
○ AWS の事例では PlusCal の有効性を強調
Slide 80
Slide 80 text
No content
Slide 81
Slide 81 text
No content
Slide 82
Slide 82 text
プロセス alice と bob が並行に動く
Slide 83
Slide 83 text
ラベルが一つの実行ステップを表し
その間では他プロセスの割り込みが入る
Slide 84
Slide 84 text
No content
Slide 85
Slide 85 text
No content
Slide 86
Slide 86 text
検査したい条件
Slide 87
Slide 87 text
No content
Slide 88
Slide 88 text
● 分散システムをテストするのは難しい
○ タイミングに依存したバグの再現性
● TLA+ による問題の発見
○ 状態遷移系を網羅的に探索して条件を確認
● TLA+ が使用された事例
○ CockroachDB、Cosmos DB、TiDB など
Slide 89
Slide 89 text
How Does the Protocol Reduce the Latencies?
Slide 90
Slide 90 text
No content
Slide 91
Slide 91 text
1. データと Transaction Record を並列で書き込み
2. ただしこの時点での Record の状態は Staging とし、
トランザクションに属するキーのリストも付ける
3. データと Record が合意して戻ってきたら
クライアントにトランザクション完了通知を出す
4. 最後に Record の状態を Committed に変更
Slide 92
Slide 92 text
k1 = v1 k2 = v2
Slide 93
Slide 93 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
Round-1
Consensus
Slide 94
Slide 94 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
Round-1
Consensus
Slide 95
Slide 95 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = committed
: k1, k2
Round-2
Consensus
Slide 96
Slide 96 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = committed
: k1, k2
Round-2
Consensus
Slide 97
Slide 97 text
No content
Slide 98
Slide 98 text
1. Intent を発見したら Transaction Record を確認
2. その Record が Staging だった場合、リストされている
キーについて Intent が書き込み成功かどうか確認
3. 全キーが OK なら Record を Committed に変更
4. まだ書き込まれていないキーを見つけた場合は
Conflict と判断して Record を Aborted に変更
Slide 99
Slide 99 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
Slide 100
Slide 100 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
Slide 101
Slide 101 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
Slide 102
Slide 102 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = staging
: k1, k2
v1’ + v2’
Slide 103
Slide 103 text
k1 = v1 k2 = v2
k1 = v1’ (t1) k2 = v2’ (t1)
t1 = committed
: k1, k2
Slide 104
Slide 104 text
No content
Slide 105
Slide 105 text
k1 = v1 k2 = v2
k1 = v1’ (t1)
t1 = staging
: k1, k2
Slide 106
Slide 106 text
k1 = v1 k2 = v2
k1 = v1’ (t1)
t1 = staging
: k1, k2
Slide 107
Slide 107 text
k1 = v1 k2 = v2
k1 = v1’ (t1)
t1 = staging
: k1, k2
Slide 108
Slide 108 text
k1 = v1 k2 = v2
k1 = v1’ (t1)
t1 = staging
: k1, k2
(No k2 intent)
Slide 109
Slide 109 text
k1 = v1 k2 = v2
k1 = v1’ (t1)
t1 = aborted
: k1, k2
v1 + v2
Slide 110
Slide 110 text
No content
Slide 111
Slide 111 text
● 暗黙的コミット済み状態（読み取り可能状態）
○ Transaction Record が Staging 状態
○ かつ全てのキーについて Intent が書き込み成功
● 明示的コミット済み状態
○ Transaction Record が Committed 状態
○ Parallel Commit 導入前と同じ、安全側の条件
Slide 112
Slide 112 text
No content
Slide 113
Slide 113 text
論理式の「かつ」
Slide 114
Slide 114 text
任意の key ∈ KEYS に対し
Slide 115
Slide 115 text
● トランザクション完了通知の正しさ
○ 完了通知の際は必ずコミット済みである
○ ただし暗黙的コミット済みの段階で構わない
● 暗黙的コミット済み状態の妥当性
○ 暗黙的にコミットされればいずれ明示的にもされる
○ 仮に Node が故障した場合であっても保証したい
Slide 116
Slide 116 text
● 安全性 (Safety)
○ 何か悪いことが「起こらない」ことを要求
○ 実行中、常に有効なアサーションのようなもの
● 活性 (Liveness)
○ 何か良いことがいつかは「起こる」ことを要求
○ 何もしないシステムは無意味なので検証には必須
Slide 117
Slide 117 text
No content
Slide 118
Slide 118 text
True True
False False
Slide 119
Slide 119 text
True
False
True True
False False
Slide 120
Slide 120 text
No content
Slide 121
Slide 121 text
● 通常の論理式に以下の記号を追加した体系
○ □A：現在の状態から先では常に A が真
○ ◇A：現在の状態から A が真になるルートが存在
● 状態の「列」に対して真偽が決まる
○ 一連の実行の様子に対して条件を定義できる
○ 真偽の与え方は CTL、LTL などいくつか存在
Slide 122
Slide 122 text
No content
Slide 123
Slide 123 text
False
True
Slide 124
Slide 124 text
True
False
False
True
Slide 125
Slide 125 text
No content
Slide 126
Slide 126 text
安全性
Slide 127
Slide 127 text
活性
Slide 128
Slide 128 text
一度 A が成立すると
その後いつか B も成立
Slide 129
Slide 129 text
No content
Slide 130
Slide 130 text
● 公平性なし（TLA+ のデフォルト）
○ まったく動かない可能性がある
● 弱い公平性の仮定（fair をつけた場合）
○ 常に動ける状態ならいつか必ず動く
● 強い公平性の仮定
○ 動ける瞬間が無限回来るならいつか必ず動く
Slide 131
Slide 131 text
No content
Slide 132
Slide 132 text
トランザクションの持ち主のプロセスが
任意のタイミングで Stall する
Slide 133
Slide 133 text
それ以外のプロセスは、動ける状況が続けば
必ずどこかのタイミングでは動く
Slide 134
Slide 134 text
No content
Slide 135
Slide 135 text
No content
Slide 136
Slide 136 text
二つのパターンのうち
どちらが選ばれるかを両方考えて
分岐を生成
/ / 更新
変数に変化無し
Slide 137
Slide 137 text
書き込みが成功したパターン
/ / 更新
変数に変化無し
Slide 138
Slide 138 text
/ / 更新
変数に変化無し
書き込みが失敗したパターン
Slide 139
Slide 139 text
No content
Slide 140
Slide 140 text
No content
Slide 141
Slide 141 text
Key を一つ取り出す際、
すべての「取り出し方」を
網羅して分岐を生成
Slide 142
Slide 142 text
● 分散システムに特有な非決定的な動作の扱い
○ 通信の失敗：成功・失敗でランダムに分岐
○ 通信の非順序性：値をランダムに取り出す
● E2E テストと違い、実際に実行するわけではない
○ 全ての可能性を考慮して状態遷移を分岐させる
○ 起こりうる全てのランダム性が考慮できる
Slide 143
Slide 143 text
● Parallel Commits のプロトコル
○ Staging 状態の導入と Transaction Recovery
● 時相論理式の導入
○ 時間的な幅を持った実行列に関する仕様を検証
● ランダム実行ではなく分岐の網羅
○ 障害の際にもプロトコルが正しく動くかを検証
Slide 144
Slide 144 text
Wrap Up the Session!
Slide 145
Slide 145 text
● CockroachDB と Parallel Commit
○ 一貫性を保ったままパフォーマンスを改善したい
● 分散システムのテスト困難性
○ 動作順・故障・通信のランダムネス
● 形式手法を利用したシステムの記述や検証
○ より厳密な仕様の理解と膨大なパターン網羅
Slide 146
Slide 146 text
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
Slide 147
Slide 147 text
Presented by チェシャ猫 (@y_taka_23)