3年間運用したCDKの失敗から学ぶCDK開発のプラクティス

AWS CDK Conference Japan 2023 3年間運用したCDKの失敗から学ぶ CDK開発のプラクティス 2023/5/20 Yuki Ando

あんどぅ JAWS-UG CDK支部の活動を応援したいおじさん 経済ニュースの事業会社のSREチームのリーダー インフラ畑出身で、コーディングはそこまで得意じゃないです 好きなAWSのサービス：ECS、Cost Explorer、CDK @integrated1453 JAWS-UG SRE支部 2

CDKと私 AWS歴が長いのでCDK自体はGA前のβの頃から触っており、もうすぐ5年近くになります。 初期構築でコードを設計・実装した時間よりも、インフラ担当の日々の運用のお仕事として メンテナンスでコードを修正・適用する時間が多く、コーディングに自信ニキではないです😇 2018年夏頃〜 2019年7月頃(GA後)〜 CDK β (JavaScript) コマンドでAWSリソースのdi 取って 適用(deploy)できる！すごい！😍 マネコンぽちぽちから卒業したい！ CDK (Python) Lambdaと同じPythonで書ける！ Pythonの勉強がんばるぞ〜〜〜💪 2021年10月〜 CDK (TypeScript) CDKやるならTypeScript！ 型がある言語はじめて！楽しい🥳 むしろLambdaもTS一択だわ ff 3

CDKと私 AWS歴が長いのでCDK自体はGA前のβの頃から触っており、もうすぐ5年近くになります。 初期構築でコードを設計・実装した時間よりも、インフラ担当の日々の運用のお仕事として メンテナンスでコードを修正・適用する時間が多く、コーディングに自信ニキではないです😇 プロダクション運用した期間：3年くらい 2018年夏頃〜 2019年7月頃(GA後)〜 CDK β (JavaScript) コマンドでAWSリソースのdi 取って 適用(deploy)できる！すごい！😍 マネコンぽちぽちから卒業したい！ CDK (Python) Lambdaと同じPythonで書ける！ Pythonの勉強がんばるぞ〜〜〜💪 2021年10月〜 CDK (TypeScript) CDKやるならTypeScript！ 型がある言語はじめて！楽しい🥳 むしろLambdaもTS一択だわ ff 4

今日お話するCDK開発のプラクティス 🙅 話さないこと モジュール分割などコードの設計に関するプラクティス 他の方が話してくれるとおもう！（自信ないんや😇 🙆 話すこと スタック分割や適用方法などインフラの運用で便利に使う上でのプラクティス 運用してみて「こっちのやり方のほうがよかったな」と思ったことからの学びです 5

3年間運用したCDKの失敗ベスト３ 個人の感想です 1 環境別の設定をcdk.jsonに書いてcontextオプションで切り替える 2 AWSサービスの単位でスタックを分割してクロススタック参照 3 SSMパラメーターストアにJSONを入れてSDKで取得 6

3年間運用したCDKの失敗ベスト３ 個人の感想です 1 環境別の設定をcdk.jsonに書いてcontextオプションで切り替える 2 AWSサービスの単位でスタックを分割してクロススタック参照 3 SSMパラメーターストアにJSONを入れてSDKで取得 7

環境別の設定が必要になること、あると思います CDKで作成していないVPCのIDとかCIDRのアドレスレンジとか、それ以外にも色々 8

cdk.jsonとcontextオプションの、用意されてる感 BLEAも以前はcdk.jsonに設定を書くサンプルが公開されていたりした cdk.jsonに環境別設定を書く 9

cdk.jsonとcontextオプションの、用意されてる感 BLEAも以前はcdk.jsonに設定を書くサンプルが公開されていたりした cdk.jsonに環境別設定を書く cdkコマンドのオプションで 環境別のContextを指定 10

cdk.jsonとcontextオプションの、用意されてる感 BLEAも以前はcdk.jsonに設定を書くサンプルが公開されていたりした cdk.jsonに環境別設定を書く cdkコマンドのオプションで 環境別のContextを指定 bin/cdk.tsでContextを取得して パラメーターとしてStackに渡す 11

これでよいのでは？🙋 🤔

cdk.jsonとcontextオプションの問題点 運用してみたら、結構不便でしたという話 cdkコマンドに常にオプションが必要という認知負荷 複数環境への一括適用が不便・遅い 設定修正時に、TSの型補完・型制約の恩恵が受けられない 13

cdk.jsonとcontextオプションの問題点 運用してみたら、結構不便でしたという話 cdkコマンドに常にオプションが必要という認知負荷 「cdk ls」で全スタックの一覧が出てきてほしい。エラーが出て「contextに何いれればいいんだっけ？」となる🙁 複数環境への一括適用が不便・遅い 設定修正時に、TSの型補完・型制約の恩恵が受けられない 14

cdk.jsonとcontextオプションの問題点 運用してみたら、結構不便でしたという話 cdkコマンドに常にオプションが必要という認知負荷 「cdk ls」で全スタックの一覧が出てきてほしい。エラーが出て「contextに何いれればいいんだっけ？」となる🙁 複数環境への一括適用が不便・遅い dev1〜dev-Nのすべての環境に適用したいときなど「cdk deploy “dev-*”」が使えない。 「seq 1 9 | xargs -I{} cdk deploy —context dev-{}」などcontextの指定をシェル芸でループすれば良いが、 コマンド・環境ごとにsynthされるので無駄に時間がかかる😩 設定修正時に、TSの型補完・型制約の恩恵が受けられない 15

cdk.jsonとcontextオプションの問題点 運用してみたら、結構不便でしたという話 cdkコマンドに常にオプションが必要という認知負荷 「cdk ls」で全スタックの一覧が出てきてほしい。エラーが出て「contextに何いれればいいんだっけ？」となる🙁 複数環境への一括適用が不便・遅い dev1〜dev-Nのすべての環境に適用したいときなど「cdk deploy “dev-*”」が使えない。 「seq 1 9 | xargs -I{} cdk deploy —context dev-{}」などcontextの指定をシェル芸でループすれば良いが、 コマンド・環境ごとにsynthされるので無駄に時間がかかる😩 設定修正時に、TSの型補完・型制約の恩恵が受けられない 設定が全てjsonの文字列なのでチェックのしようがない。せっかくTSを使ってるなら設定もIDEにチェックしてもらいたい！ 16

設定もTSで書いて、環境が多ければループでスタック作成 BLEAも設定がparameter.tsに書かれるようになっていた 設定用のTSファイルに環境別設定を書く 型も書く（TSのUnion型が便利） bin/cdk.tsでcon gを取得して forループでスタックを作成 →「cdk ls」で全環境のスタック一覧が 表示されるようになり、初心者に優しい fi 17

3年間運用したCDKの失敗ベスト３ 個人の感想です 1 環境別の設定をcdk.jsonに書いてcontextオプションで切り替える 2 AWSサービスの単位でスタックを分割してクロススタック参照 3 SSMパラメーターストアにJSONを入れてSDKで取得 18

スタックはデプロイの単位だから、 ライフサイクルが異なる場合は分けるべき ほな、データベースはアプリケーションと 別でメンテできるようにスタック分割や！ 🤓

やっちまったしくじり Service A, Service BからRDSを共有するときのスタック構成 20

やっちまったしくじり デプロイのタイミングが違うので、このスタック分割自体はそこまで悪くないはず Service A, Service Bの Security groupを接続許可したい！ 21

やっちまったしくじり クロススタック参照でISecurityGroupを受け取って、Database Stack側で接続許可 Service A, Service Bの Security groupを接続許可したい！ 22

これでDatabase Stackはインフラチームが、 Service A,Bはアプリチームが自由にcdk deployできるぞい 🤓

やっちまったしくじり Serviceのスタックは、開発中の手動ガチャガチャで上手く動かなくなって作り直したいときがある Service B Stack、検証のために 手動でガチャガチャいじったら なんか設定おかしいから cdk destroy & deployしよっと 🧑💻 24

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある そのセキュリティグループ、 俺が見てるから削除させねーよ！？ Service B Stack、検証のために 手動でガチャガチャいじったら なんか設定おかしいから cdk destroy & deployしよっと 🧑💻 25

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある なんか依存先があるからそっちを先 に消さないといけないのか〜 じゃぁDatabase Stackを cdk destroyっと 削除 🧑💻 26

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある なんか依存先があるからそっちを先 に消さないといけないのか〜 じゃぁDatabase Stackを 先にcdk destroyっと 削除 🧑💻 27

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある Service Aにつながらない〜🥺 DBの霊圧が…消えた…？ 👩💻 💦 削除 🧑💻 28

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある 👩💻 💦 削除・再作成 お、これでService B消せるように なったわ。 cdk destroy & deployっと Databaseも作り直すか 🧑💻 削除・再作成 29

やっちまったしくじり Serviceのスタックは、開発中のガチャガチャで上手く動かなくなって作り直したいときがある テストデータが消えてる〜😭 👩💻 💦 復旧完了〜〜〜✌ 🧑💻 30

やっちまったしくじり スタック間で接続許可をするための参照で、誰にとっても嬉しくない依存関係の制約ができてしまった Service AとService Bなしでは Database Stackが存在できない DatabaseStackからの参照が存在 StackがService Aと Database Service Bなしでは存在できない する限り削除・再作成ができない 31

クロススタック参照の依存関係による運用の制約を理解すること 依存の向きが逆ならまだマシだった（Database Stackは自由に消せなくなるが） Database StackがServicegroup Aと Database StackのSecurity Service Bなしでは存在できない に対する通信許可をそれぞれ追加 32

クロススタック参照をやめるにはSSMパラメータストア参照を クロススタック参照がなければ全スタックが好きなタイミングでリソースの削除・再作成できる☺ Database StackがServicegroup Aと Database StackのSecurity Service Bなしでは存在できない に対する通信許可をそれぞれ追加 33

3年間運用したCDKの失敗ベスト３ 個人の感想です 1 環境別の設定をcdk.jsonに書いてcontextオプションで切り替える 2 AWSサービスの単位でスタックを分割してクロススタック参照 3 SSMパラメーターストアにJSONを入れてSDKで取得 34

よっしゃ、スタック間のパラメーター受け渡しは 全部SSMパラメーターストアに入れたらええんやな 🤓

アプリから参照が必要な設定を1つのSSMパラメーターに入れる パラメータごとに作るのめんどいし、使うときにJSON.parse()してもらえばおｋ。天才かな？（雑） JSONをギュッと詰め込んだ 神SSMパラメータストアを作る ための共用スタック 36

bin/cdk.tsの中で、SDKで取得してparseして渡していく 各Serviceスタックを作る前に、渡したい共通の設定を変数に入れて、それを渡す SSMClientを利用して SSMパラメータストアから 神SSMパラメーターを取得する関数 神SSMパラメーターを取得して JSON.parseして変数に入れる これを各サービススタックに渡す 37

神SSMパラメーターとSDK利用の問題点 運用してみたら、結構不便でしたという話 cdkコマンドの̶pro leオプションだけではロールの切り替え不可 「cdk ls ̶pro le dev」などを使ってもSDKにはプロファイルの情報が渡らない。 「AWS̲PROFILE=dev cdk ls」などする必要がある。環境変数AWS̲PROFILEはcdkコマンド・SDKどちらにも渡るため CDKのコマンドの定石通りに行かないので、これを意識してコマンド打たないといけないのが、なかなか認知負荷 cdk lsの時にもAWSの認証が必要 SSMパラメーターをCDKの「fromStringParameterAttributes()」で取得する場合は、 cdk lsの時にはdummyの値が入ってスタックを生成できるので、認証が要らない。 スタックの生成のためのパラメーター取得にSDKを利用していると、lsしたいだけなのに認証が必要になる。 JSONが格納されたSSMパラメータストア、コンソールで読みづらい たくさんのパラメーターがJSON1行に詰まっているので、コンソールで確認するのも大変 fi fi 38

SSMパラメータストアに格納するのもいいけど、名前で参照もあり CDKアプリケーション内で命名ルールを決められるなら、fromLookupByNameも便利 StackやConstruct内で、 CDKアプリケーション内で 「この命名でリソースが作られている はず」で参照する 39

本日話した「3年間運用したCDKの失敗」ベスト３ CDKはアプリと違い「インフラを運用しやすくするために書く」ところがポイントだと思いました 1 環境別の設定をcdk.jsonに書いてcontextオプションで切り替える 環境別の設定はTSで書いて、「cdk ls」で全スタックが表示されるようにしよう！初心者に優しく 2 AWSサービスの単位でスタックを分割してクロススタック参照 スタック分割するのはいいけど、クロススタック参照の運用上の制約を理解して慎重に！迷ったら使わない 3 SSMパラメーターストアにJSONを入れてSDKで取得 横着せずにSSMパラメーターは一つずつ作るか、名前でlookupしよう！ 40

＼ご清聴ありがとうございました／