Terraform meetup tokyo#3 インフラ実装をUMLで設計する

2019年12月02日に Terraform meetup tokyo#3 の LT で発表した資料です
https://terraform-jp.connpass.com/event/153286/

Transcript

1. 2019/12/02 Terraform meetup tokyo#3 インフラ実装を UML で設計する 〜 インフラを⼀つのアプリと捉えよう〜 フリーランス@⼤阪 野崎敏彦
2. ⾃⼰紹介 • 野崎敏彦 • フリーランス • ⾃宅は⼤阪、年の 60% は東京 • 主に AWS インフラ⽀援その他もろもろやってます。 • Windows/WPF でゴリッゴリネイティブアプリ作ったりもしてます。 • Twitter : @bukaz54 2
3. 今⽇伝えたいこと • UML で考えよう。 3 AWS Cloud VPC Public subnet Private subnet Boundary Control Entiry
4. 4 去年 8 ⽉頃の話
5. こんなの。 • 実際は他システム連携や API の認可なども。 5 AWS Cloud VPC Public subnet Private subnet ECS Cluster Load Balancer App Container Database AWS CodePipeline Frontend （AWS 以外の⽅ごめんなさい）
6. 開発ステージ毎の AWS アカウント • 各環境は workspace で分離 6
7. configuration の分割 • Database スタック • Application スタック • CI/CD スタック • 運⽤ツール スタック • DNS スタック 7
8. 8 しぬかとおもった
9. 次ステージで apply 失敗 • 更新、削除できないリソース • Configuration 間での循環参照 9
10. 「環境もう１セットほしい」と⾔われる • 「QAチームを投⼊することになりました。」 • 「DB は開発チームと共有で。」 10
11. 環境の破棄が⼤変 • apply に苦労する configuration は destroy も困難 11
12. 12 なぜこうなった︖
13. ビルド⼿順が複雑なアプリと同じ状態 • 曖昧なコンポーネント分割 • 複雑な依存関係 • ライフサイクルの異なるリソースが混在 • 異なるデプロイ⽅法（アップデートできるのか、別で作って切り替 えるのか）の混在 13
14. 14 どうするか。
15. オブジェクト図、クラス図を描こう 15
16. ⼀部拡⼤ 16
17. インフラ全体を⼀つのアプリケーションと捉える • これだけの数の、ライフサイクルの全く異なるオブジェクト群を設 計無しでコーディングしたら失敗するのは当たり前。 • ある程度の規模を超えたら、アーキテクチャ図からコーディングに 直⾏するのは困難。 • UML を活⽤し、きちんとコンポーネント分割を⾏おう。 17
18. 責務で分割する 18 AWS Cloud VPC Public subnet Private subnet Boundary Control Entiry • VPC にロバストネス図乗せるのおすすめ。 ALB Container Database
19. 関⼼事で分割する • 各レイヤーのアクセス制御を担う Security Group は独⽴させる。 • AWS W-A / sec 「全レイヤーへのセキュリティの適⽤」 19
20. ライフサイクルで分割する • ECR や Hosted Zone など、初期段階で⽤意しておきたいもの。 • 消さないもの（間違って消したら困るもの、存在するだけなら無料 なもの） 20
21. 開発ステージまたぎ依存の可視化 • Database を共有することはよくある。 21
22. 22 ところで。
23. マルチベンダー開発 • もちろん各プロジェクトは並列運転 23
24. インフラは⼀⼈ • インフラがボトルネックになることもちらほら。 24
25. AWSに乗せてALB→DBを通すまでが勝負 • 可⽤性などの⾮機能要件はその後の開発サイクルで順次対応。 25
26. スタートダッシュ超重要 • トランザクションデータを扱う WebAPI が多い。 • 基本的には似通ったアーキテクチャ。 26 重要
27. インフラを量産したい • デプロイできなければ開発サイクルが回らない。 • 似たようなアーキテクチャのシステムなら即⽴ち上げられるだけの インフラ供給⼒を確⽴したい。 • 「再利⽤」。 27
28. 28 話をもどしまして。
29. Configuration 分割結果 • Common • Hosted Zone • ACM • ECS Cluster • ECR • etc … • Security Group • Load Balancer • ALB, • Listener, • Target Group • Database • RDS Instance (ignore_changes) • Bastion Host • Backend App • ECS Service • Task Definition • IAM Role • Frontend App • S3 Bucket 29
30. 効果 • configuration 単位での再利⽤性。 • CI/CD の⾃動化が「困難な箇所」 が明確になる。 • terraform state mv でのリファク タリングへの道。 30 • ３ヶ⽉後の⾃分へのドキュメンテーション。 • 引き継ぎ時にも有効。 • 開発チームと同じ⾔葉でインフラについて会話ができる。
31. まとめ • アーキテクチャ図からコンポーネント設計を経てコーディングに進。 • 再利⽤性は作り込むもの。 • UML は共通⾔語。きちんとドキュメントを残す。 31