AWS CloudFormation Best Practice

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. つらい...

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

29. そうだ！

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

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

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

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

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

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

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

37. ライフサイクルとは

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

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

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

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

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

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

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

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

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

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

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

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

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

51. 所有権

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

82. 管理がつらそう

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

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

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

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

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

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

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

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

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

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

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

94. おまけ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

109. さいごに

111. ありがとうございました!!!