Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実践!CloudFormation Best Practice
Search
urmot
December 20, 2018
Programming
0
180
実践!CloudFormation Best Practice
urmot
December 20, 2018
Tweet
Share
More Decks by urmot
See All by urmot
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
790
ログラスを支える設計標準について / loglass-design-standards
urmot
12
2.7k
ログラスを支える技術的投資の仕組み / loglass-technical-investment
urmot
10
5.7k
実践!CloudFormation Best Practice ~CloudFormationで始める組織改革~
urmot
2
3.2k
CircleCIを導入した話
urmot
0
66
SPA on AWS
urmot
0
180
RDBのログを取る時にDMSを使うという選択肢
urmot
0
97
ベンチャー企業のインフラを運用して学んだ99のこと
urmot
0
1.1k
Other Decks in Programming
See All in Programming
ErdMap: Thinking about a map for Rails applications
makicamel
1
590
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
VisionProで部屋の明るさを反映させるシェーダーを作った話
segur
0
100
良いユニットテストを書こう
mototakatsu
11
3.6k
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
250
선언형 UI에서의 상태관리
l2hyunwoo
0
270
20241217 競争力強化とビジネス価値創出への挑戦:モノタロウのシステムモダナイズ、開発組織の進化と今後の展望
monotaro
PRO
0
280
Package Traits
ikesyo
1
210
php-conference-japan-2024
tasuku43
0
430
shadcn/uiを使ってReactでの開発を加速させよう!
lef237
0
290
EC2からECSへ 念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築
sumiyae
3
580
テストコード書いてみませんか?
onopon
2
340
Featured
See All Featured
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
GraphQLとの向き合い方2022年版
quramy
44
13k
4 Signs Your Business is Dying
shpigford
182
22k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
3
180
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
500
Raft: Consensus for Rubyists
vanstee
137
6.7k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Scaling GitHub
holman
459
140k
Adopting Sorbet at Scale
ufuk
74
9.2k
Transcript
実践! CloudFormation Best Practice ~設計編~ レバレジーズ株式会社 村本 雄太 2018/12/19
目次 • 自己紹介 • 背景 • 解説!CloudFormation Best Practice •
実践!CloudFormation Best Practice • まとめ
自己紹介.yaml Name: 村本 雄太 BelongsTo: レバレジーズ株式会社: SRE Team Tags: -
新卒2年目 - いんふらえんじにあ
自己紹介.png
自己紹介.png
自己紹介.png
自己紹介.png
背景
背景 CloudFormationテンプレートを管理するのにつかれた
CloudFormationテンプレートが肥大化 どこに何を書けばよいかわからない そして誰も使わなくなる... 背景 CloudFormationテンプレートを管理するのにつかれた
誰も使わないテンプレートじゃなくて みんなが使うものを作ろう!
背景
AWS CloudFormation Best Practice を実践しよう!
解説!AWS CloudFormation Best Practice by https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/best-practices.html
解説!AWS CloudFormation Best Practice 1. ライフサイクルと所有権でスタックを整理 2. クロススタック参照を利用して共通リソースをエクスポート 3. ネストされたスタックを利用して共通テンプレートパターンを再利用
4. テンプレートを再利用して複数環境にスタックを複製する
1. ライフサイクルと所有権でスタックを整理
解説!CloudFormation Best Practice ライフサイクルと所有権によるStackの整理 • Stackを分ける基準についての項目 • ライフサイクルと所有権という概念でStackを分ける • 他リソースに影響を与えずリソースセットを変更可能
ライフサイクルとは
解説!CloudFormation Best Practice ライフサイクルが同じリソースはまとめて管理しよう • AWSリソースのライフサイクルのこと • テンプレートの変更による影響を閉じられる • Point:
AWSリソースの死に際を意識する ◦ あるAWSリソースを削除する時に同時に削除されるべきものを纏める
解説!CloudFormation Best Practice 例: 期間限定のキャンペーン用のサーバをつくる Campaign EC2 Campaign ELB WebSite
ELB WebSite EC2 S3 RDS
解説!CloudFormation Best Practice 例: 期間限定のキャンペーン用のサーバをつくる Campaign EC2 Campaign ELB WebSite
ELB WebSite EC2 S3 RDS キャンペーン終了後 使ったリソースを 削除したい
解説!CloudFormation Best Practice 例: 期間限定のキャンペーン用のサーバをつくる Campaign EC2 Campaign ELB WebSite
ELB WebSite EC2 S3 RDS キャンペーン終了後 使ったリソースを 削除したい
解説!CloudFormation Best Practice 例: 期間限定のキャンペーン用のサーバをつくる Campaign EC2 Campaign ELB WebSite
ELB WebSite EC2 S3 RDS キャンペーン終了後 使ったリソースを 削除したい キャンペーンでS3 使ってたっけ?
解説!CloudFormation Best Practice
解説!CloudFormation Best Practice 解決策: キャンペーン用のStackを別に作成する Campaign EC2 Campaign ELB WebSite
ELB WebSite EC2 S3 RDS Campaign ELB Campaign EC2 S3 WebSite ELB WebSite EC2 S3 RDS
解説!CloudFormation Best Practice 例: 期間限定のキャンペーン用のサーバをつくる Campaign ELB Campaign EC2 S3
WebSite ELB WebSite EC2 S3 RDS キャンペーン終了は キャンペーンのStack を削除するだけ
解説!CloudFormation Best Practice 解決策: キャンペーン用のStackを別に作成する Campaign ELB Campaign EC2 S3
WebSite ELB WebSite EC2 S3 RDS キャンペーン終了は キャンペーンのStack を削除するだけ キャンペーンリソースが 削除された事による影 響を閉じられる
所有権とは
解説!CloudFormation Best Practice 所有権が異なるリソースは分けて管理しよう • AWSリソースの所有権のこと • AWSリソースを誰が管理すべきかという観点で考える • 各チームのリソース変更にかかるコストを減らせる
• テンプレートの柔軟な変更が可能となる
解説!CloudFormation Best Practice 例: DBチームとWebチームで運用されているサービス EC2 ELB RDS Parameter Groups
Security Group Security Group
DBチーム: RDS SecurityGroup を変更したい 解説!CloudFormation Best Practice 例: DBチームとWebチームで運用されているサービス EC2
ELB RDS Parameter Groups Security Group Security Group
Webチーム: Web SecurityGroup を変更したい 解説!CloudFormation Best Practice 例: DBチームとWebチームで運用されているサービス EC2
ELB RDS Parameter Groups Security Group Security Group
更新タイミング の調整 影響範囲の確認 解説!CloudFormation Best Practice 例: DBチームとWebチームで運用されているサービス EC2 ELB
RDS Parameter Groups Security Group Security Group
解説!CloudFormation Best Practice
解説!CloudFormation Best Practice 解決策: WebチームとDBチームでStackを分ける EC2 ELB RDS Parameter Groups
Security Group Security Group EC2 ELB RDS Security Group Parameter Groups Security Group
解説!CloudFormation Best Practice 解決策: WebチームとDBチームでStackを分ける EC2 ELB RDS Security Group
Parameter Groups Security Group 更新タイミング の調整は不要 影響範囲もStack内 で確認できればOK
解説!CloudFormation Best Practice • SOA = Service Oriented Architecture ◦
ServiceをNetwork上で連携させてシステムの全体構成をしていく ◦ Service: 業務上の一処理 • 多層アーキテクチャ ◦ アプリケーションを複数の層に分け, 独立したモジュールとして開発 ◦ 各層はその直下の層に依存する おまけ: 詳細なStackの分け方は多層アーキテクチャとSOAが使える(らしい)
2. クロススタック参照を利用して共有リソースを エクスポート
解説!CloudFormation Best Practice クロススタック参照で共有リソースをエクスポートする • 別Stackのリソースの値を参照できる • 参照されている値の変更は不可能 ◦ 依存関係ができるので利用する際は注意が必要
• ハードコードするくらいならクロススタック参照
3. ネストされたスタックを使用して 共通テンプレートパターンを再利用する
• StackとTemplateは別の概念と認識する • Template: 呼び出す際に値を注入して利用 • Stack: AWSリソースを作るための情報を全て持つ • テンプレートが膨大になることを防ぐ
◦ どこに何を書けばよいかわからない状態を防げる 解説!CloudFormation Best Practice ネストされたスタックを使用して共通パターンを再利用する
• StackもCloudFormationで作ることができる • 共通したパターンを別Templateに抽出する • 抽出したTemplateからStackを作成する • ネストされたStackの変更は参照先に伝搬する 解説!CloudFormation Best
Practice AWS::CloudFormation::Stackを使う
解説!CloudFormation Best Practice ネストされたStackを利用するメリット • コピペを減らせる • Stackをコンポーネントに閉じることができる • コンポーネントの保守を分担できる(かも)
4. テンプレートを再利用して 複数環境にスタックを複製する
解説!CloudFormation Best Practice テンプレートを再利用して複数環境にスタックを複製する • CloudFormationは条件式を使った制御が可能 • 開発、テスト、本番の環境を条件式で制御する
• Stackは極力簡潔に書きたい • 条件式による制御をいれると複雑になってしまう • あと、各環境で差分が結構ありそう ◦ 冗長化をしない ◦ 低スペックにする
◦ テスト環境は社内アクセスのみ 解説!CloudFormation Best Practice 個人的な疑問点
実践!CloudFormation Best Practice
実践!CloudFormation Best Practice ディレクトリ構成: StackとTemplateを分ける
• ライフサイクルと所有権によってStackを分ける • 再利用されないことを前提とする • AWSリソースを作るために必要な情報を全て記述 ◦ CloudFormationで管理していないものはここでハードコードする 実践!CloudFormation Best
Practice Stacks: AWSリソースを作るために必要な情報を全て記述する
• 共通したライフサイクルと所有権を持つリソース郡 • <Service>間の連携にはクロススタック参照を用いる • SOAの考えが利用できる部分(かもしれない) 実践!CloudFormation Best Practice <Service>:
ある機能を構成するAWSリソース郡をまとめたもの
• 各層のリソースは類似したライフサイクルと所有権を持つ • 各層はその直下の層に依存する • 各層はネストされたStackとして依存解決を行う 実践!CloudFormation Best Practice <Layer>:
多層アーキテクチャでいう独立したモジュール
• <Service>以下のディレクトリには必ずmaster.yamlを置く • 各層の依存解決を担う • クロススタック参照で使う値のエクスポートも行う 実践!CloudFormation Best Practice master.yaml:
各層の依存解決を行うCloudFormationテンプレート
• 再利用されることを前提に記述する • ParametersやConditionsを使用して制御を行う • よく使う設定をここにまとめる 実践!CloudFormation Best Practice Templates:
共通パターンのテンプレート郡
まとめ
CloudFormation Best Practiceを実践する まとめ 所有者が明確になり、 少ない操作で安全にAWSリソースを更新できる みんなが使うテンプレートの完成!?!
おわり