形式手法による分散システムの検証 #builderscon / builderscon tokyo 2019

by y_taka_23

Slide 1

Slide 1 text

#builderscon #bc100a #builderscon #bc100a 形式手法による分散システムの検証チェシャ猫 (@y_taka_23) builderscon tokyo 2019 (2019/08/31)

Slide 2

Slide 2 text

#builderscon #bc100a 本日のアジェンダ ● 分散システムの例と問題設定 ● はじめての形式手法 ● 実際のモデリングの様子 ● 分散システムにおける故障の分析

Slide 3

Slide 3 text

#builderscon #bc100a #builderscon #bc100a 分散システムの難しさ Why Are Distributed Systems So Hard? 1

Slide 4

Slide 4 text

#builderscon #bc100a 世はまさに分散システム時代！

Slide 5

Slide 5 text

#builderscon #bc100a とある決済サービスの仕様 ● 統合された決済基盤 ○ 複数の EC サイトから利用される ● 複数の決済手段をサポート ○ 銀行引き落とし / ポイント払い / ギフト券 ○ 各々が別のマイクロサービスとして稼働 ○ 複数の手段に按分して支払うことも可能

Slide 6

Slide 6 text

#builderscon #bc100a 決済サービス 1000 pt ポイント管理 1000 円銀行口座管理 1000 円ギフト券管理

Slide 7

Slide 7 text

#builderscon #bc100a 決済サービス 1000 pt ポイント管理 1000 円銀行口座管理 1000 円ギフト券管理 1000 円分の購入

Slide 8

Slide 8 text

#builderscon #bc100a 決済サービス 1000 pt ポイント管理 1000 円銀行口座管理 1000 円ギフト券管理 - 500 円 - 500 pt

Slide 9

Slide 9 text

#builderscon #bc100a 決済サービス 500 pt ポイント管理 500 円銀行口座管理 1000 円ギフト券管理

Slide 10

Slide 10 text

#builderscon #bc100a 決済サービス 500 pt ポイント管理 500 円銀行口座管理 1000 円ギフト券管理 OK OK

Slide 11

Slide 11 text

#builderscon #bc100a 決済サービス 500 pt ポイント管理 500 円銀行口座管理 1000 円ギフト券管理 OK

Slide 12

Slide 12 text

#builderscon #bc100a もし DB でエラーが発生したら

Slide 13

Slide 13 text

#builderscon #bc100a 決済サービス Error ポイント管理 500 円銀行口座管理 1000 円ギフト券管理

Slide 14

Slide 14 text

#builderscon #bc100a 決済サービス 1000 pt ポイント管理 500 円銀行口座管理 1000 円ギフト券管理 OK Error

Slide 15

Slide 15 text

#builderscon #bc100a 決済サービス 1000 pt ポイント管理 500 円銀行口座管理 1000 円ギフト券管理 OK or Retry?

Slide 16

Slide 16 text

#builderscon #bc100a 雑なマイクロサービス化で簡単にデータの整合性が壊れる

Slide 17

Slide 17 text

#builderscon #bc100a TCC パターン ● 全体を二つのフェイズに分ける ● Try フェイズ ○ あらかじめ更新内容を仮登録させる ● Confirm / Cancel フェイズ ○ 全員から OK が帰って来たら改めて Confirm ○ 一箇所でも失敗した場合は全員 Cancel させる

Slide 18

Slide 18 text

#builderscon #bc100a ポイント管理ギフト券管理銀行口座管理決済サービス

Slide 19

Slide 19 text

#builderscon #bc100a ポイント管理ギフト券管理銀行口座管理決済サービス Try

Slide 20

Slide 20 text

#builderscon #bc100a ポイント管理ギフト券管理銀行口座管理 Reserved 決済サービス Try OK

Slide 21

Slide 21 text

#builderscon #bc100a ポイント管理 Reserved ギフト券管理銀行口座管理 Reserved 決済サービス Try OK

Slide 22

Slide 22 text

#builderscon #bc100a ポイント管理 Reserved ギフト券管理銀行口座管理 Reserved 決済サービス Confirm

Slide 23

Slide 23 text

#builderscon #bc100a ポイント管理 Confirmed ギフト券管理銀行口座管理 Reserved 決済サービス Confirm OK

Slide 24

Slide 24 text

#builderscon #bc100a ポイント管理 Confirmed ギフト券管理銀行口座管理 Confirmed 決済サービス Confirm OK

Slide 25

Slide 25 text

#builderscon #bc100a エラーが発生した場合

Slide 26

Slide 26 text

#builderscon #bc100a ポイント管理 Error ギフト券管理銀行口座管理 Reserved 決済サービス Try Canceled

Slide 27

Slide 27 text

#builderscon #bc100a ポイント管理 Reserved ギフト券管理銀行口座管理 Reserved 決済サービス Cancel

Slide 28

Slide 28 text

#builderscon #bc100a ポイント管理 Canceled ギフト券管理銀行口座管理 Canceled 決済サービス Cancel

Slide 29

Slide 29 text

#builderscon #bc100a buiderscon tokyo 2019「Open SKT: メルペイ開発の裏側」 https://speakerdeck.com/kazegusuri/builderscon-tokyo-2019-open-skt

Slide 30

Slide 30 text

#builderscon #bc100a 分散していても整合性が保てる

Slide 31

Slide 31 text

#builderscon #bc100a #builderscon #bc100a ご清聴ありがとうございました Presented by チェシャ猫 (@y_taka_23)

Slide 32

Slide 32 text

#builderscon #bc100a それで済んだら世界は平和

Slide 33

Slide 33 text

#builderscon #bc100a 本当に大丈夫？ ● 変なタイミングでサーバが死んだら？ ● 実は生きていて遅れて通信してきたら？ ● 通信パケットが欠落したら？ ● 通信パケットの順序が入れ替わったら？ ● 複数の値に対して手続きが交錯したら？

Slide 34

Slide 34 text

#builderscon #bc100a 分散システムは罠だらけ ● 各ノードが非同期に動く ○ 考えるべきパターンが多すぎる ● ノードやネットワークが信頼できない ○ 独立にランダムなタイミングで故障が発生 ● 仕様そのものが複雑になりがち ○ 特定の瞬間ではなく一連の動作が問題になる

Slide 35

Slide 35 text

#builderscon #bc100a 設計開発 / テスト運用

Slide 36

Slide 36 text

#builderscon #bc100a 設計開発 / テスト運用性質の保証が困難

Slide 37

Slide 37 text

#builderscon #bc100a 設計開発 / テスト運用性質の保証が困難

Slide 38

Slide 38 text

#builderscon #bc100a Chaos Engineering ● 運用環境であえて障害を発生させる ○ サービス不能状態に陥らないか ○ 障害状態から正しく復旧できるか ● 隠れていた問題点が炙り出せる ○ 安定状態を「正しい」として差分を解析 ○ 意図して発生させることが難しいバグも見つかる

Slide 39

Slide 39 text

#builderscon #bc100a 第 1 章のまとめ ● ナイーブな分散システムは危険 ○ 整合性を保つビルトイン機能に頼れない ● 分散システムは考えることが多すぎる ○ 実際に動かさずにテストするのは非現実的 ● 実際に動かしてテストする手も ○ 故障を注入することで問題点を発見する

Slide 40

Slide 40 text

#builderscon #bc100a 設計開発 / テスト運用性質の保証が困難 ???

Slide 41

Slide 41 text

#builderscon #bc100a #builderscon #bc100a 一つの答えは「形式手法」

Slide 42

Slide 42 text

#builderscon #bc100a #builderscon #bc100a 形式手法を覗いてみよう Hello, Formal Methods! 2

Slide 43

Slide 43 text

#builderscon #bc100a 形式手法とは ● システムを数学的対象により表現 ○ その対象の性質に基づいて検証を行う ○ 対象として何を選ぶかでツールの性質が決まる ● 通常のテストと比較すると ○ テストケースの抜けや漏れが生じない ○ 実装ではなく仕様・設計に対して検査できる

Slide 44

Slide 44 text

#builderscon #bc100a 形式手法の分類 ● モデル検査 ○ システムが取りうる値を列挙して探索 ○ 有限個のパターンに収まれば自動化できる ● 定理証明 ○ いわゆる数学的な証明をプログラム的に表現 ○ 真に無限個の入力を扱うことができる

Slide 45

Slide 45 text

#builderscon #bc100a TLA+ https://lamport.azurewebsites.net/tla/tla.html

Slide 46

Slide 46 text

#builderscon #bc100a TLA+ の特徴 ● モデル検査系のツール ○ 多機能な IDE とセットになっている ○ Lamport (Paxos の人) が中心となって開発 ○ Temporal Logic of Actions と呼ばれる論理が基盤 ● システムを状態遷移系として定式化 ○ 起こりうる動作の前後で成り立つ関係を記述

Slide 47

Slide 47 text

#builderscon #bc100a TLA+ は目を引く事例が豊富

Slide 48

Slide 48 text

#builderscon #bc100a TLA+ の採用事例 ● AWS DynamoDB、S3 ○ https://dl.acm.org/citation.cfm?id=2699417 ● CockroachDB の並列コミット ○ https://github.com/cockroachdb/cockroach/tree/master/docs/tla-plus ● FINAL FANTASY XV POCKET EDITION ○ DynamoDB の結果整合性が許容できるかどうか検査 ○ https://d1.awsstatic.com/events/jp/2018/summit/tokyo/customer/37.pdf

Slide 49

Slide 49 text

#builderscon #bc100a サンプル：LampLighter ● まず非常に単純なシステムを考える ● フラグが一つだけ存在する ○ 変数名は lamp とする ● プロセスが一つだけ稼働している ○ 断続的にフラグを反転させる ○ 式で書けば lamp = ~ lamp

Slide 50

Slide 50 text

#builderscon #bc100a lamp: true lamp: false lamp’ = ~ lamp lamp’ = ~ lamp

Slide 51

Slide 51 text

#builderscon #bc100a VARIABLE lamp (* 初期状態 *) Init == lamp = TRUE (* 状態遷移時の関係 *) Next == lamp' = ~ lamp

Slide 52

Slide 52 text

#builderscon #bc100a サンプル：TwinLighter ● フラグが二つ存在する ○ 変数名は lamp1 と lamp2 とする ● プロセスが二つ並行して稼働している ○ それぞれ P1 と P2 とする ○ P1 は lamp1 を、P2 は lamp2 を反転させる ○ ただし同時には片方しか動かない

Slide 53

Slide 53 text

#builderscon #bc100a lamp1: false lamp2: true lamp1: false lamp2: false lamp1: true lamp2: true lamp1: true lamp2: false

Slide 54

Slide 54 text

#builderscon #bc100a VARIABLES lamp1, lamp2 (* 初期状態 *) Init == lamp1 = TRUE /\ lamp2 = TRUE (* 状態遷移時の関係 *) Next == lamp1' = ~ lamp1 \/ lamp2' = ~ lamp2

Slide 55

Slide 55 text

#builderscon #bc100a VARIABLES lamp1, lamp2 (* 初期状態 *) Init == lamp1 = TRUE /\ lamp2 = TRUE (* 状態遷移時の関係 *) Next == lamp1' = ~ lamp1 \/ lamp2' = ~ lamp2 状態 : 各パーツの論理積

Slide 56

Slide 56 text

#builderscon #bc100a VARIABLES lamp1, lamp2 (* 初期状態 *) Init == lamp1 = TRUE /\ lamp2 = TRUE (* 状態遷移時の関係 *) Next == lamp1' = ~ lamp1 \/ lamp2' = ~ lamp2 遷移 : 各パーツの論理和

Slide 57

Slide 57 text

#builderscon #bc100a この調子で書くの辛くない？

Slide 58

Slide 58 text

#builderscon #bc100a PlusCal の使用 ● 生の TLA+ を書くのは人間には辛い ○ というか「分散システムの難しさ」そのもの ● 付属の DSL “PlusCal” からコード生成 ○ Pascal 風の記法と C 言語風の記法がある ● AWS の事例では重要な役割を果たした ○ 現場のプログラマへの心理的障壁を下げる

Slide 59

Slide 59 text

#builderscon #bc100a --algorithm LampLighter process P \in { 1,2 } variable lamp = TRUE; begin while TRUE do lamp := ~lamp; end while; end process end algorithm

Slide 60

Slide 60 text

#builderscon #bc100a --algorithm LampLighter process P \in { 1,2 } variable lamp = TRUE; begin while TRUE do lamp := ~lamp; end while; end process end algorithm 普通のループっぽい記法

Slide 61

Slide 61 text

#builderscon #bc100a --algorithm LampLighter process P \in { 1,2 } variable lamp = TRUE; begin while TRUE do lamp := ~lamp; end while; end process end algorithm 複数プロセスの生成

Slide 62

Slide 62 text

#builderscon #bc100a 第 2 章のまとめ ● 形式手法 ○ システムを数学的な対象にマッピング ○ 大きく分けて定理証明とモデル検査がある ● 今回は TLA+ をモデル検査器として使用 ○ 国内含み、興味深い産業界の事例がある ○ PlusCal により「数学」は気にならない

Slide 63

Slide 63 text

#builderscon #bc100a #builderscon #bc100a 分散システムのモデリング Model Our System With TLA+ 3 参考文献：http://muratbuffalo.blogspot.com/2018/12/2-phase-commit-and-beyond.html

Slide 64

Slide 64 text

#builderscon #bc100a ポイント管理ギフト券管理銀行口座管理決済サービス

Slide 65

Slide 65 text

#builderscon #bc100a fair algorithm TCC fair process Payment = 0 begin (* 決済サービス側の挙動 *) end process fair process Method \in METHOD begin (* 各決済手段側の挙動 *) end process end algorithm

Slide 66

Slide 66 text

Slide 67

Slide 67 text

#builderscon #bc100a 決済サービスの仕様 ● まず Try リクエストを出す ○ モデリングは Try した状態でスタート ● 確定なら Confirm を指示 ○ 全員が準備 OK 状態になった場合 ● 取り消すなら Cancel の指示 ○ 一人でも準備 OK にならなかった場合

Slide 68

Slide 68 text

#builderscon #bc100a ポイント管理 reserved ポイント管理 reserved ポイント管理 reserved 決済サービス try -> confirm

Slide 69

Slide 69 text

#builderscon #bc100a ポイント管理 canceled ポイント管理 reserved ポイント管理 reserved 決済サービス try -> cancel

Slide 70

Slide 70 text

#builderscon #bc100a try cancel confirm

Slide 71

Slide 71 text

#builderscon #bc100a try cancel confirm 全員 reserved

Slide 72

Slide 72 text

#builderscon #bc100a try cancel confirm 一人でも canceled

Slide 73

Slide 73 text

#builderscon #bc100a variables paymentState = "try"; fair process Payment = 0 begin either (* confirm リクエスト発行 *) await canConfirm; paymentState := "confirm"; or (* cancel リクエスト発行 *) await canCancel; paymentState := "cancel"; end either; end process

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

#builderscon #bc100a define (* 全員が準備 OK なら確定できる *) canConfirm == \A m \in METHOD : methodState[m] \in {"reserved"} (* ひとりでもキャンセルされていればキャンセルできる *) canCancel == \E m \in METHOD : methodState[m] \in {"canceled"} end define

Slide 77

Slide 77 text

Slide 78

Slide 78 text

#builderscon #bc100a 決済手段サービスの仕様 ● Try に対して準備動作を行う ○ 待機状態の時 Try を受信すると準備状態に ● Confirm に対して確定動作を行う ○ 自分が準備状態なら確定する動作が可能 ● Cancel に対してキャンセル操作を行う ○ さらに自分自身が失敗した場合もキャンセル

Slide 79

Slide 79 text

#builderscon #bc100a idling confirmed reserved canceled

Slide 80

Slide 80 text

#builderscon #bc100a idling confirmed reserved canceled try 受信

Slide 81

Slide 81 text

#builderscon #bc100a idling confirmed reserved canceled confirm 受信

Slide 82

Slide 82 text

#builderscon #bc100a idling confirmed reserved canceled cancel 受信

Slide 83

Slide 83 text

#builderscon #bc100a idling confirmed reserved canceled cancel 受信または自分が失敗

Slide 84

Slide 84 text

#builderscon #bc100a variables mathodState = [ m \in METHOD |-> "idling" ]; fair process Method \in METHOD begin while methodState[self] in {"idling", "reserved"} do either (* idling -> reserved : 次ページ*) or (* reserved -> confirm : 次ページ *) or (* x -> canceled : 次ページ *) end either; end while; end process

Slide 85

Slide 85 text

Slide 86

Slide 86 text

#builderscon #bc100a either (* idling -> reserved *) await methodState[self] = "idling"; methodState[self] := "reserved"; or (* reserved -> confirmed *) await methodState[self] = "reserved" /\ paymentState = "confirm"; methodState[self] := "confirmed"; or (* x -> canceled : 次ページ *) end either;

Slide 87

Slide 87 text

Slide 88

Slide 88 text

#builderscon #bc100a either (snip...) or (* x -> canceled *) await methodState[self] = "idling" \/ (methodState[self] = "reserved" /\ paymentState = "cancel"); methodState[self] := "canceled" end either;

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Slide 91

Slide 91 text

#builderscon #bc100a さて、それで何が知りたい？

Slide 92

Slide 92 text

#builderscon #bc100a 検証したい TCC の性質 ● トランザクションとしての一貫性 ○ Confirmed と Canceled が混在しないか？ ○ 混在すると不整合が発生する ● 一連の手続きが完了する保証 ○ いつかは Confirmed もしくは Canceled になる？ ○ デッドロックや無限ループに陥りたくない

Slide 93

Slide 93 text

#builderscon #bc100a 安全性と活性 ● 安全性 (Safety) ○ 何か悪い状況が「起こらない」ことを要求 ○ 通常の言語のアサーションに近い ● 活性 (Liveness) ○ 何か期待することが「起こる」ことを要求 ○ 何もしないシステムは無意味なので検証に必須

Slide 94

Slide 94 text

#builderscon #bc100a A A 「A が成り立つか？」: 「いずれ A が成り立つか？」: A

Slide 95

Slide 95 text

#builderscon #bc100a A A 「A が成り立つか？」: 状態に対する条件「いずれ A が成り立つか？」: A true false true false

Slide 96

Slide 96 text

#builderscon #bc100a A A 「A が成り立つか？」: 状態に対する条件「いずれ A が成り立つか？」: 状態列に対する条件 A true false true false true false

Slide 97

Slide 97 text

#builderscon #bc100a 普通の条件式では書けない

Slide 98

Slide 98 text

#builderscon #bc100a 時相論理 (Temporal Logic) ● 通常の論理式に記号を追加した体系 ○ [] A : 現時点以降、常に A が成り立つ ○ <> A : 現時点以降、いずれ A が成り立つ ● 状態の「列」に対して真偽を判定 ○ 時間的な幅がある実行パスの性質に言明できる ○ 真偽の与え方は何種類か (CTL, LTL など) 存在

Slide 99

Slide 99 text

#builderscon #bc100a <> A : 現時点以降、いずれは A が成り立つ A true false [] A : 現時点以降、常に A が成り立つ A A A A A false true

Slide 100

Slide 100 text

#builderscon #bc100a (* 確定されたになった決済手段と *) (* キャンセルになった決済手段が混在しない *) Consistency == \A m1, m2 \in METHOD : ~ (methodState[m1] = "confirmed" /\ methodState[m2] = "canceled") (* どの決済手段もいつかは確定もしくはキャンセルになる *) Completed == <>(\A m \in METHOD : methodState[m] \in {"confirmed", "canceled"})

Slide 101

Slide 101 text

Slide 102

Slide 102 text

#builderscon #bc100a No errors!

Slide 103

Slide 103 text

#builderscon #bc100a 検証したい TCC の性質（再掲） ● トランザクションとしての一貫性 ○ Confirmed と Canceled が混在しないか？ ○ 混在すると不整合が発生する ● 一連の手続きが完了する保証 ○ いつかは Confirmed もしくは Canceled になる？ ○ デッドロックや無限ループに陥りたくない

Slide 104

Slide 104 text

#builderscon #bc100a 第 3 章のまとめ ● TLA+ による TCC のモデリング ○ 一つ一つのコンポーネントごとに記述 ○ どんな条件のときどんな動きをし得るかを整理 ● 時相論理による検証 ○ Confirmed と Canceled の両方は生じない ○ いつかは Confirmed / Canceled のいずれかになる

Slide 105

Slide 105 text

#builderscon #bc100a #builderscon #bc100a 分散システムと故障 Detect Failure in Pre-Runtime 4

Slide 106

Slide 106 text

#builderscon #bc100a 決済サービスが SPoF では？

Slide 107

Slide 107 text

#builderscon #bc100a 決済サービスの故障 ● 先ほどのモデリングは故障しない仮定 ○ 分散システムの難しさが十分見えない ○ 分散システムは故障を考慮してこその華 ● Confirm または Cancel 命令後に故障 ○ 故障後はいかなる命令も出さなくなる ○ 故障後はずっと故障していて、復旧はしない

Slide 108

Slide 108 text

#builderscon #bc100a try cancel confirm

Slide 109

Slide 109 text

#builderscon #bc100a try cancel confirm crash

Slide 110

Slide 110 text

#builderscon #bc100a Error!

Slide 111

Slide 111 text

#builderscon #bc100a エラートレースの内容 1. Try 命令が出されている状態 2. 決済手段サーバ 1 -> 2 -> 3 の順で Try が到達し、 3 台とも Reserved 状態に 3. 決済サーバが Confirm 命令を出す 4. 直後に決済サーバが故障して沈黙 5. Confirm 命令は決済手段サーバに到達せず 6. 決済手段サーバが Reserved のままデッドロックに

Slide 112

Slide 112 text

#builderscon #bc100a 性質の良いシステム性質の悪いシステム

Slide 113

Slide 113 text

#builderscon #bc100a 故障しない性質の良いシステム性質の悪いシステム

Slide 114

Slide 114 text

#builderscon #bc100a 故障しない性質の良いシステム Crash-Stop 故障 : 故障後、完全に沈黙性質の悪いシステム

Slide 115

Slide 115 text

#builderscon #bc100a 故障しない性質の良いシステム Crash-Stop 故障 : 故障後、完全に沈黙 Crash-Recovery 故障 : 故障後、復活の可能性性質の悪いシステム

Slide 116

Slide 116 text

#builderscon #bc100a 故障しない性質の良いシステム Crash-Stop 故障 : 故障後、完全に沈黙 Crash-Recovery 故障 : 故障後、復活の可能性ビザンチン故障：サーバが嘘をつく可能性性質の悪いシステム

Slide 117

Slide 117 text

#builderscon #bc100a SPoF なら冗長化できないか？

Slide 118

Slide 118 text

#builderscon #bc100a フェイルオーバによる冗長化 ● 決済サービスの代替サーバを準備 ○ 代替サーバは故障しないと仮定する ● 代替サーバの仕様 ○ 決済サービス本体が故障に陥っていないか監視 ○ 本体が正常なら何もしない ○ 故障した場合は代わりに Confirm / Cancel 命令

Slide 119

Slide 119 text

#builderscon #bc100a ポイント管理 reserved ギフト券管理 reserved 銀行口座管理 reserved 決済サービス crash 代替サーバ

Slide 120

Slide 120 text

#builderscon #bc100a ポイント管理 reserved ギフト券管理 reserved 銀行口座管理 reserved 決済サービス crash -> confirm 代替サーバ

Slide 121

Slide 121 text

#builderscon #bc100a ポイント管理 confirmed ギフト券管理 confirmed 銀行口座管理 confirmed 決済サービス confirm 代替サーバ

Slide 122

Slide 122 text

#builderscon #bc100a crash cancel confirm

Slide 123

Slide 123 text

#builderscon #bc100a crash cancel confirm 全員 reserved

Slide 124

Slide 124 text

#builderscon #bc100a crash cancel confirm 一人でも canceled

Slide 125

Slide 125 text

#builderscon #bc100a Error!

Slide 126

Slide 126 text

#builderscon #bc100a エラートレースの内容 1. Try 命令が出されている状態 2. 決済手段サーバ 1 -> 2 -> 3 の順で Try が到達し、3 台とも Reserved 状態に 3. 決済サーバが Confirm 命令を出す 4. 直後に決済サーバが故障して沈黙 5. Confirm 命令は決済手段サーバ 1 にのみ到達し、決済手段サーバ 1 のみが Confirmed 状態に 6. 「全員が Reserved」ではないので代替サーバは動けず

Slide 127

Slide 127 text

#builderscon #bc100a crash cancel confirm 全員 reserved

Slide 128

Slide 128 text

#builderscon #bc100a crash cancel confirm 全員 reserved もしくは最低一人 confirmed が存在

Slide 129

Slide 129 text

#builderscon #bc100a No errors!

Slide 130

Slide 130 text

#builderscon #bc100a 第 4 章のまとめ ● 分散システムは故障時の挙動が重要 ○ 正常系よりもずっとパターンが豊富 ○ そもそもそれが分散アルゴリズムの存在意義 ● TLA+ による検査 ○ 全探索により、仕様に合わない検出 ○ 人間がぱっと思いつかない条件の漏れを指摘

Slide 131

Slide 131 text

#builderscon #bc100a #builderscon #bc100a 本日のまとめ Conclusion 5

Slide 132

Slide 132 text

#builderscon #bc100a 本日のまとめ ● 分散システムの設計は難しい ○ すべての場合を網羅して考慮するのが困難 ● 形式手法を用いて検証が可能 ○ モデル検査によるシステム状態の探索 ● 様々な実行パターンに関する検証 ○ 長く複雑な実行パスであっても自動で検出できる

Slide 133

Slide 133 text

#builderscon #bc100a #builderscon #bc100a Think Formally, Act Theoretically! Presented by チェシャ猫 (@y_taka_23)