Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
”AWS CDKを選定しなかった理由”から見るCDKの現在地
Search
watany
July 06, 2024
Technology
4
2.2k
”AWS CDKを選定しなかった理由”から見るCDKの現在地
AWS CDK Conference Japan 2024でお話しした内容です
https://jawsug-cdk.connpass.com/event/317921/
watany
July 06, 2024
Tweet
Share
More Decks by watany
See All by watany
苦いビールを避ける冴えたやり方
watany
2
150
こんなにあるの? 最近のIPAトレンドを ざっくりまとめてみた
watany
3
600
消費者庁のページから学ぶ アウトプットでの比較で荒れない方法
watany
0
110
Deep Dive into Lambda Response Streaming
watany
1
61
新常識! Javascript×AWS Lambdaがアツい!!
watany
3
380
Adaptor, Helmet, SSG
watany
0
250
異次元のCloudFormation 拡張コマンド~Rain~
watany
0
330
祝10周年! AWS Lambdaのトレンドを 5分で見る
watany
2
230
なぜAWS向けのFrameworkに携わり続けるのか? ~クラウド時代のOSS活動~
watany
3
980
Other Decks in Technology
See All in Technology
Postmanの日本市場におけるDevRel (的) 活動 / Postman's DevRelish activities in Japan
yokawasa
1
120
SREの前に
nwiizo
11
2.6k
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
430
QAEチームが辿った3年 ボクらが改善業務にスクラムを選んだワケ / 20241108_cloudsign_ques23
bengo4com
0
570
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
12k
家具家電付アパートの冷蔵庫をIoT化してみた!
scbc1167
0
140
3次元点群データ「VIRTUAL SHIZUOKA』のオープンデータ化による恩恵と協働の未来/FOSS4G Japan 2024
kazz24s
0
120
プロポーザルのつくり方 〜個人技編〜 / How to come up with proposals
ohbarye
4
300
Engineering at LY Corporation
lycorp_recruit_jp
0
230
透過型SMTPプロキシによる送信メールの可観測性向上: Update Edition / Improved observability of outgoing emails with transparent smtp proxy: Update edition
linyows
2
170
Microsoft Fabric OneLake の実体について
ryomaru0825
0
190
Amazon CloudWatch Network Monitor 導入ガイド_デモ説明付き
yukimmmm
0
150
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Writing Fast Ruby
sferik
627
61k
Building Your Own Lightsaber
phodgson
102
6.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
A Tale of Four Properties
chriscoyier
156
23k
BBQ
matthewcrist
85
9.3k
Designing the Hi-DPI Web
ddemaree
280
34k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Fireside Chat
paigeccino
33
3k
A better future with KSS
kneath
238
17k
Transcript
AWS CDK Conference Japan 2024 ”AWS CDKを選定しなかった理由” から見るCDKの現在地 2024-07-06 #jawsug_cdk
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
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
CDKは今、どのあたりだと思いますか? https://www.gartner.co.jp/ja/promo/hype-cycle-report-list 4
どうしてこの話をするか • CDKの採用事例に納得するも、現場と強いギャップを感じた 経験がある • CDK選定の話が単なるツールの好みや派閥争いとして、議論 が終わることに不満がある ◦ “きのこ vs
たけのこ戦争”として終始させたくない ◦ いろいろな角度からCDKを語りたい 5
Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 6
Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 7
技術選定の前提(こういう仕事でした) メンバ: 業務形態: スコープ: アーキテクチャ: 8
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態: スコープ: アーキテクチャ: 9
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ: アーキテクチャ: 10
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ: アーキテクチャ: • ”私だけがAWS CDKを使える”状態のスタート ◦ ポジティブに捉えると
▪ このままチーム全員がCDK Userに! Happy! ◦ ネガティブに捉えると ▪ チームでキャッチアップできない場合、IaC関連の作業が私一人 へ?私の本来実施する作業はだれが? →リスク要因 11
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ:インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ: 12
前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ:インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ: • アプリケーション(コード~コンテナ)チームとの分断 • リリース後の運用チーム(他社)への引き渡しが決定している
◦ 運用チームは複数システムの運用を集約している。AWSの知見はない ◦ AWS初学者を前提とした運用を期待されている 13
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ:インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ:非公開 ※Core:CloudFront + GPU +
EC2(3rd Party Software) 14
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ:インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ:非公開 ※Core:CloudFront + GPU +
EC2(3rd Party Software) ・必須ソフトウェアがあり、サーバレスアーキテクチャへの変更は厳しい ・AWS上での動作実績はなく、CloudFrontやEC2/VPC、その他マネージドサービスとの相性は 「走りながら確認」する必要があった ・他にも複数の確認項目があり、初期見積もり時点で不確定要素はあった 15
技術選定の前提 メンバ:AWS経験あり、CDK経験なし、IaC経験少し 業務形態:受託業務・リリース日あり スコープ:インフラチームとして AWS環境の要件検討、設計、構築、試験 アーキテクチャ:非公開 ※Core:CloudFront + GPU +
EC2(3rd Party Software) 16
結論 CDKの採用を見送りました 17
結論 • IaCツールはCloudFormation(+Rain, Checkov)を選択 ◦ ツール料金が無料で、サポートも既存のAWSサポート を流用できる ◦ 利用経験者がいる ◦
ツール更新による運用影響が少ない • プロジェクトは完了済。 18
注意点 • 業務形態がSIer/SESだとCDK採用が難しい? ◦ あくまで一事例であり、一般化までは早い ◦ 弊社でもCDKの採用事例はあり • 今回はCDKを「選ばなかったから」成功した? ◦
CDKで失敗しなかった可能性も、もっと成功した可能性もある • この話はベストプラクティスではない ◦ 今日のテーマは「どうして選ばない判断をしたのか」 19
Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 20
おさらい:今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 21
今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 22
CDKの方が書きやすそう A.AWS CDKを使えるメンバが(ほぼ)いない 23
権限も付与しやすいのに A.AWS CDKを使えるメンバが(ほぼ)いない 24
A.AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう? 25
A.AWS CDKを使えるメンバが(ほぼ)いない CDKにかかる採用コストとは何だろう? 私が気になるのは IaCに対する関心ごとの増加 26
With great power comes great responsibility. (大いなる力には、大いなる責任が伴う) 27
CDK採用によって得られる”力”と”責任” 1. Construct ・抽象度が高いConstruct(L2、L3 ) ・低レベルで書き込めるConstruct(L1) 2. プログラミング言語のサポート ・L2、L3 ConstructのプロパティにIDEでの補完が利く
・ex. cdk.RemovalPolicy.DESTROY ・その他、型・配列操作・Classなどのプログラミング言語機能の採用 28
CDK採用によって得られる”力”と”責任” 1. Construct ・抽象度が高いConstruct(L2、L3 ) ・低レベルで書き込めるConstruct(L1) 2. プログラミング言語のサポート ・L2、L3 ConstructのプロパティにIDEでの補完が利く
・ex. cdk.RemovalPolicy.DESTROY ・その他、型・配列操作・Classなどのプログラミング言語機能の採用 • これは全員に必要なのだろうか? • コードを書く人とIaCテンプレートを書く人が同じならば、プログラミング言語が同 じだと嬉しい。 • JSON, YAMLがスコープの人にとっては、扱う言語が増えるだけ? 29
”大いなる力”を使うべきか? • プログラミング言語は強力で、JSON,YAMLに比べて何でもできる ◦ これはDRY? Early Optimization? 30
• 何でもできるから、何でもすることは正しいのだろうか? ◦ プログラミング言語を日常的に扱っていないチームでは、 CDKを持ち込むと関心ごとが増える ◦ それは本質か? 自転車置き場の議論か? ”大いなる力”を使うべきか? 31
今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 32
今回の主な課題 • IaCツールを採用・構築するチームと運用チー ムが異なる • ⇒ つまり「CDKを引き継ぐ」 https://www.irasutoya.com/2016/04/blog-post_19.html 33
CDKを引き継ぐのは難しい? • AWSに詳しくない人へCDKを引き継ぐのは、何故か躊躇われる ◦ CloudFormationは最悪AWS Supportで解決するかも • 難しいと感じるポイント ◦ Construct
◦ コーディング規約 ◦ 運用 34
Constructは難しい 35
Constructは難しい • 例:EKS v1.30 ◦ 2024.04.17 ReleaseのKubernetes v1.30互換 36
Constructは難しい • v1.30はAWS CDK(CFn)として未対応? ◦ 2024.05.23 Release それまでは作成できない 37
Constructは難しい • CDK L2 Constructとして未対応? ◦ 2024.06.08 Release (CDK v2.145.0)
それまでは作成できない 38
Constructは難しい • はたまた、CDKのアップデート漏れ? ◦ CDKのバージョンをv2.145.0に上げるまでは作成できない 39
Constructは難しい • L2,L3 Constructの抽象度は「AWSを知っている人」向けに感じ る ◦ 前提として公式ドキュメントの「AWS API」, 「CDK L1
Construct(CFn)」, 「CDK L2Construct」のライフサイクル、差 分を理解できる人 • 引継ぎ先・新規参画メンバにどのレベルになって欲しいか、言語 化できますか? 40
コーディング規約は難しい 41
コーディング規約は難しい • 言語に依存するFormat/Lintは各言語のものを用いればよい ◦ Prettier & ESLint, Biome, other… •
CDKに対する静的解析は専用のツールを用いればよい ◦ cdk-nag, Snyk, Checkov… • 課題になるのは「CDK固有のスタイルガイド」 42
CDKのためのスタイルガイド 例 • ディレクトリ構成、 • ファイルの分割単位、命名 • App, Stack, Constructの分割単位、命名
• プログラミング固有の機能をどの程度扱うか • 設定ファイルの扱い 43
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
CDKのためのスタイルガイド • これらのスタイルガイドを徹底しなくても、初期メンバなら何とかな る時期はありそう • ただ、メンバ入れ替えや引継ぎを考えると設計意図も言語化した い https://www.irasutoya.com/2019/11/blog-post_547.html 45
CDKの運用は難しい 46
CDKの運用は難しい • ツールのアップデート問題 ◦ CDKのMinor Versionは毎週更新される • 更新スタンスの例。引継ぎ先にはどうしてもらう? ◦ 定期的に追従する
◦ リリースのタイミングで可能な限り追従する ◦ リリース頻度が低くてもツールは頑張って更新 ◦ 影響あるまでバージョンロック 47
CDKの運用は難しい • 具体的なCDKのアップデート方式 ◦ Snapshotを更新し、差分をケアする ▪ cdk synthで出力されるテンプレート差分の確認 • 以下の方針はどうする?引継ぎ先ではどれが好ましい?
◦ Upstream対応後のEscape Hatchの書き換え ◦ 確認時の試験内容・試験方式 48
”難しい”のまとめ • 挙げた中にはCDK固有ではなくIaC一般の話題、他のツールと 共通する話題もある ◦ CDKの特徴=宣言型+プログラミング+リソース抽象化 • ”チームの中でどうするか?”と”引継ぎ先を意識する場合”で検討 の難易度が異なる ◦
みなさんどうしてますか 49
今回の主な課題 A. AWS CDKを使えるメンバがほぼいない B. IaCツールを採用・構築するチームと運用チー ムが異なる C. その他のリスクファクター 50
C.その他のリスクファクター • リスクがあるから採用しない? ◦ ”リスクのない選択”は存在しない ◦ ”すべてを枯れた技術で作る”でも、時代に置き去りにされ るリスクが残る • 何かの採用を躊躇うのは、許容できるリスクが閾値を超えそう
だから 51
C.その他のリスクファクター 閾値≒リスク許容度への考え方の例 https://x.com/dkfj/status/1799994345514508616 52
C.その他のリスクファクター • 「今回は」CDK採用のリスクは取れないと判断した • 判断が正解だと信じたい気持ちもあるし、後悔もある ◦ 後悔があるのは十分に悩み切れなかったから 53
Contents 1. CDKを採用しなかった理由 2. 考察 3. CDKの現在地 54
3.CDKの現在地 • 私にとってCDKとは”AWSに集中するためのフレームワー ク” ◦ AWSのマイクロサービス固有の”過度な散らばり”を吸収 してHuman Readableに扱える ◦ L2
Constructの力と、付随する力の扱い 55
3.CDKの現在地 • CDKを採用しやすいチーム ◦ アプリケーションエンジニア、類するメンバ ◦ AWS支持者・有識者 ◦ コードを継続的メンテナンスできる体制・チーム •
上記に合わない場合…? ◦ モチベーションや学習で出来る点はあると思う ◦ 学習・運用コストは低くないので、チームでの他の課題も 含めて採用を検討 56
3.CDKの現在地 合わない場合にチームの形を変えるか、ツールを変 えるか https://www.irasutoya.com/2018/05/blog-post_109.html 57
3.CDKの現在地 チームを変えられない時、ど うすればCDKを選べるのだろ うか? 58
いつかCDKを選ぶために(案) 1.「書かない人のため」のCDK記述ガイドライン ◦ プログラミング言語を書く人へのナレッジはJAWS-UG CDK 支部で出ている ◦ 書かない人のためのナレッジは出てこない ▪ 例えば、今回の私のような例は能力の欠如を晒すようで
恥ずかしい 59
いつかCDKを選ぶために(案) • インフラ畑の人がプログラミングに寄せずに書くことを、恥ずかしが らずに話せると一段階進むかもしれない ◦ あるいは、DAMPの方向性で ◦ DAMP=Descriptive And Meaningful
Phrases ▪ 「記述的かつ意味のあるフレーズ」 60
いつかCDKを選ぶために(案) 2.ベストプラクティスの整理、簡略化 • 例えば命名・スタック分割・リソース参照などは本当にワークアラウンド を暗記しないと駄目か? ◦ Upstreamへのフィードバック ◦ Tool化、OSS化 61
まとめ • CDKが今後も広く普及するには ◦ 現在はチームの形によってフィットする/しない部分があっ て、CFnの完全上位互換と言いづらい ▪ 今回のように選ばない理由は残っている • 選定理由が”流行ってるから”、”新しいから”は止めたい
◦ CDKを”愛情”だけでなく”納得”で選定できるように 62
See you again 👋 63