AWS CDKは銀の弾丸ではない
投稿日 August 12, 2023 • 1分で読めます • 73文字 • 言語を選択: Korean、English
Table of contents
TL;DR（Notion AIが書いてくれた文章）
AWS CDK（クラウド開発キット）はコード型インフラ（IaC）開発に広く使用されていますが、すべてのユースケースに適したソリューションではないことに注意が必要です。
まず、多くのカスタマイズを必要としない小規模プロジェクトや簡単なインフラ設定には、AWS CDKが最善の選択ではないかもしれません。このような場合には、より簡単なIaCツールを使用するか、AWSコンソールで直接コードを書く方が効率的かもしれません。
次に、AWS CDKはインフラ定義のための高レベルのオブジェクト指向抽象化を提供しますが、特定の状況では複雑さを増加させる可能性もあります。開発者はAWS CDKが提供する柔軟性と、それによって発生しうる追加の複雑さの間のトレードオフを慎重に考慮する必要があります。
最後に、AWS CDKはまだ比較的新しいツールであり、急速に発展しています。大きく活発なコミュニティがありますが、まだ一部の特定のユースケースに必要なすべての機能やサポートが提供されていない可能性があります。
全体的に、AWS CDKはインフラ開発のための強力なツールですが、すべてを満たすソリューションではありません。開発者は特定のユースケースとプロジェクト要件を慎重に考慮した後、AWS CDKまたは他のIaCツールを使用するかどうか決定する必要があります。
なぜ無関係なCDKに嫌気がさしたのか？
私は最近Go言語でCLIクローラーアプリケーションを作っている。 最初は軽い気持ちで、No Server & No DB環境のアプリケーションを作ろうとした。 しかしchromedriverを私のCLIアプリケーション内で動作させるにはいくつかの難点があった。 （ここ に少し整理しておいたが、CLIが完成したらその時また詳しく投稿するつもりだ）
ユーザーのローカルPCでchromedriverを実行する代わりに、AWS Lambdaでchromedriverを実行する方法を探すことにした。 そうしているうちにdocker-selenium-lambda で私が望むようにLambdaでchromedriverを実行できるように実装されていることを知った。 しかし私は本当になぜか、Serverlessベースのこのリポジトリを参照してCDKベースのコードを書こうとした。 各ツールの長所と短所は考慮もしなかった。 ただ私が実際に会社でCDKを多く使っており、IaCを書くならCDKが常に正解だというありえない考えが根底にあったのだ。
3日間、私のプロジェクトにCDKを適用しようとした時に直面した最大の問題はECRに関連するものだった。 CDKではECRリポジトリを作成できない。 - 関連リンク そして思いもよらなかったServerlessがこの機能をうまくサポートしていたのだ。 私はここでCDKがすべてを解決してくれる万能ツールではないことに気づいた。 そして私がいかに無思考で馴染みのあるツールを使おうとしていたかに気づいた。
Serverless vs SAM vs CDK
Serverless
- 長い間使用されてきたのでコミュニティが大きい
- CloudFormationの複雑な部分を抽象化
- 簡単にアプリをテストしてデプロイできるシンプルさ
- 様々なプラグイン
- Serverless設定ファイルとCloudFormation設定ファイルの違いを区別するのが難しい場合がある
SAM
- Serverlessと同様にCloudFormationの複雑な層を簡素化
- ローカルテスト機能
- AWS build pipelineとの統合
- CDKとの組み合わせが可能
- 複雑なインフラ構成をするには難しい場合がある
CDK
- コンポーネントを構成して再利用するのに容易
- 馴染みのあるプログラミング言語でインフラを定義
- 複雑なインフラ構成をするのに容易
- サーバーレスに限らずAWSのすべてのサービスをサポート
- ローカルテストなど一部の詳細機能は他のサービスとの統合が必要
まとめ
重要な違いといえば、ServerlessとSAMは文字通りServerlessのためのツールであり、CDKはAWSのすべてのサービスをサポートするIaCツールだという点だ。 したがって私が作ろうとしているアプリケーションが複雑になればなるほど、CDKを使う方が有利だ。 一方、私のアプリケーションの構造が複雑でない時はServerlessとSAMのどちらのツールを使うか悩むことになるが、実際私はこのような選択の分岐に立たされたらServerless側の軽くてシンプルな構造を多く使うことになりそうだ。
また、フロントエンド中心のアプリケーションを作ろうとするならAmplifyを学んでみるのもいいだろう。
結論
今回の機会に私がいかに考えなしに開発ツールを選択して使ってきたかに気づいた。 ただ私が多く使ってきて馴染みのあるもの、そしてほぼ正解と見なされるソリューションを採用していたのだ。 より良い開発者になるためには、プロジェクトにどのツールが適しており、これらをどう組み合わせたら良いシナジーを出せるか考えてみるべきだ。 今後はサイドプロジェクトを作る時にも、私が実装しようとしているロジックにより適した方法を探して活用する習慣をつけなければならない。