見出し画像

AWS CDK Conference 2024 初心者がおさえておきたいAWS CDKのベストプラクティス 2024年版 を聞いた

amixedcolor

AWS CDK Conference 2024に参加しています！

「初心者がおさえておきたいAWS CDKのベストプラクティス 2024年版」を聞いて、たくさんインプットしたので休憩時間を利用して整理しながらアウトプットしようと思います

追記：発表者の方がスライドを公開されてました！

はじめに

今回のセッションでは、20のベストプラクティスについて言及がありました。とても密度の高い内容でしたが、自分にインプットできた範囲で書いていこうと思います！

ベストプラクティス 1~10

CDKにも当てはまりますが、全般的なプラクティスの発表でした

1. ドキュメントを読む

下記3つのCDKに関するドキュメントを読んで情報収集ができます

実践的な内容もあるとのことで、まずはここを読みにいくと良さそうです

2. しくみを理解する

CDK自体がどういった仕組みで動いているのかを理解することで、デバッグが容易になる話がありました

自分は現時点で下記の理解です

  1. ユーザーがdeployをする

  2. AWS CDK Toolkitがテンプレートにしたりする

  3. CloudFormation テンプレートがデプロイされる

  4. AWSリソースが作成される

3. Tenetsに共感する

意思決定のための組織や製品の信条で、何に価値を置くかを明らかにするものだそうです。フレームワークの選定や、上手に使い続けるのに役立つとのことでした。

初めて聞いたので調べてみたところ、AWSとして下記のようなものをもっているようでした

4. 困った時の相談先を知る

下記の3つが紹介されました

発表時のXでは、Supportに聞けたのかという投稿を目にしましたが、オープンソースでもAWSオフィシャルだからかな？と思いました

5. Gitでバージョン管理をする

単にバージョン管理ツールという話ではなく、 Gitで という話でした。自分はGitHubかGitLabしか使ったことがなかったので他のバージョン管理ツールがそもそも具体的にイメージできないですが、コミュニケーションツールやCI/CDの観点からもGitが良いようです。

6. Gitリポジトリに全てを保存する

プライベートなGitリポジトリに全てを保存することが話されました。AWSアカウントIDやリージョンなども含め全てをコードとしてコミットして実行時のパラメータや環境への依存を排除できるそうです。

一聞した時に少し驚きましたが、考えてみると確かに、自分が開発しているCDKもそういった情報をコード内に保持していました。手動にさせないことのメリットを感じます。

7. Gitリポジトリとチームの境界を合わせる

1Gitリポジトリ = 1CDK Appを原則にするという話がありました。自分が開発しているCDKは1つのAppで、社内で他のCDKを開発している話はきいたことがなかったこともあり、1つのリポジトリでした。

チームの境界を合わせると、コンウェイの法則に基づいて分断を生む可能性もあるので、慎重な意思決定が必要だという話もありました。

8. IDEの機能を活用する

コード補完 / Linter / Formatterを活用することで、CDKの恩恵をより受けられる話でした。自分が書いている時はTSで書いていますが、静的解析が非常に便利に書きやすいなと、自然に感じて使っていました。

9. 生成AIを活用する

コードを提案してくれるのが単に便利なだけでなく、 Amazon Q DeveloperはIaCコードのセキュリティスキャンもしてくれるとのことでした。

セキュリティスキャンの機能があることは初耳でした。

10. 初めから標準化しない

変更容易性を担保して、プラットフォームエンジニアリングとして最小限にするといった話でした。
まさに弊社内で取り組んでいることで、ベストプラクティスに沿えていると思いました。

ベストプラクティス 11~20

よりCDKに焦点を当てたベストプラクティスの話でした。

11. リソースの置き換えに注意する

cdk diffを使うことや、論理IDの書き換えに関する注意がありました。下記のケースで論理IDが代わり、必ず置き換えになるようです。

  • Construct時のIDを変更する

  • Constructを別の階層に移動する

12. ハイレベルなコンストラクトを使おう

抽象化はソフトウェアの正常な発展の形で、こわくないよ！という話が印象的でした。

自分はL1コンストラクトでできるだけ書いた方がいいのではないかと、つい最近の初めてCDKを書いた時にL1コンストラクトで書いていましたが、まさに怖さを感じていました。

次からはL2コンストラクトを使ったり、不安だったらエスケープハッチでL1コンストラクトを取得したり、スナップショットテストで意図しない変更を検知しようと思いました。

13. grant / metric / connections を使う

L2以上で使える便利なメソッドだそうで、さらにL2を使いたくなりました。

14. 必要になるまでスタックを分けない

まずは1スタックで作り、迷うなら分けず、必要になって初めて分けようという話でした。弊社もCDKを使い始めた初期はスタック依存関係で困っていたようでしたが、今はスタックを分けています。

15. コンストラクトで構造化する

「構造化の手段はスタックではなくコンストラクト」という話があり、今の構造化をスタックで行っているのはよくないか…？でも不便はないな…？とは悩みました。

16. ベタ書きから始める

変数にしないことで、初心者にはテストしやすくなり、読みやすくなるという話でした。

17. パラメータはappレベルから注入する

クラスがテスト可能でなくなるためということでした。これに沿っていない実装もあるなと思い、少なくとも今後はこのベストプラクティスを意識したいです。

18. スナップショットテストを書く

テンプレートの出力を比較して意図しない変更がないことを 数行のコードで 確認できるとのことでした。まだ書いたことがないので、次の機会で書いてみようと思いました。

19. リソース名ではなくConstruct IDにこだわる

読みやすさなどの話がありました。

20. コードベースと環境の一貫性を保つ

まずは常に全てのスタックをデプロイすることから始めて、一部だけデプロイする場合も全部の差分を継続的に確認するという話でした。

それをしないと、いつかデプロイするのが怖くなってしまうということで、まさに今そうでは…！？と思って確認しようと思いました。

おわりに

ベストプラクティスによってはできていたり、当たり前だと感じるようなものもある中で、できていないな、やっていきたいなと感じるものもあり、自分に必要なものを持って帰っていこうと思いました。

CDKに関するベストプラクティスを網羅的に聞いたのは初めてで、とても学びになりました。

このあとのセッションもたのしむぞ！

この記事が気に入ったらサポートをしてみませんか？