形式手法と AWS のおいしい関係。- モデル検査器 Alloy によるインフラ設計技法 #jawsfesta

形式手法と AWS のおいしい関係。- モデル検査器 Alloy によるインフラ設計技法 #jawsfesta

1. 1. 形式手法と AWS の おいしい関係。 チェシャ猫 (@y_taka_23) JAWS Festa 東海道 2016 (2016/10/22) モデル検査器 Alloy によるインフラ設計技法
2. 2. AWS で「やっちまった」こと ありませんか？
3. 3. 本日の目次 1. インフラ設計、この厄介なるもの 2. 形式手法、この深淵なるもの 3. Alloy、この強力なるもの 4. モデリング・ケーススタディ 5. まとめ
4. 4. 1 インフラ設計、この厄介なるもの 問題を複雑にしている要因は そもそもどこにあるのか？
5. 5. インフラ設計の難しさ ▪ 長期間に渡って使用される ▫ 当初の想定に反する事態になりやすい ▫ 設計意図が引き継がれにくい ▪ 変更時の影響範囲が大きい ▫ 一部分のみの再設計が困難 ▪ 構成要素が多く、系として複雑 ▫ 全体を正しく把握しないと動かせない
6. 6. AWS をテストする手法たち ▪ awspec ▫ RSpec 形式で AWS リソースをテスト ▫ API にアクセスしてリソースの情報を取得 ▪ AWS Config Rules ▫ 設定の変更履歴を追跡 ▫ 条件を満たさないリソースを監視 ▫ Lambda でカスタムルール作成可能
7. 7. 実物に依存せず 「設計」に対して試行錯誤したい
8. 8. 形式手法 Formal Methods
9. 9. 2 形式手法、この深淵なるもの 数理的手法を応用することで 何が得られるのか？
10. 10. 形式手法とは ▪ システムを数学的対象として表現 ▫ 選んだ対象によって特性が変わる ▪ 数学的対象に関する理論を用いて検証 ▪ いわゆるテストと比較して ▫ より抽象的な設計を検証できる ▫ テストケースの漏れが生じない ▫ 一般的には学習コストが高い（なじみがない）
11. 11. 様々な形式手法ツール ▪ 形式仕様記述 : Z、VDM++ ▪ 定理証明 : Coq、Agda、Isabelle ▪ モデル検査 : Alloy、TLA+、SPIN ▫ 列挙可能な数学的対象でシステムを定義 ▫ システムが満たすべき制約を記述 ▫ 全探索で制約が満たされることを確認
12. 12. AWS でも使われた形式手法 ▪ 分散アルゴリズムの検証 ▫ DynamoDB、S3 に適用 ▫ 意図せずしてデータが壊れないことを保証 ▪ ツールは TLA+ を使用 ▫ 当初 Alloy を検討するも頓挫 ▫ 原因は「表現力が足りなかった」こと ▪ 普通の開発者が数週間で習得 http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods
13. 13. re:Invent 2016 でもセッションが https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=8311
14. 14. 3 Alloy、この強力なるもの 「関係」によってシステムを 記述するとはどういうことか？
15. 15. Alloy はどんなツールなのか？ ▪ 関係論理でシステムを定義 ▫ データモデル的な表現に向く ▪ SAT ソルバにより具体例を発見 ▫ 制約を満たす（満たさない）例を自動で列挙 ▪ 発見した例を可視化 ▫ 検証結果が読み取りやすい ▫ Lightweight を標榜、試行錯誤を支援
16. 16. 初めての Alloy モデル sig Subnet {} sig Instance { subnet : Subnet, } run {}
17. 17. 初めての具体例その 1
18. 18. 初めての具体例その 2
19. 19. 初めての具体例その 3
20. 20. 関係論理へのマッピング ▪ シグニチャ ▫ 有限集合を表す ▫ Subnet、Instance ▪ フィールド ▫ シグニチャ (= 集合) 上の関係を表す ▫ 実体は直積集合の部分集合 ▫ subnet ⊆ Instance × Subnet
21. 21. フィールド = 部分集合 subnet0 instance0 instance1 instance2 subnet1 subnet2 (i0, s0) (i0, s1) (i0, s2) (i1, s0) (i1, s1) (i1, s2) (i2, s0) (i2, s1) (i2, s2)
22. 22. フィールド = 部分集合 subnet0 instance0 instance1 instance2 subnet1 subnet2 (i0, s0) (i0, s1) (i0, s2) (i1, s0) (i1, s1) (i1, s2) (i2, s0) (i2, s1) (i2, s2)
23. 23. フィールド = 部分集合 : 具体例その 1
24. 24. フィールド = 部分集合 subnet0 instance0 instance1 instance2 subnet1 subnet2 (i0, s0) (i0, s1) (i0, s2) (i1, s0) (i1, s1) (i1, s2) (i2, s0) (i2, s1) (i2, s2)
25. 25. フィールド = 部分集合 : 具体例その 2
26. 26. フィールド = 部分集合 subnet0 instance0 instance1 instance2 subnet1 subnet2 (i0, s0) (i0, s1) (i0, s2) (i1, s0) (i1, s1) (i1, s2) (i2, s0) (i2, s1) (i2, s2)
27. 27. 初めての具体例その 3
28. 28. セキュリティグループを追加してみる sig Subnet {} sig Instance { subnet : Subnet, } run {}
29. 29. セキュリティグループを追加してみる sig Subnet {} sig SecurityGroup {} sig Instance { subnet : Subnet, securityGroup : SecurityGroup, } run {}
30. 30. インスタンスにつきセキュリティグループは常にひとつ？
31. 31. 多重度の表現 ▪ 対応する集合の要素の数を指定 ▫ one : ちょうど 1 個 ▫ lone : 0 個または 1 個 ▫ set : 0 個以上 ▫ some : 1 個以上 ▪ ER 図における 1..* などに相当
32. 32. 関係に多重度を指定する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : Subnet, securityGroup : SecurityGroup, } run {}
33. 33. 関係に多重度を指定する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : one Subnet, securityGroups : some SecurityGroup, } run {}
34. 34. セキュリティグループを複数持つインスタンスが出現
35. 35. サブネット内には常に インスタンスが存在するだろうか？
36. 36. 2 種類の検査コマンド ▪ pred ▫ 条件が成り立つ具体例を探索 ▫ run コマンドで検査 ▪ assert ▫ 条件が成り立たない反例を探索 ▫ check コマンドで検査
37. 37. 具体例を探索する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : one Subnet, securityGroup : some SecurityGroup, } run {}
38. 38. 具体例を探索する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : one Subnet, securityGroup : some SecurityGroup, } pred subnetShouldNotBeEmpty { all s : Subnet | some subnet.s } run subnetShouldNotBeEmpty
39. 39. 具体例 : すべてのサブネットがインスタンスを持つ
40. 40. 反例を探索する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : one Subnet, securityGroup : some SecurityGroup, } pred subnetShouldNotBeEmpty { all s : Subnet | some subnet.s } run subnetShouldNotBeEmpty
41. 41. 反例を探索する sig Subnet {} sig SecurityGroup {} sig Instance { subnet : one Subnet, securityGroup : some SecurityGroup, } assert subnetShouldNotBeEmpty { all s : Subnet | some subnet.s } check subnetShouldNotBeEmpty
42. 42. 反例 : インスタンスを持たないサブネットが存在する
43. 43. Alloy によるモデル検査の流れ ▪ シグニチャとフィールドでモデルを定義 ▪ 検査したい性質を記述 ▫ pred + run : 性質を満たす具体例を探す ▫ assert + check : 反例を探す ▪ 結果を見て、必要ならモデルを修正 ▫ テスト駆動開発に似た使用感 ▫ 繰り返す過程で設計が洗練される
44. 44. 4 モデリング・ケーススタディ システムをモデル化する際 頭の中では何が起きるのか？
45. 45. Alloy によるモデル記述のコツ ▪ 最初から完璧を目指さない ▫ 可視化機能をうまく利用、TDD をイメージ ▫ 行き詰ったら定義の仕方を変えてみる ▫ 関係の方向を逆にするとうまくいったりする ▪ 必要な要素を見極める ▪ パーツごとに分割して考える ▫ システムの中で、分割しやすいラインを考える
46. 46. サンプル : 単一のパブリックサブネットを持つ VPC http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Scenario1.html
47. 47. サンプルの構成要素 ▪ AWS 上のリソースに関する条件 ▫ EC2 インスタンス ▫ VPC、サブネット、インターネットゲートウェイ、 EIP ▫ ルートテーブル ▫ セキュリティグループ ▪ AWS 以外の一般論に関する条件 ▫ CIDR、プロトコル、ポート番号など
48. 48. パーツ 1 : CIDR に関する部分 ▪ CIDR ブロック ▫ 含む / 含まれるを関係で定義 ▫ 制約を与えて木構造（ループがない）にする ▪ プロトコル ▫ TCP、UDP、ICMP ▪ ポート番号 ▫ ICMP のとき、かつそのときに限り空集合
49. 49. パーツ 1 の正しくない例
50. 50. パーツ 1 の正しい例
51. 51. パーツ 2 : EC2 インスタンスに関する部分 ▪ EC2 インスタンス ▫ ちょうど 1 個のサブネットに属する ▫ 1 個以上のセキュリティグループを持つ ▪ サブネット、VPC ▫ ちょうど 1 個の CIDR ブロックを持つ ▪ インターネットゲートウェイ ▪ Elastic IP アドレス
52. 52. パーツ 3 : ルートテーブルに関する部分 ▪ ルートテーブル ▫ 0 個以上のルート設定を持つ ▪ ルート ▫ Destination となる CIDR ブロック ▫ Target は以下のいずれか（= 和集合の要素） ■ EC2 インスタンス ■ インターネットゲートウェイ
53. 53. パーツ 4 : セキュリティグループに関する部分 ▪ 構造はルートテーブルと似ている ▪ セキュリティグループ ▫ 0 個以上のイン / アウトバウンドルールを持つ ▪ ルール ▫ プロトコル、ポート番号 ▫ Source / Destination ■ CIDR ブロックとセキュリティグループの和集合
54. 54. 仕様から設計を発見したい
55. 55. 具体例を見つけたい仕様を記述する ▪ Web サーバのインスタンスが 1 つ存在 ▫ インターネットから HTTPS 接続可能 ▫ 管理用のネットワークから SSH 接続可能 ▫ その他の場所からは接続不可能 ▪ 「接続可能」の条件を定式化 ▫ ルーティングが正しく設定されている ▫ セキュリティーグループが解放されている
56. 56. サンプルと同じ構成を自動で設計！
57. 57. 5 まとめ 結局、この 25 分間で 我々は何を得たのか？
58. 58. 本日のまとめ ▪ 形式手法で設計を検証できる ▪ ツールは使い方が肝心 ▪ インフラ設計に Alloy がおすすめ
59. 59. AWS での「やっちまった」が 減ることを祈って Presented by チェシャ猫 (@y_taka_23)
60. 60. CREDITS Special thanks to all the people who made and released these awesome resources for free: ▪ Presentation template by SlidesCarnival ▪ Photographs by Unsplash