”AWS CDKを選定しなかった理由”から見るCDKの現在地

by watany

Slide 1

Slide 1 text

AWS CDK Conference Japan 2024 ”AWS CDKを選定しなかった理由” から見るCDKの現在地 2024-07-06 #jawsug_cdk

Slide 2

Slide 2 text

Me Watanabe Yohei(watany) ● NTT TechnoCross Corporation ● AWS ○ AWS Assosiate Ambassador 2024 ○ Japan AWS Top Engineer 2023 ○ JAWS-UG Tokyo https://jawsug.connpass.com/event/316451/ 2

Slide 3

Slide 3 text

AWS CDK Conference 3周年おめでとう！ https://jawsug-cdk.connpass.com/event/317921/ https://jawsug.connpass.com/event/240422/ https://jawsug-cdk.connpass.com/event/278205/ 3

Slide 4

Slide 4 text

CDKは今、どのあたりだと思いますか？ https://www.gartner.co.jp/ja/promo/hype-cycle-report-list 4

Slide 5

Slide 5 text

どうしてこの話をするか ● CDKの採用事例に納得するも、現場と強いギャップを感じた経験がある ● CDK選定の話が単なるツールの好みや派閥争いとして、議論が終わることに不満がある ○ “きのこ vs たけのこ戦争”として終始させたくない ○ いろいろな角度からCDKを語りたい 5

Slide 6

Slide 6 text

Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 6

Slide 7

Slide 7 text

Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 7

Slide 8

Slide 8 text

技術選定の前提(こういう仕事でした) メンバ：業務形態：スコープ：アーキテクチャ： 8

Slide 9

Slide 9 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：スコープ：アーキテクチャ： 9

Slide 10

Slide 10 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：アーキテクチャ： 10

Slide 11

Slide 11 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：アーキテクチャ： ● ”私だけがAWS CDKを使える”状態のスタート ○ ポジティブに捉えると ■ このままチーム全員がCDK Userに！ Happy！ ○ ネガティブに捉えると ■ チームでキャッチアップできない場合、IaC関連の作業が私一人へ？私の本来実施する作業はだれが？ →リスク要因 11

Slide 12

Slide 12 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験アーキテクチャ： 12

Slide 13

Slide 13 text

前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験アーキテクチャ： ● アプリケーション(コード～コンテナ)チームとの分断 ● リリース後の運用チーム(他社)への引き渡しが決定している ○ 運用チームは複数システムの運用を集約している。AWSの知見はない ○ AWS初学者を前提とした運用を期待されている 13

Slide 14

Slide 14 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) 14

Slide 15

Slide 15 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) ・必須ソフトウェアがあり、サーバレスアーキテクチャへの変更は厳しい・ＡＷＳ上での動作実績はなく、CloudFrontやEC2/VPC、その他マネージドサービスとの相性は「走りながら確認」する必要があった・他にも複数の確認項目があり、初期見積もり時点で不確定要素はあった 15

Slide 16

Slide 16 text

技術選定の前提メンバ：AWS経験あり、CDK経験なし、IaC経験少し業務形態：受託業務・リリース日ありスコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) 16

Slide 17

Slide 17 text

結論 CDKの採用を見送りました 17

Slide 18

Slide 18 text

結論 ● IaCツールはCloudFormation(＋Rain, Checkov)を選択 ○ ツール料金が無料で、サポートも既存のAWSサポートを流用できる ○ 利用経験者がいる ○ ツール更新による運用影響が少ない ● プロジェクトは完了済。 18

Slide 19

Slide 19 text

注意点 ● 業務形態がSIer/SESだとCDK採用が難しい？ ○ あくまで一事例であり、一般化までは早い ○ 弊社でもCDKの採用事例はあり ● 今回はCDKを「選ばなかったから」成功した？ ○ CDKで失敗しなかった可能性も、もっと成功した可能性もある ● この話はベストプラクティスではない ○ 今日のテーマは「どうして選ばない判断をしたのか」 19

Slide 20

Slide 20 text

Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 20

Slide 21

Slide 21 text

おさらい：今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チームが異なる C. その他のリスクファクター 21

Slide 22

Slide 22 text

今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チームが異なる C. その他のリスクファクター 22

Slide 23

Slide 23 text

CDKの方が書きやすそう A．AWS CDKを使えるメンバが(ほぼ)いない 23

Slide 24

Slide 24 text

権限も付与しやすいのに A．AWS CDKを使えるメンバが(ほぼ)いない 24

Slide 25

Slide 25 text

A．AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう？ 25

Slide 26

Slide 26 text

A．AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう？私が気になるのは IaCに対する関心ごとの増加 26

Slide 27

Slide 27 text

With great power comes great responsibility. (大いなる力には、大いなる責任が伴う) 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

CDK採用によって得られる”力”と”責任” 1. Construct ・抽象度が高いConstruct(L2、L3 ) ・低レベルで書き込めるConstruct(L1) 2. プログラミング言語のサポート・L2、L3 ConstructのプロパティにIDEでの補完が利く・ex. cdk.RemovalPolicy.DESTROY ・その他、型・配列操作・Classなどのプログラミング言語機能の採用 ● これは全員に必要なのだろうか？ ● コードを書く人とIaCテンプレートを書く人が同じならば、プログラミング言語が同じだと嬉しい。 ● JSON, YAMLがスコープの人にとっては、扱う言語が増えるだけ？ 29

Slide 30

Slide 30 text

”大いなる力”を使うべきか？ ● プログラミング言語は強力で、JSON,YAMLに比べて何でもできる ○ これはDRY？ Early Optimization？ 30

Slide 31

Slide 31 text

● 何でもできるから、何でもすることは正しいのだろうか？ ○ プログラミング言語を日常的に扱っていないチームでは、 CDKを持ち込むと関心ごとが増える ○ それは本質か？自転車置き場の議論か？ ”大いなる力”を使うべきか？ 31

Slide 32

Slide 32 text

今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チームが異なる C. その他のリスクファクター 32

Slide 33

Slide 33 text

今回の主な課題 ● IaCツールを採用・構築するチームと運用チームが異なる ● ⇒ つまり「CDKを引き継ぐ」 https://www.irasutoya.com/2016/04/blog-post_19.html 33

Slide 34

Slide 34 text

CDKを引き継ぐのは難しい？ ● AWSに詳しくない人へCDKを引き継ぐのは、何故か躊躇われる ○ CloudFormationは最悪AWS Supportで解決するかも ● 難しいと感じるポイント ○ Construct ○ コーディング規約 ○ 運用 34

Slide 35

Slide 35 text

Constructは難しい 35

Slide 36

Slide 36 text

Constructは難しい ● 例：EKS v1.30 ○ 2024.04.17 ReleaseのKubernetes v1.30互換 36

Slide 37

Slide 37 text

Constructは難しい ● v1.30はAWS CDK(CFn)として未対応？ ○ 2024.05.23 Release それまでは作成できない 37

Slide 38

Slide 38 text

Constructは難しい ● CDK L2 Constructとして未対応？ ○ 2024.06.08 Release (CDK v2.145.0) それまでは作成できない 38

Slide 39

Slide 39 text

Constructは難しい ● はたまた、CDKのアップデート漏れ？ ○ CDKのバージョンをv2.145.0に上げるまでは作成できない 39

Slide 40

Slide 40 text

Constructは難しい ● L2，L3 Constructの抽象度は「AWSを知っている人」向けに感じる ○ 前提として公式ドキュメントの「AWS API」, 「CDK L1 Construct(CFn)」, 「CDK L2Construct」のライフサイクル、差分を理解できる人 ● 引継ぎ先・新規参画メンバにどのレベルになって欲しいか、言語化できますか？ 40

Slide 41

Slide 41 text

コーディング規約は難しい 41

Slide 42

Slide 42 text

コーディング規約は難しい ● 言語に依存するFormat/Lintは各言語のものを用いればよい ○ Prettier & ESLint, Biome, other… ● CDKに対する静的解析は専用のツールを用いればよい ○ cdk-nag, Snyk, Checkov… ● 課題になるのは「CDK固有のスタイルガイド」 42

Slide 43

Slide 43 text

CDKのためのスタイルガイド例 ● ディレクトリ構成、 ● ファイルの分割単位、命名 ● App, Stack, Constructの分割単位、命名 ● プログラミング固有の機能をどの程度扱うか ● 設定ファイルの扱い 43

Slide 44

Slide 44 text

CDKのためのスタイルガイド参考になるもの ● 公式のベストプラクティス ○ https://docs.aws.amazon.com/cdk/v2/guide/best-practices.html ● サンプル実装 ○ Baseline Environment on AWS(BLEA) ○ Generative AI Use Cases JP (GenU) ● コンプライアンス・ガバナンス ○ CDK Aspect ○ CloudFormation Guard 44

Slide 45

Slide 45 text

CDKのためのスタイルガイド ● これらのスタイルガイドを徹底しなくても、初期メンバなら何とかなる時期はありそう ● ただ、メンバ入れ替えや引継ぎを考えると設計意図も言語化したい https://www.irasutoya.com/2019/11/blog-post_547.html 45

Slide 46

Slide 46 text

CDKの運用は難しい 46

Slide 47

Slide 47 text

CDKの運用は難しい ● ツールのアップデート問題 ○ CDKのMinor Versionは毎週更新される ● 更新スタンスの例。引継ぎ先にはどうしてもらう？ ○ 定期的に追従する ○ リリースのタイミングで可能な限り追従する ○ リリース頻度が低くてもツールは頑張って更新 ○ 影響あるまでバージョンロック 47

Slide 48

Slide 48 text

CDKの運用は難しい ● 具体的なCDKのアップデート方式 ○ Snapshotを更新し、差分をケアする ■ cdk synthで出力されるテンプレート差分の確認 ● 以下の方針はどうする？引継ぎ先ではどれが好ましい？ ○ Upstream対応後のEscape Hatchの書き換え ○ 確認時の試験内容・試験方式 48

Slide 49

Slide 49 text

”難しい”のまとめ ● 挙げた中にはCDK固有ではなくIaC一般の話題、他のツールと共通する話題もある ○ CDKの特徴＝宣言型＋プログラミング＋リソース抽象化 ● ”チームの中でどうするか？”と”引継ぎ先を意識する場合”で検討の難易度が異なる ○ みなさんどうしてますか 49

Slide 50

Slide 50 text

今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チームが異なる C. その他のリスクファクター 50

Slide 51

Slide 51 text

C．その他のリスクファクター ● リスクがあるから採用しない？ ○ ”リスクのない選択”は存在しない ○ ”すべてを枯れた技術で作る”でも、時代に置き去りにされるリスクが残る ● 何かの採用を躊躇うのは、許容できるリスクが閾値を超えそうだから 51

Slide 52

Slide 52 text

C．その他のリスクファクター閾値≒リスク許容度への考え方の例 https://x.com/dkfj/status/1799994345514508616 52

Slide 53

Slide 53 text

C．その他のリスクファクター ● 「今回は」CDK採用のリスクは取れないと判断した ● 判断が正解だと信じたい気持ちもあるし、後悔もある ○ 後悔があるのは十分に悩み切れなかったから 53

Slide 54

Slide 54 text

Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 54

Slide 55

Slide 55 text

３．CDKの現在地 ● 私にとってCDKとは”AWSに集中するためのフレームワーク” ○ AWSのマイクロサービス固有の”過度な散らばり”を吸収してHuman Readableに扱える ○ L2 Constructの力と、付随する力の扱い 55

Slide 56

Slide 56 text

３．CDKの現在地 ● CDKを採用しやすいチーム ○ アプリケーションエンジニア、類するメンバ ○ AWS支持者・有識者 ○ コードを継続的メンテナンスできる体制・チーム ● 上記に合わない場合…？ ○ モチベーションや学習で出来る点はあると思う ○ 学習・運用コストは低くないので、チームでの他の課題も含めて採用を検討 56

Slide 57

Slide 57 text

３．CDKの現在地合わない場合にチームの形を変えるか、ツールを変えるか https://www.irasutoya.com/2018/05/blog-post_109.html 57

Slide 58

Slide 58 text

３．CDKの現在地チームを変えられない時、どうすればCDKを選べるのだろうか？ 58

Slide 59

Slide 59 text

いつかCDKを選ぶために(案) １．「書かない人のため」のCDK記述ガイドライン ○ プログラミング言語を書く人へのナレッジはJAWS-UG CDK 支部で出ている ○ 書かない人のためのナレッジは出てこない ■ 例えば、今回の私のような例は能力の欠如を晒すようで恥ずかしい 59

Slide 60

Slide 60 text

いつかCDKを選ぶために(案) ● インフラ畑の人がプログラミングに寄せずに書くことを、恥ずかしがらずに話せると一段階進むかもしれない ○ あるいは、DAMPの方向性で ○ DAMP＝Descriptive And Meaningful Phrases ■ 「記述的かつ意味のあるフレーズ」 60

Slide 61

Slide 61 text

いつかCDKを選ぶために(案) ２．ベストプラクティスの整理、簡略化 ● 例えば命名・スタック分割・リソース参照などは本当にワークアラウンドを暗記しないと駄目か？ ○ Upstreamへのフィードバック ○ Tool化、OSS化 61

Slide 62

Slide 62 text

まとめ ● CDKが今後も広く普及するには ○ 現在はチームの形によってフィットする/しない部分があって、CFnの完全上位互換と言いづらい ■ 今回のように選ばない理由は残っている ● 選定理由が”流行ってるから”、”新しいから”は止めたい ○ CDKを”愛情”だけでなく”納得”で選定できるように 62

Slide 63

Slide 63 text

See you again 👋 63