AWS CDKのベストプラクティスは本当にベストなのか　アーキテクトが今一度考える「リソースの自動名付け」の公理

自己紹介

佐藤智樹氏（以下、佐藤）：それでは始めたいと思います。「それでも俺はCDKの作るリソースに物理名を付けたい〜CDKのベストプラクティスは本当にベストなのか〜」という話をします。

正直に言うと、ユーザーグループのイベントなので、ちょっとこういう話もしていいのかなと思って応募してみたら、思っていたより参加人数がすごく、ちょっとビビっていますが、始めていきたいと思います。

（スライドを示して）私は佐藤智樹といいます。クラスメソッド株式会社のCX事業部のIoTチームにいます。

現在サーバーサイドエンジニアやインフラエンジニア兼、QAがある時の対応や、AWSアカウントのセキュリティはそもそもこうやって設計すべきだよねというような話を考えたり、いろいろやっています。

趣味はAPEXや散歩で、好きなサービスはLambdaやCDK、サーバーレス系です。2021年はずっとLambdaを使っていて、最近コンテナを使っているのですが、セキュリティのことを考えると、Lambdaはメチャクチャ楽でいいサービスだなというのをしみじみ感じます。

（スライドを示して）一番右側に書いてあるアイコンは、この前変わったらしいので、昨日徹夜でパーッと貼りつけました。あとは、AWS Community Buildersという、AWSが自薦で応募したら認めるよというものに応募していて、一応コミュニティビルダーになっています。ただ、特にまだ何もしていないので、その中でCDKのコミュニティを日本で作ったらいいのではないかという作文を書きました。今後は、ぜひそういうことをやっていきたいなと思っています。

自動名付けのリソース名、つらくないですか？

では、本題に入ります。AWS CDKのベストプラクティスとは何かは、このあと説明しますが、そのベストプラクティスと書いてあるものの中で、リソースの自動名付けが推奨されています。

ただ、半年ぐらいいろいろやって思うのですが、自動名付けのリソース名はつらくないですか？　これから「つらいんでどうしましょうか」という話をしていこうかなと思っています。

（スライドを示して）先人の肩に乗るわけではないのですが、『ソフトウェアアーキテクチャの基礎』という、最近出た好きな本があります。この本の中に、「アーキテクトには過去の時代から残されている前提や公理を疑うという重要な責任がある」と書かれていました。

例えば2人しかいないチームなのに、マイクロサービスを何十個も作ったほうがいいみたいな、マイクロサービスという絶対的に正しいものがあって、それを導入しなければいけないみたいな状況があるとします。アーキテクトとしては、一般的にいいと言われているものをどこにでも導入すればいいのではなくて、今のチームや状況を考えて選択することが重要だと思います。それを今回CDKでも、ベストプラクティスに対してやって疑ってみようかなと思っています。

（スライドを示して）今回の目次です。AWS CDKのベストプラクティスってなんだったのかという振り返りをしたあと、今回取り上げる項目はこれですという話をします。そのあとに、リソースの自動名付けの概要で、こういう話を書いていますという話をして、自分がここは問題なのではないかと考える理由と、こうやったほうがいいのではないのかと思っていることを共有したいと思います。

AWS CDKのベストプラクティスをあらためて考える

（スライドを示して）あらためて、AWS CDKのベストプラクティスについてです。AWS CDKのベストプラクティスについて書かれたブログが2021年に出ています。「CDKでクラウドアプリケーションを開発するためのベストプラクティス」という記事が書かれていました。

主に、CDKの哲学、組織で取り組む際の心得、コードの管理方法、それからレポジトリをどう運用していくのか・したほうがいいのかという話、Constructライブラリのベストプラクティスの使い方、AWS CDKアプリケーションのベストプラクティスが書かれていました。

なので、CDKである程度開発している人にとってはけっこう為になる内容で、初めての人にはちょっと早すぎるかもしれませんが、こういう哲学でやっているんだなというのがいろいろわかる、すごく良い記事だなと思っています。

今回はここの、「AWS CDKのアプリケーションのベストプラクティス」に注目して、本当にこれってそうかな？　というのをあらためて考えてみたいなと思います。

（スライドを示して）ベストプラクティスを調べてみてください。AWS CDKのベストプラクティスで調べたら、たぶんブログが出てくると思いますが、その内容は中級者以上向けかなと個人的には思っています。ここの内容を読んでもピンとこないなとか、今日私が話すのもメチャクチャニッチな話なので、もっと体系的で基本的な話が知りたいなとかあれば、以前の「AWS Dev Day」で、CDKで最初に開発する時に詰まる部分やノウハウの共有をしているので、よかったら見てください。

AWS CDKのアプリケーションベストプラクティス

（スライドを示して）あらためて、AWS CDKのアプリケーションベストプラクティスと書いてあるところに書かれている項目の箇条書きを持ってきました。その箇条書きの下に自分なりに解釈したコメントを書いています。では1個ずつ見ていきましょう。

「デプロイ時ではなく、合成時に決定する」。Cfnのパラメーターを使うのではなくて、CDKのテンプレートの生成時に値を埋め込むようにしましょうというのが、公式のドキュメントにも書いてありますし、ベストプラクティスとしてもそういうふうにやりましょうと。Parametersを使わないと書かれています。

あとは、「自動で生成されるリソース名を使用し、物理的な名前を使用しない」。「デプロイ要件に応じて、アプリケーションのStageを複数のStackに分割する」。状況に応じて、Stackのサービスのライフサイクルやチームによって分けようということです。

ほかには、「cdk.context.jsonをコミットして、外部的な要因で合成結果が変わってしまうことを避ける」。同時に1つのアカウントを複数人で使っている時に、リソースの更新が意図せず発生しないようにする知恵で、本当はコミットしないようにしましょうと書かれています。

「CDKでロールとセキュリティグループを管理する」。CDKで一部提供されているロール、例えばgrantナンチャラというファンクションを使うと、簡単にこのリソースに対してこのアクションだけを許可する、みたいなことができます。自分で作るとけっこう作り込みが大変ですが、そのあたりを自動でよしなにいろいろ生成してくれるファンクションとか、セキュリティグループについてもよしなに作ってくれるファンクションがあります。AWSがセキュリティの柱でしたっけ。そこで言っている、最小権限を与える設計を意識して、CDKの機能をフル活用してやりましょうと書いてありました。これもいいことだなと思います。

「すべてのStageをコードでモデル化する」。環境ごとにStackファイルを作らずに、環境ごとの値をパラメーターで切り替えると、環境差異が最小になるという話かなと思っています。

私もこれまで案件をいろいろやってきたのですが、途中から入った案件だと、やはりこのベストプラクティスを意識していなくて、本番用のStackと開発用のStackに分けてしまっているところもありました。結局そこに差異ができてしまうので、そこはできるだけ差異ができないようにパラメーターで切り替えて、最小にしましょうということで、そこはベストプラクティスにもやはり書いてありました。

あとは、「すべてを測定する」。メトリクスやダッシュボードなどを作れるメソッドを活用しよう。LambdaにもX-Rayを付ける値がありますし、ダッシュボードもある程度簡単に作れるようになっているので、その機能をできるだけ活用して、すべての状態を観測できるようにしましょうと書いてありました。これもすごく正しくて、いいことだと思います。

ただ、ちょっと気になったのが、この「自動で生成されるリソース名を使用し、物理的な名前を使用しない」です。私はこのベストプラクティスが出る2021年の何月までは、物理名を付けてやっていて、これに「付けるな」と書いてあったので、あれ？　本当にそうなのかな？　と思いつつ、読んでみました。

ベストプラクティスの詳細と物理名を使う場合のデメリット

（スライドを示して）この項目の詳細を抜き出してきました。ここを読み上げると、「名前は貴重なリソースで、すべての名前は一度しか使えないので、テーブルやバケット、インフラアプリケーションにハードコードしてしまうと、そのインフラは2つ並べてデプロイできず、さらに悪いことに、リソースの置き換えを必要とする変更をこれ以上加えることはできない」と書いてありました。

（スライドを示して）これをダラダラ読んでいくと時間かかってしまうので飛ばして、自分なりに整理した内容をお話しします。私の解釈が入っているので、気になる方はきちんと読んでもらうといいと思います。

「インフラの一部を複数デプロイすることができない」。Aテーブルを作りたい時に、そのAテーブルを複数作れないとか、リソースに破壊的変更を伴う場合は、再作成に失敗するという話が書いてあったのかなと思います。

例えば（スライド）左側の物理名を固定しない場合、テーブルの作成を1度したあとに、DynamoDBのKeySchemaを変更すると、KeySchemaの変更は一応テーブルで途中変更できないので、新しいテーブルが勝手に生成されて、そこのテーブルがCDKと紐づくという流れになります。

物理名を固定している場合は、ここがうまく機能しないと書かれていました。なので、ちょっとスムーズに開発ができないという話なのかなと思いました。

（スライドを示して）自分の経験から、物理名を使う場合のデメリットも考えてみました。削除時のポリシーを保護、つまりRemovalPolicyをRETAINで設定している場合、また勝手にされている場合は、Stackの削除後、再デプロイ時に前回実行したリソースが重複して失敗するのが、Lambdaを使っているとよくあるパターンかなと思っています。

例えば、下のほうの物理名を固定しない場合は、CDKでLambdaを1回スタック・デプロイして作った時はロググループができて、その後Stackを削除してもう1回CDKからLambda作成した時に新しいロググループができるので、エラーになって落ちることはありません。

ただ、もしLambdaの名前を固定していると、それに関連してできるロググループも同じ名前でできます。なので、前からのStackを1回消して全部のリソースを消したと思っているのに、もう1回デプロイした時に失敗します。

ロググループのところがAlready exists errorになる問題があるのかなと、経験から考えました。

（次回へつづく）