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

More Related Content

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