JAWS-UG CDK支部 #16 ~CDK Conference 2024 Extra~ 2024/09/25　あきた（yoyoyo_pg） CDKを活用した 大規模コンテナ移行 プロジェクトの紹介

● あきた（@yoyoyo_pg） ● 経歴 ○ 名古屋の士業系SaaS ○ Java開発2年 -> AWS歴2年半 ○ SREとしてインフラ構築・運用 ○ JAWS-UG名古屋運営（2024年～） ● 好きなAWSサービス ○ AWS CDK 自己紹介 2

3 話す事 ● CDKを用いて100台近くのコンテナ・CICDパイプライ ンの構築フローを定めた事例 ○ 複数人での構築作業において、構築や運用の手間を 減らすうえで工夫した点や今後の課題 話さない事 ● CDKのベストプラクティス ● CDK自体の内部構造や技術的な話 ● コンテナへのデプロイフロー・移行作業の話 今日お話すること

4 ● 20年物のモノリスなJavaアプリケーションのEoL対応 に伴い、約1年かけ動作基盤をEC2からコンテナ(ECS on Fargate)へと移行 ○ 元々CloudFormationで構築していたVPCやALBなど 共通リソースはそのままで、モノリスを分解しつつ アプリケーションを段階的に移行する形 ● コンテナ化・CICDパイプラインの構築のために、IaC ツール(CDK + ecspresso)を導入 プロジェクトの概要

Virtual private cloud (VPC) Private subnet Public subnet 5 簡易構成図（移行前） Application Load Balancer Amazon Aurora Amazon EC2 アプリケーション約 15個が同居

Virtual private cloud (VPC) Private subnet Public subnet 6 簡易構成図（移行後） Application Load Balancer Service Amazon ECS Container Amazon Aurora Amazon EC2 1アプリケーション=1ECSサービスとし て構築し、段階的に移行

7 簡易構成図（移行後） Application Load Balancer Amazon ECS ServiceA Amazon Aurora ServiceE ServiceI ServiceB ServiceF ServiceJ ServiceD ServiceH ServiceC ServiceG ServiceK Virtual private cloud (VPC) Private subnet Public subnet

構成図（全体） 8 8 ● 7 環境 × 15 コンテナ = 約 100 パターンのコンテナと 60 パターンのCICDパイプライン ○ TEST環境×4, デモ環境, STG環境, 本番環境

9 ● 約 100 パターンのコンテナ・60 パターンのCICDパイ プラインの構成を定義 ○ 環境別に 15 アプリケーション分を定義 ○ 構築量が多く、スタックは分けざるを得なかった CDKスタック構成 ■コンテナ用スタック ● Test1Container ● Test2Container ● StgContainer ● ProdContianer ・・・ ■CICD用スタック ● Test1Cicd ● Test2Cicd ● StgCicd ● ProdCicd ・・・

10 スタック別の構築内容 ■コンテナ用スタック ● ECSクラスター ● タスクロール ● タスク実行ロール ● セキュリティグループ ● ターゲットグループ ● ロググループ ● SSMパラメータストア ■CICD用スタック ● CodePipeline ● CodeBuild ● buildspec.yml ● 各種ロール ● 環境別の設定ファイル ■ecspresso ● ECSサービス ● ECSタスク

11 大まかな構築の流れ ■コンテナ用スタック ● ECSクラスター ● タスクロール ● タスク実行ロール ● セキュリティグループ ● ターゲットグループ ● ロググループ ● SSMパラメータストア ①コンテナスタックを構築 ②空のターゲットグループ をALBに紐づけ ■CICD用スタック ● CodePipeline ● CodeBuild ● buildspec.yml ● 各種ロール ● 環境別の設定ファイル ④CICDパイプラインを構築 ■ecspresso ● ECSサービス ● ECSタスク ③コンテナ本体を構築 ※SSMパラメータストアで名前解決

12 ● コンテナ・CICDパイプラインの構成を、共通コンスト ラクトとして定義 ● 共通コンストラクトには主に「アプリ名」「環境名」 をpropsとして渡す ○ 共通で構築しないリソースに関しては、権限付与用 の関数を用いて構築 ■ セキュリティグループやECSタスクロールの内、 本番環境のみメール通知権限、アプリAとアプリ BのみS3アクセス権を付与、など CDKの共通コンストラクト

13 実装例（パラメータとスタック）

14 実装例（パラメータとスタック） アプリ名・環境名を parameter.tsで定義 各アプリがどの機能を 使うかを定義

15 実装例（パラメータとスタック） アプリ名・環境名を parameter.tsで定義 各アプリがどの機能を 使うかを定義 コンテナスタックを 環境別に定義 アプリ別コンテナコン ストラクトを定義

16 実装例（コンストラクト） 権限付与用の関数を 用いて権限の付与

17 ● テストコード（スナップショットテスト）導入 ○ CDKバージョンアップやリファクタリングが容易に ● npm install の自動化 ○ VSCodeの機能（tasks.json）で、プロジェクトを 開いた時に自動的に npm install が走るように ■ CDKバージョンアップ後にチームにアナウンス する手間を削減 ● コーディング規約・運用規約の制定 ○ 最初にある程度の共通認識をすり合わせておけた ○ レビュー時のコスト削減 取り組んでよかった事

18 ● コンストラクトツリーによる構造化 ○ 自作コンストラクトを作成しアプリ別に分割 ■ リソースをCloudFormationの画面上からも、 コードベース上からも確認しやすく ● エスケープハッチの活用 ○ L2からL1を取り出してのパラメータの指定 取り組んでよかった事

19 ● cdk import と cdk migrate の実施 ○ 既存のリソース（手動構築・CFnによる構築）を出 来るだけCDK管理下へ ● CDK用パイプラインの導入 ○ 当時は導入の判断を見送っていた ● バリデーションチェックや単体テストの導入 ○ まずは本番環境用リソースに対して ● ecspressoで構築したECSサービス・タスクをどう管理 するかの検討（CDK以外の部分） 今後取り組みたい事

20 ● cdk import と cdk migrate の実施 ○ 既存のリソース（手動構築・CFnによる構築）を出 来るだけCDK管理下へ ● CDK用パイプラインの導入 ○ 当時は導入の判断を見送っていた ● バリデーションチェックや単体テストの導入 ○ まずは本番環境用リソースに対して ● ecspressoで構築したECSサービス・タスクをどう管理 するかの検討（CDK以外の部分） 今後取り組みたい事

21 JAWS-UG 名古屋 「IaC運用のリアルを 語りたい！LT大会（仮）」 10月28日（月）19:00～21:00 会場：コラボベース NAGOYA connpass上で後日イベントページを公開します 宣伝

22 ご清聴ありがとうございました おわり

23 次のスライドからは、 本編で紹介しきれなかった 取り組みの例を紹介します おまけ

24 コーディング規約例 ● コンストラクト名はパスカルケースで記載 ● デフォルトのパラメータは可能な限り活用 ● リソースやリソース名は自動生成を可能な限り活用 ● GrantやAllow系メソッドは可能な限り活用 設計面の規約例 ● 可能な限り同一スタックで定義 ● 自作コンストラクト・関数の置き場所の指定 ● SSMパラメータ参照・コンストラクト間の値参照の活用 取り組み例：コーディング規約

25 ルール例 ● CDK化の基準 ○ ex. 全てのインフラ操作を「CDKで管理」する訳で はなく、普段メール通知を閉じておくテスト環境は メール通知を閉じておく等 ● GitHub上のルール ○ ブランチ名は作業者名/操作内容 ○ ラベルによる管理（環境別のラベルを作成） 取り組み例：運用ルールの制定