CDK初心者が開発で遭遇したトラブルと解決法

Transcript

1. CDK初心者が開発で 遭遇したトラブルと解決法 大畠 敬就 @Figure_Skate_IT
2. Profile 大畠 敬就 （Ohata Takanari） X：@Figure_Skate_IT Qiita：https://qiita.com/Figure_Skate_IT 2023年４月入社、AWS歴：1年 CDK、Typescript歴：6ヶ月 基盤メンバーとして構築・バグ修正を担当 趣味：フィギュアスケート・資格勉強
3. Agenda CDK初心者が遭遇したトラブルについて、 プログラミング・デプロイ・作成困難な点の３つに分けて簡単に紹介する。 同内容はQiitaにも投稿した。 CDK初心者が開発で遭遇したトラブルと解決法 #AWS - Qiita 1.Programming 1.1. クラス構成に関する思想のずれ ★★★ 1.2. 配列利用によるトラブル★☆☆ 1.3. 設定値外だしに関するトラブル★★☆ 1.4. リファクタ時のトラブル★☆☆ 2.Deployment 2.1. 同名リソース作成によるデプロイエラー★★☆ 2.2.スタック間参照トラブル★★★ 2.3.リソース作成順序エラー★☆☆ 2.4.スタックに作成可能なリソース数上限★★☆ 3.Difficult to Create 3.1.S3クロスリージョンレプリケーション★★☆ 3.2.Aurora作成時等に自動作成されるロググループの設定変更★☆☆
4. 1.Programming：1.1. クラス構成に関する思想のずれ★★★ class Logs(){ new logs1 new logs2 new logs3 } class Firehose(){ new firehose1 new firehose2 new firehose3 } class S3(){ new bucket1 new bucket2 new bucket3 } new s3.bucket( this,”bucket1”,{ 共通設定１ 共通設定２ ・・・ 個別設定１ ・・・ }) new s3.bucket( this,”bucket2”,{ 共通設定１ 共通設定２ ・・・ 個別設定１ ・・・ }) バケット３ ・・・ 共通の設定を まとめる べた書き s3ComProps={ 共通設定１ 共通設定２ ・・・ } new s3.bucket( this,”bucket1”,{ …S3ComProps, 個別設定１ ・・・ }) new s3.bucket( this,”bucket1”,{ …S3ComProps, 個別設定１ ・・・ }) バケット3 ・・・ ラッパー関数、 ラッパーConstruct ラッパークラス（Construct継承無） bucket1 = createS3(this,bucket1,{個別設 定}) bucket2 = createS3(this,bucket2,{個別設 定}) bucket3 = createS3(this,bucket3,{個別設 定}) ・・・ function createS3(scope,id,props){ const myBucket = new s3.bucket(scope,id,{ 共通設定１ 共通設定２ props.個別設定１ ・・・ }) return myBucket } sfnlog = LogsToS3() lambdalog = LogsToS3() containerlog = LogsToS3() class LogsToS3(){ new logs new firehose new s3 } サービス単位の クラス分割（L2+） 機能単位の クラス分割(L3) 作成したクラス内で ラッパー関数等を 利用する合わせ技も！ プログラミングは自由度が高く、思想がずれる。アプリ的な詳細設計をして思想を揃えよう。 CDKプログラミングのパターン #AWS - Qiita
5. 1.Programming：1.2. 配列利用によるトラブル★☆☆ NW App1 App2 DB 参照 SG Subnet const mySGConfigs=[ {sg1の情報} {sg2の情報} {sg3の情報} {sg4の情報} ] const mySGs:ec2.SecurityGroup[]= [] for (i in sgConfigs){ mySGs[i] = new ec2.SecurityGroup( this, mySGConfig[i].id, mySGConfig.props) } sg2が不要になり削除 →配列の番号がずれる！！ コードの他部分にも影響発生 type mySGDict = {[key:string]:ec2.SecurityGroup} const mySGs:mySGDict = {} for (config of sgConfigs){ mySGs[config.id] = new ec2.SecurityGroup( this, config.id, conig.props) } 辞書型を用いると、 削除されても該当 key Valueが消えるだけ 配列を利用すると、要素を削除した際に番号がずれる。 代わりに辞書型を利用しよう。
6. 1.Programming：1.3. 設定値外だしに関するトラブル★★☆ # lambda関数の環境差分 lambdaConfig:{ functionName:”prd-lambda” logRetention: logs.RetentionDays.THREE_MONTHS # 本番は三ヶ月、開発は一ヶ月ログ保存 } コメント利用可能 ①JSONではなく.tsファイルに外だししよう Cdk.json等のjsonファイルでは、コメントや CDK独自のenum型等が利用できない。 設定値外出しの際はconfigを使って.tsファイ ルを利用しよう。 【AWS】Configで分けるCDK環境の紹介【CDK】｜ 朝日新聞社 メディア研究開発センター (note.com) enum型利用可能 ②どこまで外だしすべきか 人によってどこまで定数を外出しすべきか、 基準が違うことがある。 プロジェクトとして認識をそろえよう。 外出しを行う基準（例） ・現在の環境差分のみ ・将来環境差分が発生し得るもの ・リソース名（スタック間参照避けるため） ・すべての定数（極論）
7. 1.Programming：1.4. リファクタ時のトラブル★☆☆ べた書きしていたリソースをconstructを継承したクラスにリファクタすると、論理IDが変化してリソ ースが再作成される。（リソース名を明示的に指定した場合、同名リソース作成デプロイエラー発生） ※Constructを継承しないクラスやラッパー関数を利用すると、論理IDを変えずにリファクタ可能。 new s3.bucket( this,”bucket1”,{ 共通設定１ 共通設定２ ・・・ 個別設定１ ・・・ }) new s3.bucket( this,”bucket2”,{ 共通設定１ 共通設定２ ・・・ 個別設定１ ・・・ }) bucket1 = createS3(this,bucket1,{個別設 定}) bucket2 = createS3(this,bucket2,{個別設 定}) bucket3 = createS3(this,bucket3,{個別設 定}) ・・・ class createS3 extends construct (scope,id,props){ constructor( super(scope,id) const myBucket = new s3.bucket(scope,id,{ 共通設定１ 共通設定２ props.個別設定１ ・・・ }) べた書き クラス化（Construct継承） リファクタ リソース 再作成 トラブル！
8. 2.Deployment：2.1. 同名リソース作成によるデプロイエラー★★☆ ・同じ名前のリソースが既に存在すると、デプロイエラーが発生。 ・ステートフルリソースの再作成を伴う変更（例：dbの暗号化）があった場合もデプロイエラー発生。 ・デプロイ失敗してロールバックした際、新規作成されたステートフルリソースの削除が必要。 例：S3、ECR、ロググループ、（ログストリーム）、db、等 対策 ①リソース名を明示的に指定しない（CDK推奨） ②ステートフルリソース名の末尾等に識別番号を付与 ③ロールバック時は削除されるようRemoval PolicyにRETAIN_ON_UPDATE_OR_DELETEを指定 ロググループの 削除忘れで 何度もエラーが 発生することも
9. 2.Deployment：2.2. スタック間参照トラブル★★★ ①循環参照エラー 参照元で生成したリソースを参照先のスタッ クで変更できない。 例：SGをスタック間参照した際、参照先スタ ックでルール追加すると循環参照エラー。 対策：fromNameやfromArn系メソッドで新 規作成する。 ②スタック間参照削除エラー 参照先スタックで参照を削除すると、参照元スタ ックのデプロイに失敗。 対策： ①cdk deploy -e で参照を切ってデプロイする。 ②参照元でexportvalueを利用 ※SSMパラメータを用いてスタック間参照をなくすことで、両方とも回避可能 [AWS CDK] クロススタック参照で、参照先から参照を削除する場合は 、参照元で exportValue を使おう | DevelopersIO (classmethod.jp) AWS CDKのProps渡しのクロススタック参照で起きる問題 と対処方法 | DevelopersIO (classmethod.jp)
10. 2.Deployment：2.3. リソース作成順序エラー★☆☆ ロググループやログストリーム等、他のリソースの作成に依存するリソースの作成に失敗する ことがある。 ※デプロイ順序次第なので、失敗がランダムになることも。 対策：node.addDependencyメソッドを用いて依存関係を明示する。 AWS CDKでリソース間の依存性をaddDependsOnで明示的に定義する | DevelopersIO (classmethod.jp) CDK Tips: 2種類のaddDependency - maybe daily dev notes (hatenablog.com) Const myLogGroup = new logs.logGroup(省略) Const myAurora = new rds.databaseCluster(省略) myAurora.node.addDependency(myLogGroup)
11. 2.Deployment：2.4. スタックに作成可能なリソース数上限★★☆ ・1スタックに作成可能なリソース上限は500個。 ・サブネットを細かく設定したり、監視を増やしたり、細かくIAM設定すると案外すぐに到達する。 対策：リソース数に余裕を持ったスタック構成を採用。スタック間参照利用しない。 スタック間参照を 回避するため、 できるだけ大きい スタックを作成 リソース数上限に到達 分割が必要に スタック間参照 削除トラブル リソース再作成
12. 3.Difficult to Create：3.1. S3クロスリージョンレプリケーション★★☆ リージョンが違うと別スタックの利用が必須。→スタック間参照の実装＋クラス設計が必要。 S３は様々な箇所で登場するため、横展開も必要。どの方式を採用するかの検討が大変。 おすすめ方式 ・バケット名：Configファイルに格納 ・ＫＭＳキーArn：ＳＳＭパラメータに格納 以下記事に別リージョンのSSMパラメータを読み取るカスタムリソースのコードがある。そのまま利用 できておすすめ。 DKで別のリージョンのリソースを使用する方法 (zenn.dev) スタック間 参照 クロスリー ジョン クラス設計 （横展開） 同名リソース作成によるデプロイエラー 躓きやすいポイントがてんこ盛り
13. 3.Difficult to Create： 3.2. Aurora作成時等に自動作成されるロググループの設定変更★☆☆ Aurora作成時に以下ロググループが自動で作成される。 (※redis等は自分で作ったロググループを明示的に指定できるが、rdsは指定不可。) ・RDSOSメトリクス・Postgreログ →保持期間や暗号化、Firehoseを用いたS3へのエキスポート等、自由に設定不可。 対策：rdsが作成される前に同名のロググループを作成し、先に設定を行う。 同名リソース作成による デプロイエラー リソース作成順序エラー DBの再デプロイに時間がかかる
14. Summary ・スタック間参照で様々なトラブルが発生する。 SSMパラメータを利用し、スタック間参照を避けよう。 ・スタック内のリソース数上限などの制約を事前に把握したうえで、 構造化をうまく活用し、プログラミングのメリットを生かそう。 ・先人の知見を有効活用し、同じトラブルで悩まないようにしよう。 CDK初心者が開発で遭遇したトラブルと解決法 #AWS - Qiita 1.Programming 1.1. クラス構成に関する思想のずれ ★★★ 1.2. 配列利用によるトラブル★☆☆ 1.3. 設定値外だしに関するトラブル★★☆ 1.4. リファクタ時のトラブル★☆☆ 2.Deployment 2.1. 同名リソース作成によるデプロイエラー★★☆ 2.2.スタック間参照トラブル★★★ 2.3.リソース作成順序エラー★☆☆ 2.4.スタックに作成可能なリソース数上限★★☆ 3.Difficult to Create 3.1.S3クロスリージョンレプリケーション★★☆ 3.2.Aurora作成時等に自動作成されるロググループの設定変更★☆☆