JAWS Festa 東海道 2016 の発表スライドです。モデル検査器 Alloy を用いて AWS のリソースをモデル化し、仕様からインフラ設計を自動で生成する流れをお見せします。

1. 形式手法と AWS の
おいしい関係。
チェシャ猫 (@y_taka_23)
JAWS Festa 東海道 2016 (2016/10/22)
モデル検査器 Alloy によるインフラ設計技法

2. AWS で「やっちまった」こと
ありませんか？

3. 本日の目次
1. インフラ設計、この厄介なるもの
2. 形式手法、この深淵なるもの
3. Alloy、この強力なるもの
4. モデリング・ケーススタディ
5. まとめ

4. 1
インフラ設計、この厄介なるもの
問題を複雑にしている要因は
そもそもどこにあるのか？

5. インフラ設計の難しさ
▪ 長期間に渡って使用される
▫ 当初の想定に反する事態になりやすい
▫ 設計意図が引き継がれにくい
▪ 変更時の影響範囲が大きい
▫ 一部分のみの再設計が困難
▪ 構成要素が多く、系として複雑
▫ 全体を正しく把握しないと動かせない

6. AWS をテストする手法たち
▪ awspec
▫ RSpec 形式で AWS リソースをテスト
▫ API にアクセスしてリソースの情報を取得
▪ AWS Config Rules
▫ 設定の変更履歴を追跡
▫ 条件を満たさないリソースを監視
▫ Lambda でカスタムルール作成可能

7. 実物に依存せず
「設計」に対して試行錯誤したい

8. 形式手法
Formal Methods

9. 2
形式手法、この深淵なるもの
数理的手法を応用することで
何が得られるのか？

10. 形式手法とは
▪ システムを数学的対象として表現
▫ 選んだ対象によって特性が変わる
▪ 数学的対象に関する理論を用いて検証
▪ いわゆるテストと比較して
▫ より抽象的な設計を検証できる
▫ テストケースの漏れが生じない
▫ 一般的には学習コストが高い（なじみがない）

11. 様々な形式手法ツール
▪ 形式仕様記述 : Z、VDM++
▪ 定理証明 : Coq、Agda、Isabelle
▪ モデル検査 : Alloy、TLA+、SPIN
▫ 列挙可能な数学的対象でシステムを定義
▫ システムが満たすべき制約を記述
▫ 全探索で制約が満たされることを確認

12. AWS でも使われた形式手法
▪ 分散アルゴリズムの検証
▫ DynamoDB、S3 に適用
▫ 意図せずしてデータが壊れないことを保証
▪ ツールは TLA+ を使用
▫ 当初 Alloy を検討するも頓挫
▫ 原因は「表現力が足りなかった」こと
▪ 普通の開発者が数週間で習得
http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services-uses-formal-methods

13. re:Invent 2016 でもセッションが
https://www.portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=8311

14. 3
Alloy、この強力なるもの
「関係」によってシステムを
記述するとはどういうことか？

15. Alloy はどんなツールなのか？
▪ 関係論理でシステムを定義
▫ データモデル的な表現に向く
▪ SAT ソルバにより具体例を発見
▫ 制約を満たす（満たさない）例を自動で列挙
▪ 発見した例を可視化
▫ 検証結果が読み取りやすい
▫ Lightweight を標榜、試行錯誤を支援

16. 初めての Alloy モデル
sig Subnet {}
sig Instance {
subnet : Subnet,
}
run {}

17. 初めての具体例その 1

18. 初めての具体例その 2

19. 初めての具体例その 3

20. 関係論理へのマッピング
▪ シグニチャ
▫ 有限集合を表す
▫ Subnet、Instance
▪ フィールド
▫ シグニチャ (= 集合) 上の関係を表す
▫ 実体は直積集合の部分集合
▫ subnet ⊆ Instance × Subnet

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. フィールド = 部分集合
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. フィールド = 部分集合 : 具体例その 1

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. フィールド = 部分集合 : 具体例その 2

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. 初めての具体例その 3

28. セキュリティグループを追加してみる
sig Subnet {}
sig Instance {
subnet : Subnet,
}
run {}

29. セキュリティグループを追加してみる
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : Subnet,
securityGroup : SecurityGroup,
}
run {}

30. インスタンスにつきセキュリティグループは常にひとつ？

31. 多重度の表現
▪ 対応する集合の要素の数を指定
▫ one : ちょうど 1 個
▫ lone : 0 個または 1 個
▫ set : 0 個以上
▫ some : 1 個以上
▪ ER 図における 1..* などに相当

32. 関係に多重度を指定する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : Subnet,
securityGroup : SecurityGroup,
}
run {}

33. 関係に多重度を指定する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : one Subnet,
securityGroups : some SecurityGroup,
}
run {}

34. セキュリティグループを複数持つインスタンスが出現

35. サブネット内には常に
インスタンスが存在するだろうか？

36. 2 種類の検査コマンド
▪ pred
▫ 条件が成り立つ具体例を探索
▫ run コマンドで検査
▪ assert
▫ 条件が成り立たない反例を探索
▫ check コマンドで検査

37. 具体例を探索する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : one Subnet,
securityGroup : some SecurityGroup,
}
run {}

38. 具体例を探索する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : one Subnet,
securityGroup : some SecurityGroup,
}
pred subnetShouldNotBeEmpty {
all s : Subnet | some subnet.s
}
run subnetShouldNotBeEmpty

39. 具体例 : すべてのサブネットがインスタンスを持つ

40. 反例を探索する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : one Subnet,
securityGroup : some SecurityGroup,
}
pred subnetShouldNotBeEmpty {
all s : Subnet | some subnet.s
}
run subnetShouldNotBeEmpty

41. 反例を探索する
sig Subnet {}
sig SecurityGroup {}
sig Instance {
subnet : one Subnet,
securityGroup : some SecurityGroup,
}
assert subnetShouldNotBeEmpty {
all s : Subnet | some subnet.s
}
check subnetShouldNotBeEmpty

42. 反例 : インスタンスを持たないサブネットが存在する

43. Alloy によるモデル検査の流れ
▪ シグニチャとフィールドでモデルを定義
▪ 検査したい性質を記述
▫ pred + run : 性質を満たす具体例を探す
▫ assert + check : 反例を探す
▪ 結果を見て、必要ならモデルを修正
▫ テスト駆動開発に似た使用感
▫ 繰り返す過程で設計が洗練される

44. 4
モデリング・ケーススタディ
システムをモデル化する際
頭の中では何が起きるのか？

45. Alloy によるモデル記述のコツ
▪ 最初から完璧を目指さない
▫ 可視化機能をうまく利用、TDD をイメージ
▫ 行き詰ったら定義の仕方を変えてみる
▫ 関係の方向を逆にするとうまくいったりする
▪ 必要な要素を見極める
▪ パーツごとに分割して考える
▫ システムの中で、分割しやすいラインを考える

46. サンプル : 単一のパブリックサブネットを持つ VPC
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Scenario1.html

47. サンプルの構成要素
▪ AWS 上のリソースに関する条件
▫ EC2 インスタンス
▫ VPC、サブネット、インターネットゲートウェイ、
EIP
▫ ルートテーブル
▫ セキュリティグループ
▪ AWS 以外の一般論に関する条件
▫ CIDR、プロトコル、ポート番号など

48. パーツ 1 : CIDR に関する部分
▪ CIDR ブロック
▫ 含む / 含まれるを関係で定義
▫ 制約を与えて木構造（ループがない）にする
▪ プロトコル
▫ TCP、UDP、ICMP
▪ ポート番号
▫ ICMP のとき、かつそのときに限り空集合

49. パーツ 1 の正しくない例

50. パーツ 1 の正しい例

51. パーツ 2 : EC2 インスタンスに関する部分
▪ EC2 インスタンス
▫ ちょうど 1 個のサブネットに属する
▫ 1 個以上のセキュリティグループを持つ
▪ サブネット、VPC
▫ ちょうど 1 個の CIDR ブロックを持つ
▪ インターネットゲートウェイ
▪ Elastic IP アドレス

52. パーツ 3 : ルートテーブルに関する部分
▪ ルートテーブル
▫ 0 個以上のルート設定を持つ
▪ ルート
▫ Destination となる CIDR ブロック
▫ Target は以下のいずれか（= 和集合の要素）
■ EC2 インスタンス
■ インターネットゲートウェイ

53. パーツ 4 : セキュリティグループに関する部分
▪ 構造はルートテーブルと似ている
▪ セキュリティグループ
▫ 0 個以上のイン / アウトバウンドルールを持つ
▪ ルール
▫ プロトコル、ポート番号
▫ Source / Destination
■ CIDR ブロックとセキュリティグループの和集合

54. 仕様から設計を発見したい

55. 具体例を見つけたい仕様を記述する
▪ Web サーバのインスタンスが 1 つ存在
▫ インターネットから HTTPS 接続可能
▫ 管理用のネットワークから SSH 接続可能
▫ その他の場所からは接続不可能
▪ 「接続可能」の条件を定式化
▫ ルーティングが正しく設定されている
▫ セキュリティーグループが解放されている

56. サンプルと同じ構成を自動で設計！

57. 5
まとめ
結局、この 25 分間で
我々は何を得たのか？

58. 本日のまとめ
▪ 形式手法で設計を検証できる
▪ ツールは使い方が肝心
▪ インフラ設計に Alloy がおすすめ

59. AWS での「やっちまった」が
減ることを祈って
Presented by
チェシャ猫 (@y_taka_23)

60. CREDITS
Special thanks to all the people who made and released
these awesome resources for free:
▪ Presentation template by SlidesCarnival
▪ Photographs by Unsplash