Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,381 views

Published on

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

Published in: Technology

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

×