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