とあるチームの手動作業の多いCloudFormation運用とその改善

Transcript

1. とあるチームの手動作業の多い CloudFormation運用とその改善 山本 直弥 JAWS-UG 名古屋 IaC運用のリアルを語りたい！LT大会 2024年10月28日
2. 自己紹介 名前：山本 直弥 所属：株式会社シーイーシー＠名古屋 2023-2024 Japan AWS All Certifications Engineer JAWS登壇： オフラインは今回が初 好きなAWSサービス： AWS Lambda AWS Step Functions AWS CloudFormation 1 ※Xのアイコン X：@Nao_Engineer_AC
3. この発表について ⚫話すこと ⚫一言で言うと：CloudFormationテンプレートをより簡単に作るには？ CloudFormation (Cfn)とは 過去のPJの課題 Former2運用の課題 課題を改善するためにどんな運用やツールを選ぶか AWS Infrastructure Composer (旧 Application Composer) ⚫話さないこと ⚫CDK、Terraform、CI/CD 2
4. テンプレート CloudFormation（Cfn）とは？ 3 • YAML/JSONで記述されたテンプレートを元にAWS リソースをデプロイする • メリット ➢リソースをコードで管理するので各リソースの設定の確認、変更管理が容易 ➢一括で デプロイできるのでリリースの負荷や手動操作の設定ミスのリスク減少 ➢関連する機能やツールが多い リソース スタック 各リソースの状態を YAML/JSONで定義したもの テンプレートからプロビ ジョニングされるリソー スの集合 コード(YAML/JSON) → リソース
5. Cfnの再利用性：デプロイ時のパラメータ指定 4 • 複数アカウントで運用する際にParameters、Mappingの活用することで 1つのテンプレートで各環境のリソース定義を管理可能 • 環境毎にテンプレートを作成する手間を減らすことができる ①Parametersセクションにパラメータ設定 ②Resourceセクションでパラメータ呼び出し ③スタック作成時に環境に合わせてパラメータ選択 ④環境に合わせてリソースができる ＜Parameter設定例＞
6. CfnのPolicy as Code：AWS CloudFormation Guard • AWS CloudFormation Guard（Cfn-guard） • 独自ルールを定義してテンプレート定義の正しさを検証 • 意図せぬ設定でデプロイされることを防ぐ Template <例> Lambda タイムアウト=◦◦ メモリサイズ＝◦◦ など任意ポリシーを定義 ※単項演算子 (exists,is_string等)、二項 演算子(==,>=等)で評価 CloudFormation Stack ※Cfnテンプレートを元にルール ファイルを作成することも可能 Cfn-guard Template Cfn-guard 意図せぬ変更がないか 定義したルールに従っているか
7. スキャン/選択したものを テンプレート化 機能を作りこみ(マネコンでも可) Former2：環境を一括テンプレ化 6 AWSマネコンでリソースを作った後にそのままテンプレート化できる １行もコード(YAML/JSON)を書くことなくテンプレートが作れる テンプレート作成まで自動でできるの最高！ • AWSアカウントを内の既存リソースをスキャン • 任意の選択したリソースの定義をそのままテンプレートが作成できる • IaCジェネレータに似たツール Template テンプレートから リソース定義反映 Stack リソース → コード(YAML/JSON)
8. 過去のPJの概略図 DEVアカウント STG/PRD兼用アカウント EC2 instance contents AWS Step Functions workflow Stack （STG) Stack (PRD) AWS Step Functions workflow Template • DEVは各リソースを手動作成しているサーバレス系サービスが多いシステム • STG/PRDデプロイ時にFormer2で一連の機能ごとにCfnテンプレート作成 • Former2で出力したテンプレートをSTG/PRDにデプロイ AWS Step Functions workflow Management Console スキャン Former2のおかげでIaC運用が簡単に行えそう ノーコードでテンプレ出力
9. 一括テンプレ化の課題 • 別環境用のパラメータ化の際に結局、手作業修正が発生 • 環境固有の設定値が固定値で出力されるので修正が必要 (リソース名、ARN、SfnステートマシンのJSON定義内のARN） • 一連の機能の大きなテンプレートを一括手修正するため、修正ミス発生 • 一度の手作業修正の範囲が大きい • DEV環境開発後にテンプレ化するため、 開発時に行った設定のテンプレ化忘れも発生しやすい 8 ①DEVをそのまま テンプレート化 ③手動修正による修正漏れや テンプレ化忘れ発見、再修正 ②環境に合わせるための手作業編集 めちゃ手作業 時間もかかる DEV_Function1 →${Env}_Function1 など各種変数化 ＜Former2を使った別環境デプロイ作業イメージ＞ Stack Template Template テンプレート化忘れの リスク有り
10. 運用を改善：DEV開発時点からIaC管理 9 DEVアカウント STG/PRD兼用アカウント AWS Step Functions workflow Stack （STG) Stack (PRD) AWS Step Functions workflow Template AWS Step Functions workflow Stack （DEV) DEV開発の段階でテンプレ作成 →開発完了時点でテンプレの正しさは検証できているはず DEVで検証済みのテンプレを再利用 手作業のリスクを回避 リリースの準備負荷軽減
11. でもゼロからコード化は難しい 10 • Former2運用から脱するときの課題 • ゼロからコード(YAML)を書くのは苦労しそう。学習コストが高い →Former2ならGUI操作だけでテンプレ化できた • 既に運用されているSTG/PRD用テンプレートに影響を出したくない 既存テンプレートへの影響は出したくない しかし、Cfn運用方法は変えたい かといって、IaCコードを手動で作るのはハードルが高い
12. AWS Infrastructure Composer で簡単にCfnテンプレートを作ろう 11 • CloudFormationテンプレートをGUI操作で作成/編集できるツール(既存テンプレートも利用可能) • ローカル環境のVSCode上でも操作できる テンプレートの内容が キャンバス上で 視覚的に確認できる GUI操作結果を テンプレートに自動反映
13. 特に拡張コンポーネントはより直感的に操作できる 12 StepFunctionsのワークフロースタジオ Lambdaの各種設定(穴埋め式で作れる) 拡張コンポーネント：サーバレス系リソース リソースの関連付けも線をつなげるだけ
14. 標準コンポーネントもAmazonQで定義生成 13 • AmazonQと連携してボタン一つで自動生成。 • なじみのないサービスも安心 ②生成ボタン ①初期設定 ④生成後 値の微調整だけで動きそうな 定義が提案される ③生成中 （数十秒） 標準コンポーネント：Cfn可能なリソース
15. 自動生成以外のCfn運用を助ける機能も充実 14 • 自動変更された箇所の表示 環境変数やポリシーの定義など自動 反映された差分が表示できる • グループ化 機能のまとまりをグルー プ化してさらに見やすい これなら学習コストも抑えながら ゼロからコード化もできそう 既存テンプレートもそのまま使える
16. 最後に • Former2が良くないツールだということではない • 既存環境を一括でCfnテンプレート化して既存環境用に運用するなら Former2は最高のツールの一つ • プロジェクトの特性やメンバーの成熟度によっても 選択するツールが変わる。今後もツールや運用方法を学んで 改善を進めていきたい 15 AWS Infrastructure ComposerもFormer2も最高 いろんなツールや運用方法を研究して安心して楽できる方法探したい
17. ご清聴ありがとうございました 16