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

Transcript

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 VPC PrivateA Subnet PublicC Subnet
12. あらゆるリソースが依存関係を持っていた ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet
13. 変更時の影響が把握しづらい ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet 変更したら どうなるんだ...
14. 毎回恐る恐る更新 ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA Subnet PublicC Subnet 変更したら どうなるんだ... 更新ボタンを 押したくない...
15. もうやだ... ServiceA ELB ServiceB ELB ServiceA EC2 ServiceB EC2 ServiceA S3 ServiceB EC2 ServiceC EC2 ServiceA EC2 VPC PrivateA 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. ありがとうございました!!!