形式手法と aws のおいしい関係。- モデル検査器 alloy...

形式手法と 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

3Alloy、この強力なるもの

「関係」によってシステムを記述するとはどういうことか？

Alloy はどんなツールなのか？

▪ 関係論理でシステムを定義

▫ データモデル的な表現に向く

▪ SAT ソルバにより具体例を発見

▫ 制約を満たす（満たさない）例を自動で列挙

▪ 発見した例を可視化

▫ 検証結果が読み取りやすい

▫ Lightweight を標榜、試行錯誤を支援

初めての Alloy モデル

sig Subnet {}

sig Instance {

subnet : Subnet,

}

run {}

初めての具体例その 1

関係論理へのマッピング

▪ シグニチャ

▫ 有限集合を表す

▫ 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)

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

セキュリティグループを追加してみる

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 Instance {

subnet : Subnet,

securityGroup : SecurityGroup,

}

run {}

関係に多重度を指定する

sig Subnet {}


sig Instance {

subnet : one Subnet,

securityGroups : some SecurityGroup,

}

run {}

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

サブネット内には常に

インスタンスが存在するだろうか？

2 種類の検査コマンド

▪ pred

▫ 条件が成り立つ具体例を探索

▫ run コマンドで検査

▪ assert

▫ 条件が成り立たない反例を探索

▫ check コマンドで検査

具体例を探索する

sig Subnet {}


sig Instance {


securityGroup : some SecurityGroup,

}

run {}

具体例を探索する

sig Subnet {}


sig Instance {



}

pred subnetShouldNotBeEmpty {

all s : Subnet | some subnet.s

}

run subnetShouldNotBeEmpty

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

反例を探索する

sig Subnet {}


sig Instance {



}

pred subnetShouldNotBeEmpty {


}

run subnetShouldNotBeEmpty

反例を探索する

sig Subnet {}


sig Instance {



}

assert subnetShouldNotBeEmpty {


}

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

http://www.slidescarnival.com/

http://unsplash.com/

形式手法と aws のおいしい関係。- モデル検査器 alloy...

Technology