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

AWS CDK Conference Japan 2024でお話しした内容です
https://jawsug-cdk.connpass.com/event/317921/

Transcript

1. AWS CDK Conference Japan 2024 ”AWS CDKを選定しなかった理由” から見るCDKの現在地 2024-07-06 #jawsug_cdk
2. 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
3. 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
4. CDKは今、どのあたりだと思いますか？ https://www.gartner.co.jp/ja/promo/hype-cycle-report-list 4
5. どうしてこの話をするか • CDKの採用事例に納得するも、現場と強いギャップを感じた 経験がある • CDK選定の話が単なるツールの好みや派閥争いとして、議論 が終わることに不満がある ◦ “きのこ vs たけのこ戦争”として終始させたくない ◦ いろいろな角度からCDKを語りたい 5
6. Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 6
7. Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 7
8. 技術選定の前提(こういう仕事でした) メンバ： 業務形態： スコープ： アーキテクチャ： 8
9. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態： スコープ： アーキテクチャ： 9
10. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ： アーキテクチャ： 10
11. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ： アーキテクチャ： • ”私だけがAWS CDKを使える”状態のスタート ◦ ポジティブに捉えると ▪ このままチーム全員がCDK Userに！ Happy！ ◦ ネガティブに捉えると ▪ チームでキャッチアップできない場合、IaC関連の作業が私一人 へ？私の本来実施する作業はだれが？ →リスク要因 11
12. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ： 12
13. 前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ： • アプリケーション(コード～コンテナ)チームとの分断 • リリース後の運用チーム(他社)への引き渡しが決定している ◦ 運用チームは複数システムの運用を集約している。AWSの知見はない ◦ AWS初学者を前提とした運用を期待されている 13
14. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) 14
15. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) ・必須ソフトウェアがあり、サーバレスアーキテクチャへの変更は厳しい ・ＡＷＳ上での動作実績はなく、CloudFrontやEC2/VPC、その他マネージドサービスとの相性は 「走りながら確認」する必要があった ・他にも複数の確認項目があり、初期見積もり時点で不確定要素はあった 15
16. 技術選定の前提 メンバ：AWS経験あり、CDK経験なし、IaC経験少し 業務形態：受託業務・リリース日あり スコープ：インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ：非公開 ※Core：CloudFront + GPU + EC2(3rd Party Software) 16
17. 結論 CDKの採用を見送りました 17
18. 結論 • IaCツールはCloudFormation(＋Rain, Checkov)を選択 ◦ ツール料金が無料で、サポートも既存のAWSサポート を流用できる ◦ 利用経験者がいる ◦ ツール更新による運用影響が少ない • プロジェクトは完了済。 18
19. 注意点 • 業務形態がSIer/SESだとCDK採用が難しい？ ◦ あくまで一事例であり、一般化までは早い ◦ 弊社でもCDKの採用事例はあり • 今回はCDKを「選ばなかったから」成功した？ ◦ CDKで失敗しなかった可能性も、もっと成功した可能性もある • この話はベストプラクティスではない ◦ 今日のテーマは「どうして選ばない判断をしたのか」 19
20. Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 20
21. おさらい：今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 21
22. 今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 22
23. CDKの方が書きやすそう A．AWS CDKを使えるメンバが(ほぼ)いない 23
24. 権限も付与しやすいのに A．AWS CDKを使えるメンバが(ほぼ)いない 24
25. A．AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう？ 25
26. A．AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう？ 私が気になるのは IaCに対する関心ごとの増加 26
27. With great power comes great responsibility. (大いなる力には、大いなる責任が伴う) 27
28. CDK採用によって得られる”力”と”責任” 1. Construct ・抽象度が高いConstruct(L2、L3 ) ・低レベルで書き込めるConstruct(L1) 2. プログラミング言語のサポート ・L2、L3 ConstructのプロパティにIDEでの補完が利く ・ex. cdk.RemovalPolicy.DESTROY ・その他、型・配列操作・Classなどのプログラミング言語機能の採用 28
29. CDK採用によって得られる”力”と”責任” 1. Construct ・抽象度が高いConstruct(L2、L3 ) ・低レベルで書き込めるConstruct(L1) 2. プログラミング言語のサポート ・L2、L3 ConstructのプロパティにIDEでの補完が利く ・ex. cdk.RemovalPolicy.DESTROY ・その他、型・配列操作・Classなどのプログラミング言語機能の採用 • これは全員に必要なのだろうか？ • コードを書く人とIaCテンプレートを書く人が同じならば、プログラミング言語が同 じだと嬉しい。 • JSON, YAMLがスコープの人にとっては、扱う言語が増えるだけ？ 29
30. ”大いなる力”を使うべきか？ • プログラミング言語は強力で、JSON,YAMLに比べて何でもできる ◦ これはDRY？ Early Optimization？ 30
31. • 何でもできるから、何でもすることは正しいのだろうか？ ◦ プログラミング言語を日常的に扱っていないチームでは、 CDKを持ち込むと関心ごとが増える ◦ それは本質か？ 自転車置き場の議論か？ ”大いなる力”を使うべきか？ 31
32. 今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 32
33. 今回の主な課題 • IaCツールを採用・構築するチームと運用チー ムが異なる • ⇒ つまり「CDKを引き継ぐ」 https://www.irasutoya.com/2016/04/blog-post_19.html 33
34. CDKを引き継ぐのは難しい？ • AWSに詳しくない人へCDKを引き継ぐのは、何故か躊躇われる ◦ CloudFormationは最悪AWS Supportで解決するかも • 難しいと感じるポイント ◦ Construct ◦ コーディング規約 ◦ 運用 34
35. Constructは難しい 35
36. Constructは難しい • 例：EKS v1.30 ◦ 2024.04.17 ReleaseのKubernetes v1.30互換 36
37. Constructは難しい • v1.30はAWS CDK(CFn)として未対応？ ◦ 2024.05.23 Release それまでは作成できない 37
38. Constructは難しい • CDK L2 Constructとして未対応？ ◦ 2024.06.08 Release (CDK v2.145.0) それまでは作成できない 38
39. Constructは難しい • はたまた、CDKのアップデート漏れ？ ◦ CDKのバージョンをv2.145.0に上げるまでは作成できない 39
40. Constructは難しい • L2，L3 Constructの抽象度は「AWSを知っている人」向けに感じ る ◦ 前提として公式ドキュメントの「AWS API」, 「CDK L1 Construct(CFn)」, 「CDK L2Construct」のライフサイクル、差 分を理解できる人 • 引継ぎ先・新規参画メンバにどのレベルになって欲しいか、言語 化できますか？ 40
41. コーディング規約は難しい 41
42. コーディング規約は難しい • 言語に依存するFormat/Lintは各言語のものを用いればよい ◦ Prettier & ESLint, Biome, other… • CDKに対する静的解析は専用のツールを用いればよい ◦ cdk-nag, Snyk, Checkov… • 課題になるのは「CDK固有のスタイルガイド」 42
43. CDKのためのスタイルガイド 例 • ディレクトリ構成、 • ファイルの分割単位、命名 • App, Stack, Constructの分割単位、命名 • プログラミング固有の機能をどの程度扱うか • 設定ファイルの扱い 43
44. 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
45. CDKのためのスタイルガイド • これらのスタイルガイドを徹底しなくても、初期メンバなら何とかな る時期はありそう • ただ、メンバ入れ替えや引継ぎを考えると設計意図も言語化した い https://www.irasutoya.com/2019/11/blog-post_547.html 45
46. CDKの運用は難しい 46
47. CDKの運用は難しい • ツールのアップデート問題 ◦ CDKのMinor Versionは毎週更新される • 更新スタンスの例。引継ぎ先にはどうしてもらう？ ◦ 定期的に追従する ◦ リリースのタイミングで可能な限り追従する ◦ リリース頻度が低くてもツールは頑張って更新 ◦ 影響あるまでバージョンロック 47
48. CDKの運用は難しい • 具体的なCDKのアップデート方式 ◦ Snapshotを更新し、差分をケアする ▪ cdk synthで出力されるテンプレート差分の確認 • 以下の方針はどうする？引継ぎ先ではどれが好ましい？ ◦ Upstream対応後のEscape Hatchの書き換え ◦ 確認時の試験内容・試験方式 48
49. ”難しい”のまとめ • 挙げた中にはCDK固有ではなくIaC一般の話題、他のツールと 共通する話題もある ◦ CDKの特徴＝宣言型＋プログラミング＋リソース抽象化 • ”チームの中でどうするか？”と”引継ぎ先を意識する場合”で検討 の難易度が異なる ◦ みなさんどうしてますか 49
50. 今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 50
51. C．その他のリスクファクター • リスクがあるから採用しない？ ◦ ”リスクのない選択”は存在しない ◦ ”すべてを枯れた技術で作る”でも、時代に置き去りにされ るリスクが残る • 何かの採用を躊躇うのは、許容できるリスクが閾値を超えそう だから 51
52. C．その他のリスクファクター 閾値≒リスク許容度への考え方の例 https://x.com/dkfj/status/1799994345514508616 52
53. C．その他のリスクファクター • 「今回は」CDK採用のリスクは取れないと判断した • 判断が正解だと信じたい気持ちもあるし、後悔もある ◦ 後悔があるのは十分に悩み切れなかったから 53
54. Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 54
55. ３．CDKの現在地 • 私にとってCDKとは”AWSに集中するためのフレームワー ク” ◦ AWSのマイクロサービス固有の”過度な散らばり”を吸収 してHuman Readableに扱える ◦ L2 Constructの力と、付随する力の扱い 55
56. ３．CDKの現在地 • CDKを採用しやすいチーム ◦ アプリケーションエンジニア、類するメンバ ◦ AWS支持者・有識者 ◦ コードを継続的メンテナンスできる体制・チーム • 上記に合わない場合…？ ◦ モチベーションや学習で出来る点はあると思う ◦ 学習・運用コストは低くないので、チームでの他の課題も 含めて採用を検討 56
57. ３．CDKの現在地 合わない場合にチームの形を変えるか、ツールを変 えるか https://www.irasutoya.com/2018/05/blog-post_109.html 57
58. ３．CDKの現在地 チームを変えられない時、ど うすればCDKを選べるのだろ うか？ 58
59. いつかCDKを選ぶために(案) １．「書かない人のため」のCDK記述ガイドライン ◦ プログラミング言語を書く人へのナレッジはJAWS-UG CDK 支部で出ている ◦ 書かない人のためのナレッジは出てこない ▪ 例えば、今回の私のような例は能力の欠如を晒すようで 恥ずかしい 59
60. いつかCDKを選ぶために(案) • インフラ畑の人がプログラミングに寄せずに書くことを、恥ずかしが らずに話せると一段階進むかもしれない ◦ あるいは、DAMPの方向性で ◦ DAMP＝Descriptive And Meaningful Phrases ▪ 「記述的かつ意味のあるフレーズ」 60
61. いつかCDKを選ぶために(案) ２．ベストプラクティスの整理、簡略化 • 例えば命名・スタック分割・リソース参照などは本当にワークアラウンド を暗記しないと駄目か？ ◦ Upstreamへのフィードバック ◦ Tool化、OSS化 61
62. まとめ • CDKが今後も広く普及するには ◦ 現在はチームの形によってフィットする/しない部分があっ て、CFnの完全上位互換と言いづらい ▪ 今回のように選ばない理由は残っている • 選定理由が”流行ってるから”、”新しいから”は止めたい ◦ CDKを”愛情”だけでなく”納得”で選定できるように 62
63. See you again 👋 63