Zenn
📘

[レポート]AWS CDKはどう使いこなすのか、初期開発から運用までのノウハウ (AWS DevDay 2021)

2021/10/01に公開
AWS
AWS CDK
tech

はじめに

DevDay Online 2021の「AWS CDKはどう使いこなすのか、初期開発から運用までのノウハウ」のセッションを聞きました。
自分の解釈で内容をまとめたいと思います。

オリジナルの資料はこちらにあるので参照ください：AWS DevDay Online Japan に「AWS CDK はどう使いこなすのか、初期開発から運用までのノウハウ」というタイトルで登壇しました #AWSDevDay | DevelopersIO https://dev.classmethod.jp/articles/aws-devday-online-japan-know-how-from-initial-development-to-operation-on-how-to-use-aws-cdk/

わかったこと

  • CDKの学習コンテンツってどれがいい？
  • 初期開発時に検討すべき項目ってどんなものがあるだろう？
  • 運用で気にするべきこと

CDKの学習コンテンツってどれがいい？

習熟度に応じて、適切なコンテンツが変わってくる。
そして、中間レベルのコンテンツが意外となさそう。

初期開発時に検討すべき項目ってどんなものがあるだろう？

初期開発時に決めておくとスムーズな項目が11つある

  1. 選定する言語
  2. AWS CDKのパッケージ管理
  3. アプリ層(bin)の分け方
    • 基本はAppは1つでも良さそうではある
  4. スタック層(lib)の分け方
  5. スタック感のリソース参照
  6. コンストラクト層の使い分け
  7. 複数アカウントへのデプロイポリシー
  8. コーディング規約
    • tryGetContextをどこで書くべきか
    • どこまでDRYにするか、L3に寄せるか
    • 等
  9. 複数人開発時のデプロイ方法
  10. リポジトリの粒度
  11. どこまでAWS CDKかすべきか

プロジェクトによらず使えそうだな。と思ったノウハウは以下

  • 使用言語にこだわりが無ければTypeScriptがオススメ。なぜなら、日本語の記事やサンプルコードが得やすいため

    • もちろん、チームに合わせればよい。他にもJavaScript, Python, Java, C#, Goなど色々あるので。

  • CDKのパッケージは全部同じバージョンに揃えるべき

    • バージョン間で互換性がなくて、エラーになることがあるので（わりと開発プロジェクトが進行していると、まぁ当たり前だろ、って認識になり暗黙知化しちゃいやすい・・）

  • CDKでは各種AWSリソースをどう設定するかをConstructという単位で構成していく

  • Constructに3つの種類が存在する

    • L1：CloudFormationのリソースと1:1で対応する
    • L2：デフォルト値や追加の関数を実装してL1Constructを抽象化したもの
      • 例えば、必須値だけ渡せばAWSリソースを定義できる = 必要なコード量が減る
    • L3：L1,L2をさらに抽象化したもの
      • 定義しなければ暗黙的にデフォルト値が適用されたりするのでコーディング料は少なくなる。
      • 例えば、VPCを例にとるとここまでコード量を少なく出来る

  • 複数のConstructを1つのStackにまとめることができる

  • 複数のStackを1つのAppにまとめることができる

  • 従って、CDKではApp -> Stack -> Constructという順に階層化して管理できる

  • Appは基本1つでも問題ない

    • ただし、バックエンド/フロントエンドなど、分けると可読性が上がる場合もあるので検討すると良い

  • Stackは次の観点で分け方を検討するとよい

    • デプロイのライフサイクル
    • 影響範囲
    • 関係者
      • 例えばフロントエンド/バックエンド 等
    • AWS CloudFormationの制約
      • 一つのStackに載せられるリソース数に制限がある場合があるので、それを考えると分けざるを得ない場合がある

  • 逆に難しいことを考えずに一旦1つのStackにまとめてしまう、という考え方もあり。特に問題がなさそうであれば。

  • なお、Stackを分けた場合、別なスタックの値を参照する方法が3つある。用途に合わせて使い分ける

    • 自動クロススタック参照
    • ネストスタック参照
    • ARNベースの参照

  • Constructは次の観点でL1-L3を使い分けるとよい

    • L3でやってみる
    • L2を中心に組んでいく
    • （同しようもない部分だけ）L1も使っていく

  • あるいは、L2を中心に組んでいき、複数のPJTで同じような構成を作ることが多いな、ってなってきたらL3に移行していくというのもよいのでは

  • 前提として、CDKはCloudFormationがベースになっている

  • 複数アカウントを利用して開発〜運用する場合には、cdk.jsonに各AWS環境用の設定をまとめて、デプロイ時に参照されるようにすると複数AWSアカウントを利用する際に便利

    • 逆に言うと、各環境毎にスタックを作る、というのはやめたほうがいい

  • 複数AWSアカウントを利用する例

    • Gitflowに合わせて、各ブランチ用にAWSアカウントを用意する
      • mainブランチ用
      • releaseブランチ用
      • developブランチ用
      • featureブランチ用
    • 負荷テスト用のAWSアカウントを作って、そこで負荷テストを行う
    • 等

運用で気にするべきこと

運用開始前に決めておくとスムーズな項目が5つある

  • サービス選定
    • AWSのCodeシリーズ使うのか、外部CI使うのか
      • Codeシリーズの利用パターン
        • CDK Pipelinesを使うのか、Codeシリーズをそのまま使うのか
    • 外部CIの利用パターン

その上で、次の点は把握しておくと良い。

  • Codeシリーズの場合の問題
    • チームで導入検討する場合、AWSサービスの仕様の理解が必要なので、その点は若干学習コストがかかるメンバーもいるかもしれない

おわりに

CDKを使ったプロジェクトを始める際の考慮すべきこと、運用時に考慮すべきことについてよく分かるセッションでした。

個人的な感想ですが、キャッチアップにも有用な話でした。
これからCDKを使ったプロジェクトに参画する人も、「なんでこうなってんの？」っていうのをこのセッションの内容をもとに一通り確認するといいと思います。

参考

Discussion