実践！CloudFormation Best Practice ~CloudFormationで始める組織改革~

by urmot

Slide 1

Slide 1 text

実践！ CloudFormation Best Practice ~CloudFormationで始める組織改革~ レバレジーズ株式会社村本雄太 2019/02/23

Slide 2

Slide 2 text

目次 1. 自己紹介 & 会社紹介 2. 問題点 3. 実践！ベストプラクティス 4. まとめ

Slide 3

Slide 3 text

目次 1. 自己紹介 & 会社紹介 2. 問題点 3. 実践！ベストプラクティス 4. まとめ

Slide 4

Slide 4 text

● 村本雄太 ● レバレジーズ株式会社 ᄂ SREチームリーダー ● @urmot2 好きなAWSサービスはCloudFormationです

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

働きがいのある会社ベストカンパニーに選出

Slide 7

Slide 7 text

働きがいのある会社女性ランキング4位

Slide 8

Slide 8 text

目次 1. 自己紹介 & 会社紹介 2. 問題点 3. 実践！ベストプラクティス 4. まとめ

Slide 9

Slide 9 text

Templateがモノリシックで管理がつらい... 1. 全リソースを1Stackで集中管理 2. 数千行を超えるTemplate 3. Parametersによる複雑な制御厳選！モノリシックTemplateのつらみ3選

Slide 10

Slide 10 text

1. 全リソースを1Stackで集中管理 2. 数千行を超えるTemplate 3. Parametersによる複雑な制御 Templateがモノリシックで管理がつらい... 厳選！モノリシックTemplateのつらみ3選

Slide 11

Slide 11 text

複数サービスのリソースが混在 ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet

Slide 12

Slide 12 text

あらゆるリソースが依存関係を持っていた ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet

Slide 13

Slide 13 text

変更時の影響が把握しづらい ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet 変更したらどうなるんだ...

Slide 14

Slide 14 text

毎回恐る恐る更新 ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet 変更したらどうなるんだ... 更新ボタンを押したくない...

Slide 15

Slide 15 text

もうやだ... ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet 変更したらどうなるんだ... 更新ボタンを押したくない...

Slide 16

Slide 16 text

モノリシックなTemplateは管理がつらい... 1. 全リソースを1Stackで集中管理 2. 数千行を超えるTemplate 3. Parametersによる複雑な制御厳選！Template管理のつらみ3選

Slide 17

Slide 17 text

最終的に3000行のTemplateに 1 --- 2 AWSTemplateFormatVersion: '2010-09-09' 3 Description: 'My CloudFormation' 4 2459 ServiceCSqs: 2560 Type: AWS::CloudFormation::Stack 2561 Properties: 2562 Parameters:

Slide 18

Slide 18 text

1 --- 2 AWSTemplateFormatVersion: '2010-09-09' 3 Description: 'My CloudFormation' 4 2459 ServiceCSqs: 2560 Type: AWS::CloudFormation::Stack 2561 Properties: 2562 Parameters: どこを変更すれば良いかわからないどこを変更すれば良いの...?

Slide 19

Slide 19 text

1 --- 2 AWSTemplateFormatVersion: '2010-09-09' 3 Description: 'My CloudFormation' 4 2459 ServiceCSqs: 2560 Type: AWS::CloudFormation::Stack 2561 Properties: 2562 Parameters: インフラ担当に依頼するしかないインフラ担当が全部管理どこを変更すれば良いの...?

Slide 20

Slide 20 text

1 --- 2 AWSTemplateFormatVersion: '2010-09-09' 3 Description: 'My CloudFormation' 4 2459 ServiceCSqs: 2560 Type: AWS::CloudFormation::Stack 2561 Properties: 2562 Parameters: インフラ担当に負荷が集中インフラ担当がボトルネックに... どこを変更すれば良いの...?

Slide 21

Slide 21 text

1 --- 2 AWSTemplateFormatVersion: '2010-09-09' 3 Description: 'My CloudFormation' 4 2459 ServiceCSqs: 2560 Type: AWS::CloudFormation::Stack 2561 Properties: 2562 Parameters: 申し訳ない... インフラ担当がボトルネックに... どこを変更すれば良いの...?

Slide 22

Slide 22 text

1. 全リソースを1Stackで集中管理 2. 数千行を超えるTemplate 3. Parametersを使った複雑な制御モノリシックなTemplateは管理がつらい... 厳選！Template管理のつらみ3選

Slide 23

Slide 23 text

複数環境に対応しようとしていた 43 --- 44 Parameters: 45 EnvType: 46 Type: String 151 Conditions: 152 IsProd: !Equals [!Ref EnvType, Prod] 153 IsStag: !Equals [!Ref EnvType, Stag] 154

Slide 24

Slide 24 text

43 --- 44 Parameters: 45 EnvType: 46 Type: String 151 Conditions: 152 IsProd: !Equals [!Ref EnvType, Prod] 153 IsStag: !Equals [!Ref EnvType, Stag] 154 環境の差分を把握するのが困難これを変えるとどうなるの？

Slide 25

Slide 25 text

43 --- 44 Parameters: 45 EnvType: 46 Type: String 151 Conditions: 152 IsProd: !Equals [!Ref EnvType, Prod] 153 IsStag: !Equals [!Ref EnvType, Stag] 154 環境ごとの違いを吸収しなければならない記述が複雑に...

Slide 26

Slide 26 text

43 --- 44 Parameters: 45 EnvType: 46 Type: String 151 Conditions: 152 IsProd: !Equals [!Ref EnvType, Prod] 153 IsStag: !Equals [!Ref EnvType, Stag] 154 何も考えたくない...

Slide 27

Slide 27 text

つらい...

Slide 28

Slide 28 text

なんとかしなければ...

Slide 29

Slide 29 text

そうだ！

Slide 30

Slide 30 text

AWSのベストプラクティスを実践しよう！

Slide 31

Slide 31 text

● 設計時の推奨事項 ● テンプレート作成時の推奨事項 ● 運用時の推奨事項 AWSさんがベストプラクティスを提供してくださっている

Slide 32

Slide 32 text

● 設計時の推奨事項 ● テンプレート作成時の推奨事項 ● 運用時の推奨事項今回は設計に着目

Slide 33

Slide 33 text

目次 1. 自己紹介 & 会社紹介 2. 問題点 3. 実践！ベストプラクティス 4. まとめ

Slide 34

Slide 34 text

時間がないので3つだけ 1. ライフサイクルと所有権でStackを整理 2. 他Stackの値を安全に利用する 3. 共通パターンを再利用

Slide 35

Slide 35 text

1. ライフサイクルと所有権でStackを整理 2. 他Stackの値を安全に利用する 3. 共通パターンを再利用時間がないので3つだけ

Slide 36

Slide 36 text

Stackを分割する基準についての項目ライフサイクルと所有権に着目！

Slide 37

Slide 37 text

ライフサイクルとは

Slide 38

Slide 38 text

AWSリソースのライフサイクルのこと ● ライフサイクルが異なるリソースを分ける ● Template更新による影響をシャットアウト

Slide 39

Slide 39 text

例: 期間限定のキャンペーン用サーバを作る場合 WebSite ELB WebSite EC2 RDS S3 WebSite Stack

Slide 40

Slide 40 text

1. WebSite Stackにキャンペーン用リソースを追加 WebSite ELB WebSite EC2 RDS S3 WebSite Stack Campaign ELB Campaign EC2

Slide 41

Slide 41 text

2. キャンペーン終了後はキャンペーン用リソースを削除 WebSite ELB WebSite EC2 RDS S3 WebSite Stack Campaign ELB Campaign EC2 使ったリソースを削除したい

Slide 42

Slide 42 text

3. キャンペーン用リソースをピックアップ WebSite ELB WebSite EC2 RDS S3 WebSite Stack Campaign ELB Campaign EC2 使ったリソースをピックアップ

Slide 43

Slide 43 text

4. リソース削除による影響範囲を調査 WebSite ELB WebSite EC2 RDS S3 WebSite Stack Campaign ELB Campaign EC2 このリソースの影響範囲は...

Slide 44

Slide 44 text

5. WebSiteにも影響を与えそうなりソースを発見 WebSite ELB WebSite EC2 RDS S3 WebSite Stack Campaign ELB Campaign EC2 WebSiteでも S3使ってる... このリソースの影響範囲は...

Slide 45

Slide 45 text

既存のリソースに影響を与えるところだった...

Slide 46

Slide 46 text

解決策: WebSiteとCampaignでStackを分割する ELB EC2 RDS S3 WebSite Stack ELB EC2 S3 Campaign Stack

Slide 47

Slide 47 text

1. キャンペーン用のStackを作成 ELB EC2 RDS S3 WebSite Stack ELB EC2 S3 Campaign Stack

Slide 48

Slide 48 text

2. キャンペーン用リソースを削除する ELB EC2 RDS S3 WebSite Stack ELB EC2 S3 Campaign Stack

Slide 49

Slide 49 text

3. Campaign Stackを削除するだけ ELB EC2 RDS S3 WebSite Stack ELB EC2 S3 Campaign Stack

Slide 50

Slide 50 text

削除による影響をシャットアウト ELB EC2 RDS S3 WebSite Stack ELB EC2 S3 Campaign Stack 無傷

Slide 51

Slide 51 text

所有権

Slide 52

Slide 52 text

所有権が異なるリソースを分割管理 ● 変更の意思決定にかかるコストを減らせる ● Templateの柔軟な変更が可能となるリソースを誰が管理すべきかを考える

Slide 53

Slide 53 text

例: DBチームとWebチームで運用されているサービス ELB EC2 RDS Security Group Parameter Group Security Group Service Stack

Slide 54

Slide 54 text

ELBの SecurityGroupを変更したい 1. DBチームとWebチームが同時に変更要望を出す ELB EC2 RDS Security Group Parameter Group Security Group Service Stack Webチーム RDSの SecurityGroupを変更したい DBチーム

Slide 55

Slide 55 text

2. 更新タイミングの調整, 影響範囲の確認が必要になる ELB EC2 RDS Security Group Parameter Group Security Group Service Stack 影響範囲の調査更新タイミングの調整

Slide 56

Slide 56 text

変更コストが高いなぁ...

Slide 57

Slide 57 text

解決策: WebチームとDBチームでStackを分割する ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack

Slide 58

Slide 58 text

ELBの SecurityGroup を変更したい 1. DBチームとWebチームが同時に変更要望を出す ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack Webチーム RDSの SecurityGroup を変更したい DBチーム

Slide 59

Slide 59 text

2. 各チームのタイミングで変更してリリース ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack 今日変更して今日リリース!! Webチーム今日変更して明日リリース!! DBチーム

Slide 60

Slide 60 text

更新タイミングの調整が不要 ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack 更新タイミングの調整は不要

Slide 61

Slide 61 text

影響範囲も確認しやすい ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack 更新タイミングの調整は不要 Stack内の影響範囲を確認すればOK

Slide 62

Slide 62 text

ハッピー ELB EC2 Security Group Web Stack RDS Security Group Parameter Group DB Stack 更新タイミングの調整は不要 Stack内の影響範囲を確認すればOK

Slide 63

Slide 63 text

1. ライフサイクルと所有権でStackを整理 2. 他のStackの値を安全に利用する 3. 共通パターンを再利用時間がないので3つだけ

Slide 64

Slide 64 text

他のStackの値を安全に利用したい ● Templateにハードコード ● Parametersで他Stackの値を渡す ● クロススタック参照他のStackの値の参照方法はいくつかある

Slide 65

Slide 65 text

他のStackの値を安全に利用する ● Templateにハードコード ● Parametersで他Stackの値を渡す ● クロススタック参照他のStackの値の参照方法はいくつかある

Slide 66

Slide 66 text

例: MyVpcのVPC IDをMyAppで利用する MyVpc ELB MyApp Subnet EC2 MyApp VPC

Slide 67

Slide 67 text

# MyVpc.yaml Outputs: VpcId: Value: !Ref Vpc Export: Name: MyVpc-Id 1. MyVpcでVPC IDをExport

Slide 68

Slide 68 text

# MyVpc.yaml Outputs: VpcId: Value: !Ref Vpc Export: Name: MyVpc-Id 1. MyVpcでVPC IDをExport リージョン内で一意である必要がある

Slide 69

Slide 69 text

# MyApp.yaml Resources: MyAppSubnet: Type: AWS::EC2::Subnet Properties: VpcId: !ImportValue MyVpc-Id 2. MyAppでMyVpcの値をImport !ImportValueで MyVpc-Idを指定

Slide 70

Slide 70 text

# MyVpc.yaml Outputs: VpcId: Value: !GetAtt Vpc.CidrBlock Export: Name: MyVpc-Id VPC IDから CIDR Blockに変更 3. Exportの値を変更してみる

Slide 71

Slide 71 text

# MyVpc.yaml Outputs: VpcId: Value: !GetAtt Vpc.CidrBlock Export: Name: MyVpc-Id VPC IDから CIDR Blockに変更 4. 変更をMyVpc Stackに適応

Slide 72

Slide 72 text

# MyVpc.yaml Outputs: VpcId: Value: !GetAtt Vpc.CidrBlock Export: Name: MyVpc-Id 5. エラーが発生し変更がロールバック参照されているExportの値は変更できない

Slide 73

Slide 73 text

6. 参照されているExportは変更できない # MyApp.yaml Resources: PrivateASubnet: Type: AWS::EC2::Subnet Properties: VpcId: !ImportValue MyVpc-Id 勝手に変更されない為安全に利用可能

Slide 74

Slide 74 text

やったー！ # MyApp.yaml Resources: PrivateASubnet: Type: AWS::EC2::Subnet Properties: VpcId: !ImportValue MyVpc-Id 勝手に変更されない為安全に利用可能

Slide 75

Slide 75 text

1. ライフサイクルと所有権でStackを整理 2. 他Stackの値を安全に利用する 3. 共通パターンを再利用時間がないので3つだけ

Slide 76

Slide 76 text

● 共通パターンの保守が容易に ● 専用Templateの保守を分担共通パターン = よく使う設定パターン共通パターンを専用Templateに集約

Slide 77

Slide 77 text

例: 社内IPを許可するSecurityGroupにIPを追加する ELB EC2 Security Group ServiceA Stack ELB Security Group EC2 ServiceB Stack

Slide 78

Slide 78 text

1. 新しい支店のIPを追加する ELB EC2 Security Group ServiceA Stack ELB Security Group EC2 ServiceB Stack

Slide 79

Slide 79 text

2. 各Stackの管理者にIP追加を依頼 ELB EC2 Security Group ServiceA Stack ELB Security Group EC2 ServiceB Stack 支店のIPを SecurityGroup に追加してー

Slide 80

Slide 80 text

3. Stackの管理者はIPを確認しSecurityGroupに追加 ELB EC2 Security Group ServiceA Stack ELB Security Group EC2 ServiceB Stack ServiceAに支店のIPを追加 ServiceBに支店のIPを追加

Slide 81

Slide 81 text

SecurityGroupが二重管理 ELB EC2 Security Group ServiceA Stack ELB Security Group EC2 ServiceB Stack 同じ設定を 2箇所で管理 2つだけならまだいいけど...

Slide 82

Slide 82 text

管理がつらそう

Slide 83

Slide 83 text

解決策: 社内IPを許可する専門Templateを作成 CompanySG.yaml

Slide 84

Slide 84 text

1. 社内IPを許可する専用Templateを作成 CompanySG.yaml 社内IPを許可する SecurityGroupを追加 Company SG

Slide 85

Slide 85 text

2. 専用テンプレートをS3にアップロード CompanySG.yaml Company SG

Slide 86

Slide 86 text

3. 各Stackにネストされたスタックとして作成 ELB EC2 Company SG ServiceA Stack ELB Company SG EC2 ServiceB Stack Company SG 各Stackで同じTemplate を参照

Slide 87

Slide 87 text

新しい支店のIPを追加する CompanySG.yaml Company SG

Slide 88

Slide 88 text

1. CompanySGに新しい支店のIPを追加する支店のIPを CompanySG に追加 CompanySG.yaml Company SG

Slide 89

Slide 89 text

2. CampanySG.yamlをS3にアップロード CompanySG.yaml Company SG

Slide 90

Slide 90 text

3. 各Stackを更新 ELB EC2 Company SG ServiceA Stack ELB Company SG EC2 ServiceB Stack Company SG 変更を加えずに更新

Slide 91

Slide 91 text

4. Campany.yamlの変更が各Stackに反映される ELB EC2 Company SG ServiceA Stack ELB Company SG EC2 ServiceB Stack Company SG Campany.yaml と同期

Slide 92

Slide 92 text

Stackの管理者は社内IPの保守はしない共通パターンの保守が容易に ELB EC2 Company SG ServiceA Stack ELB Company SG EC2 ServiceB Stack Company SG

Slide 93

Slide 93 text

Stackの管理者は社内IPの保守はしない仕事が減った！ ELB EC2 Company SG ServiceA Stack ELB Company SG EC2 ServiceB Stack Company SG

Slide 94

Slide 94 text

おまけ

Slide 95

Slide 95 text

より詳細な実践方法はブログをご参照ください

Slide 96

Slide 96 text

目次 1. 自己紹介 & 会社紹介 2. 問題点 3. 実践！ベストプラクティス 4. まとめ

Slide 97

Slide 97 text

1. 記述の簡素化 2. Stackの管理を分担 3. 変更コストが激減 CloudFormationの管理が圧倒的に楽になったッッ!!!

Slide 98

Slide 98 text

1. 記述の簡素化 2. Stackの管理を分担 3. 変更コストが激減 CloudFormationの管理が圧倒的に楽になったッッ!!!

Slide 99

Slide 99 text

● 1Templateの行数: 3000行 → ● Parametersの数: 20個 → Templateの記述がかなりシンプルになった Stack分割で1Templateがミニマム化

Slide 100

Slide 100 text

● 1Templateの行数: 3000行 → 200行 ● Parametersの数: 20個 → Templateの記述がかなりシンプルになった Stack分割で1Templateがミニマム化

Slide 101

Slide 101 text

● 1Templateの行数: 3000行 → 200行 ● Parametersの数: 20個 → 2〜5個 Templateの記述がかなりシンプルになった Stack分割で1Templateがミニマム化

Slide 102

Slide 102 text

● 1Templateの行数: 3000行 → 200行 ● Parametersの数: 20個 → 2〜5個よっしゃ！ Stack分割で1Templateが小さくなった

Slide 103

Slide 103 text

1. 記述の簡素化 2. Stackの管理を分担 3. 変更コストが激減 CloudFormationの管理が圧倒的に楽になったッッ!!!

Slide 104

Slide 104 text

● アプリ側でもリソースの管理が可能に ● テスト環境の作成依頼がなくなる ● インフラ担当がボトルネックじゃなくなるチームとStackを分担して管理可能に専用Templateを作成した結果

Slide 105

Slide 105 text

● アプリ側でもリソースの管理が可能に？ ● テスト環境の作成依頼がなくなるかも... よかった！所有権でStackを分割した結果

Slide 106

Slide 106 text

1. 記述の簡素化 2. Stackの管理を分担 3. 変更コストが激減 CloudFormationの管理が圧倒的に楽になったッッ!!!

Slide 107

Slide 107 text

● Stack間の連携が容易に ● 影響範囲の特定が容易に ● リリース日の調整が不要に変更にかかるコストが激減クロススタック参照でリソースの依存が限定された

Slide 108

Slide 108 text

● 影響範囲の特定が容易に ● リリース日の調整が不要に ● 変更セットが使用可能に！やったね！ Stackの分割でリソースの依存が限定された