Slide 1

Slide 1 text

#jawsug_nagoya IaC運用を楽にするためにCDK Pipelinesを導入した けど、思い通りにいかなかった話 Masaki Suzuki 2024/10/28 JAWS-UG 名古屋 IaC運用のリアルを語りたい!LT大会

Slide 2

Slide 2 text

#jawsug_nagoya アジェンダ 1. CDK Pipelines導入の背景 2. 発生した問題 3. まとめ(反省点) 4. 参考情報 2

Slide 3

Slide 3 text

#jawsug_nagoya 自己紹介 ◼ 名前: 鈴木 正樹 (Masaki Suzuki) ◼ Job: クラウドアーキテクト&バックエンドエンジニア(※現職では違う) ◼ 主な活動拠点: JAWS-UG 名古屋支部 & CDK支部 ◼ 好きな技術: • AWS(特にLambda), その他サーバーレスバックエンド全般 • Infrastructure as Code(特にAWS CDK), CI/CD (GitHub Actions, AWS CodePipeline) etc. • 好きなAWSサービス:AWS Lambda, CDK ◼ SNS: • @makky12 (SUZUKI Masaki@クラウドエンジニア) • @makky12.bsky.social • https://github.com/smt7174/ • http://makky12.hatenablog.com/ 3

Slide 4

Slide 4 text

#jawsug_nagoya 自己紹介その2 4 • 5/17(金)発売のSoftware Design6月号にて、Bun.jsの記事を寄稿しました • 第2特集の「実証Bun 次世代JavaScriptランタイムの実態に迫る」の第1章お よび第3章を執筆しています

Slide 5

Slide 5 text

#jawsug_nagoya 注意事項 ◼ 本資料に登場するCodePipelineのバージョンはV1となっています(重要!) ◼ 今回の発表資料・発言内容は、すべて個人の見解・知見になります ◼ 本資料は、下記URLで公開しています • この資料です 5

Slide 6

Slide 6 text

#jawsug_nagoya 1. CDK Pipelines導入の背景

Slide 7

Slide 7 text

#jawsug_nagoya 前提 ◼ 業務でこんなアプリを作ることに(重要な部分のみ抜粋。赤枠が重要な箇所) 7 AWS Coud Virtual private cloud (VPC) Private subnet Public subnet Private subnet Aurora CodePipeline ECS ECR API Gateway Lambda(Web) SES Email NAT gateway Lambda (Mail Handling) GitHub (Infra/Frontend) Device

Slide 8

Slide 8 text

#jawsug_nagoya チーム状態 & CDK Pipelines導入決定まで 8 The Power of PowerPoint - thepopp.com ◼ メンバーで誰もAWSに詳しい人がいない(※1) ◼ サービス開始まで時間がなく、詳しく教える時間がない… ◼ CodePipelineによるCD構成をシンプルに作ってくれる機能が必要 ↓ ◼ CDK Pipelinesがあるじゃないか!(※2) ※1:本当に「AWS?IaC?なにそれおいしいの?」というレベル ※2:AWS CDKで、 AWS CodePipelineを利用したアプリケーションのデプロイパイプラインを構築 するためライブラリ(詳細は下記資料を参照) https://speakerdeck.com/smt7174/cdk-pipelineswozatukurili-jie-suru

Slide 9

Slide 9 text

#jawsug_nagoya CDK Pipelinesのメリット(≒理想の運用) 9 The Power of PowerPoint - thepopp.com ◼ CodePipelineについて、最小限のCDK定義で済む ◼ Codeファミリー(Commit, Build, Deploy)の個別定義が不要(※1) ◼ メンバーがまずアプリ(スタック)の運用に注力できる(※2) ◼ アプリ側の仕様は理解しているなので(多分)、そこからAWSやIaCについて少しづつ知ってもらう ◼ まずアプリの運用をこなしつつ、メンバーのスキルアップも図れる ◼ …はずでした(ネタバレ) ※1:CDK PipelinesはL3コンストラクタで、CI/CDプロセス全体を1コンストラクタで定義可能 ※2:CDK Pipelinesでは、メインスタック(CodePipeline関連を定義するスタック)とは別に、それ以 外のリソース(アプリで使用するリソース)を定義するスタックを設定する(今回は便宜上「アプリスタッ ク」と表記)

Slide 10

Slide 10 text

#jawsug_nagoya 2. 発生した問題

Slide 11

Slide 11 text

#jawsug_nagoya 問題1:スタック間で引数を渡せない 11 The Power of PowerPoint - thepopp.com ◼ メインスタックとアプリスタック間で、引数(VPC ID)を渡せない ◼ この2つはCodePipelineで別のステージとして構成されるため (※1) ◼ 今回はECS・LambdaをVPC内に配置するため(※2)、どうしてもVPC IDを受け渡す必要があった ◼ CloudFormation OutputやAWS CLIを使用したが、どれもうまくいかず ◼ 最終的に、VPC内に配置するリソースは全てメインスタックに定義 ◼ 結果メインスタックが肥大化し、運用が大変になるという結果に…(※3) ※1:これはCDK Pipelinesというより、CodePipelineの仕様です ※2:正確にはLambdaは「VPC内のリソースにアクセスできる」のであり、VPC内に配置されるわけではありま せん ※3:その結果、スタックのリソース上限(Max500個)に引っかかりかねない事態に…

Slide 12

Slide 12 text

#jawsug_nagoya 問題2:ECRにイメージがないと、Lambdaがデプロイできない 12 The Power of PowerPoint - thepopp.com ◼ Lambdaのソースコードは、ECRにDockerイメージとして保存(※1) ◼ CDKの初回デプロイ時、上記イメージ(厳密にはECR)が存在しないため、 デプ ロイ時エラーになる(※2) ◼ 「初回限定のDockerイメージを作成する」「初回かどうかで処理を分ける」など、 追加処理が必要に ◼ 結果、メインスタックがさらに複雑になり、ここでも運用が大変になる結果に ※1:インフラとアプリでGitHubリポジトリを分離し、アプリ側単体開発できるようにするため ※2:ECR自体はメインスタックで定義しているので、1回デプロイしないとECR自体が作成されない

Slide 13

Slide 13 text

#jawsug_nagoya 3. まとめ(反省点)

Slide 14

Slide 14 text

#jawsug_nagoya まとめ(反省点) 14 The Power of PowerPoint - thepopp.com ◼ 「できるだろう」で終わらず、まず「小さく早く」試す (※1) ◼ 確かにCDK PipelinesはCI/CDの構成をシンプルに構成できるが、それ以 外の部分にも注意を払う (※2) ◼ 「アーキテクチャはトレードオフ」であることを理解し(※3)、全体を俯瞰した 上で最適解を見つける(1つの手法に固執せず、柔軟に考える) ※1:これは別にCDK Pipelinesに限った話ではないですが… ※2:最終的に「アプリスタックにはSESのみ存在し、それ以外はすべてメインスタックに存在する」という 構成になり、メインスタックが大きくなりすぎるという結果になってしまいました… ※3:「ソフトウェアアーキテクチャの基礎 - エンジニアリングに基づく体系的アプローチ」より

Slide 15

Slide 15 text

#jawsug_nagoya 4. 参考情報

Slide 16

Slide 16 text

#jawsug_nagoya 「初回限定のDockerイメージ作成が必要」の件について 16 The Power of PowerPoint - thepopp.com ◼ 今回のようにLambdaソースにDockerイメージを適用すると、「初回デプ ロイ時限定のDockerイメージの作成」が必要になることがある(※1) ◼ 「cdk-ecr-deployment」というAWS公式OSSを使うと、この「初回デプロイ 時限定のDockerイメージ作成」をシンプルに実装可能(※2) ◼ 具体的な実装方法については、私のブログ(※3)で紹介していますので、よ ろしければご参照ください(今回はソースの説明は割愛します) ※1:LambdaソースにDockerイメージを適用するケースで、イメージ格納先ECRとLambdaを同じス タックで定義していると、割と起こりうるんじゃないか思います。 ※2:もちろん、初回限定でなくても使用可能です(むしろ普段使いの用途がメインだと思います) ※3:https://makky12.hatenablog.com/entry/2023/10/23/120500

Slide 17

Slide 17 text

#jawsug_nagoya 「スタック間で引数(VPC ID)を渡せない」件について 17 The Power of PowerPoint - thepopp.com ◼ 先述の通り、CodePipelineではステージ間で引数を渡すことはできない ◼ ただしV2から「パイプライン変数」が追加され、同じCodePipeline内の全 ステージから同じ変数を参照することが可能になった ◼ 今回のケースも、V2ならばVPC IDをパイプライン変数に設定することで、 問題なく対処可能(※1) ※1:実装当時、まだV2がなかった(サービス開始直前&本番デプロイ直前というタイミングでV2が発表 された。もう少しV2が早く出ていれば…)

Slide 18

Slide 18 text

#jawsug_nagoya ちなみに ◼ 9/25(水)のJAWS-UG CDK支部#16において、僕のセッションでパイプライン変数 のことを紹介したら、パイプライン変数の実装者であるAWS Hero 後藤さんが「僕 が作りました」ポストを… ◼ まさか「そいつの開発者 俺だもん」をリアルで聞くとは思いもしませんでしたw 18

Slide 19

Slide 19 text

#jawsug_nagoya ご清聴ありがとうございました 以上です