CDKを活用した 大規模コンテナ移行 プロジェクトの紹介

Transcript

1. JAWS-UG CDK支部 #16 ~CDK Conference 2024 Extra~ 2024/09/25　あきた（yoyoyo_pg） CDKを活用した 大規模コンテナ移行 プロジェクトの紹介
2. • あきた（@yoyoyo_pg） • 経歴 ◦ 名古屋の士業系SaaS ◦ Java開発2年 -> AWS歴2年半 ◦ SREとしてインフラ構築・運用 ◦ JAWS-UG名古屋運営（2024年～） • 好きなAWSサービス ◦ AWS CDK 自己紹介 2
3. 3 話す事 • CDKを用いて100台近くのコンテナ・CICDパイプライ ンの構築フローを定めた事例 ◦ 複数人での構築作業において、構築や運用の手間を 減らすうえで工夫した点や今後の課題 話さない事 • CDKのベストプラクティス • CDK自体の内部構造や技術的な話 • コンテナへのデプロイフロー・移行作業の話 今日お話すること
4. 4 • 20年物のモノリスなJavaアプリケーションのEoL対応 に伴い、約1年かけ動作基盤をEC2からコンテナ(ECS on Fargate)へと移行 ◦ 元々CloudFormationで構築していたVPCやALBなど 共通リソースはそのままで、モノリスを分解しつつ アプリケーションを段階的に移行する形 • コンテナ化・CICDパイプラインの構築のために、IaC ツール(CDK + ecspresso)を導入 プロジェクトの概要
5. Virtual private cloud (VPC) Private subnet Public subnet 5 簡易構成図（移行前） Application Load Balancer Amazon Aurora Amazon EC2 アプリケーション約 15個が同居
6. Virtual private cloud (VPC) Private subnet Public subnet 6 簡易構成図（移行後） Application Load Balancer Service Amazon ECS Container Amazon Aurora Amazon EC2 1アプリケーション=1ECSサービスとし て構築し、段階的に移行
7. 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 8 • 7 環境 × 15 コンテナ = 約 100 パターンのコンテナと 60 パターンのCICDパイプライン ◦ TEST環境×4, デモ環境, STG環境, 本番環境
9. 9 • 約 100 パターンのコンテナ・60 パターンのCICDパイ プラインの構成を定義 ◦ 環境別に 15 アプリケーション分を定義 ◦ 構築量が多く、スタックは分けざるを得なかった CDKスタック構成 ▪コンテナ用スタック • Test1Container • Test2Container • StgContainer • ProdContianer ・・・ ▪CICD用スタック • Test1Cicd • Test2Cicd • StgCicd • ProdCicd ・・・
10. 10 スタック別の構築内容 ▪コンテナ用スタック • ECSクラスター • タスクロール • タスク実行ロール • セキュリティグループ • ターゲットグループ • ロググループ • SSMパラメータストア ▪CICD用スタック • CodePipeline • CodeBuild • buildspec.yml • 各種ロール • 環境別の設定ファイル ▪ecspresso • ECSサービス • ECSタスク
11. 11 大まかな構築の流れ ▪コンテナ用スタック • ECSクラスター • タスクロール • タスク実行ロール • セキュリティグループ • ターゲットグループ • ロググループ • SSMパラメータストア ①コンテナスタックを構築 ②空のターゲットグループ をALBに紐づけ ▪CICD用スタック • CodePipeline • CodeBuild • buildspec.yml • 各種ロール • 環境別の設定ファイル ④CICDパイプラインを構築 ▪ecspresso • ECSサービス • ECSタスク ③コンテナ本体を構築 ※SSMパラメータストアで名前解決
12. 12 • コンテナ・CICDパイプラインの構成を、共通コンスト ラクトとして定義 • 共通コンストラクトには主に「アプリ名」「環境名」 をpropsとして渡す ◦ 共通で構築しないリソースに関しては、権限付与用 の関数を用いて構築 ▪ セキュリティグループやECSタスクロールの内、 本番環境のみメール通知権限、アプリAとアプリ BのみS3アクセス権を付与、など CDKの共通コンストラクト
13. 13 実装例（パラメータとスタック）
14. 14 実装例（パラメータとスタック） アプリ名・環境名を parameter.tsで定義 各アプリがどの機能を 使うかを定義
15. 15 実装例（パラメータとスタック） アプリ名・環境名を parameter.tsで定義 各アプリがどの機能を 使うかを定義 コンテナスタックを 環境別に定義 アプリ別コンテナコン ストラクトを定義
16. 16 実装例（コンストラクト） 権限付与用の関数を 用いて権限の付与
17. 17 • テストコード（スナップショットテスト）導入 ◦ CDKバージョンアップやリファクタリングが容易に • npm install の自動化 ◦ VSCodeの機能（tasks.json）で、プロジェクトを 開いた時に自動的に npm install が走るように ▪ CDKバージョンアップ後にチームにアナウンス する手間を削減 • コーディング規約・運用規約の制定 ◦ 最初にある程度の共通認識をすり合わせておけた ◦ レビュー時のコスト削減 取り組んでよかった事
18. 18 • コンストラクトツリーによる構造化 ◦ 自作コンストラクトを作成しアプリ別に分割 ▪ リソースをCloudFormationの画面上からも、 コードベース上からも確認しやすく • エスケープハッチの活用 ◦ L2からL1を取り出してのパラメータの指定 取り組んでよかった事
19. 19 • cdk import と cdk migrate の実施 ◦ 既存のリソース（手動構築・CFnによる構築）を出 来るだけCDK管理下へ • CDK用パイプラインの導入 ◦ 当時は導入の判断を見送っていた • バリデーションチェックや単体テストの導入 ◦ まずは本番環境用リソースに対して • ecspressoで構築したECSサービス・タスクをどう管理 するかの検討（CDK以外の部分） 今後取り組みたい事
20. 20 • cdk import と cdk migrate の実施 ◦ 既存のリソース（手動構築・CFnによる構築）を出 来るだけCDK管理下へ • CDK用パイプラインの導入 ◦ 当時は導入の判断を見送っていた • バリデーションチェックや単体テストの導入 ◦ まずは本番環境用リソースに対して • ecspressoで構築したECSサービス・タスクをどう管理 するかの検討（CDK以外の部分） 今後取り組みたい事
21. 21 JAWS-UG 名古屋 「IaC運用のリアルを 語りたい！LT大会（仮）」 10月28日（月）19:00～21:00 会場：コラボベース NAGOYA connpass上で後日イベントページを公開します 宣伝
22. 22 ご清聴ありがとうございました おわり
23. 23 次のスライドからは、 本編で紹介しきれなかった 取り組みの例を紹介します おまけ
24. 24 コーディング規約例 • コンストラクト名はパスカルケースで記載 • デフォルトのパラメータは可能な限り活用 • リソースやリソース名は自動生成を可能な限り活用 • GrantやAllow系メソッドは可能な限り活用 設計面の規約例 • 可能な限り同一スタックで定義 • 自作コンストラクト・関数の置き場所の指定 • SSMパラメータ参照・コンストラクト間の値参照の活用 取り組み例：コーディング規約
25. 25 ルール例 • CDK化の基準 ◦ ex. 全てのインフラ操作を「CDKで管理」する訳で はなく、普段メール通知を閉じておくテスト環境は メール通知を閉じておく等 • GitHub上のルール ◦ ブランチ名は作業者名/操作内容 ◦ ラベルによる管理（環境別のラベルを作成） 取り組み例：運用ルールの制定