検証環境の追加タスクで、後から環境を複製する難しさを実感　IaCの導入決定で、僕がCDKを選んだ理由

前回のプレカンファレンス資料の紹介と今回のアジェンダの紹介

吉川幸弘氏：それでは、「3年目のCDKを振り返って」を始めます。まず、前回のプレカンファレンスの資料について軽く紹介しておきます。

前回は、CloudFormationにおけるクラウドウォッチやRUMの問題を、CDKで解決するストーリーで登壇しました。RUMのL2 Constructを作成して、チーム内で共有して、RUMの導入速度を改善するという内容でした。現在そのL2 Constructは、awsのリポジトリにRFCとして提出して、レビューをしてもらっている途中です。

前回の資料が少し踏み込んだ内容だったのと、今回はトップバッターなので、ライトな資料にしました。みなさんのように込み入った話ではなく、当たり前な内容ばかりになっていると思いますが、その点をご了承ください。

それではアジェンダです。今までのAWS CDKの運用について話して、最後に前回のプレカンファレンスでいただいた質問について軽く回答していこうと思います。

自己紹介

申し遅れました、私、吉川幸弘と申します。Twitterなどでは「ゆっきー」と呼ばれています。大阪のスタートアップのエンジニアで、ふだんはお客さまのAWS導入のサポート、自社プロダクトの開発、および営業を担当しています。

好きなテクノロジーは静的型付け言語と、Infrastructure as Codeで、特に両点を備えているAWS CDKが大好きです。「@WinterYukky」というIDでTwitterもしているので、よければフォローをお願いします。

データウェアハウスのデータを活用したBIツール作成プロジェクトに参加

吉川：それではアジェンダの1点目、私が初学者にCDKをおすすめする理由について。私がCDKを始めた時の状況について共有します。

当時の私はAWSの利用経験がなく、TypeScriptとGCP、Google Cloud PlatformのGKEが少々できるレベルのスキルセットでした。その時に、データウェアハウスのデータを活用したBIツールを作成するプロジェクトに協力することになりました。

1ヶ月でPoC開発は無事完了

約3年前の話なので、少々（スライドの）雰囲気を変えます。データウェアハウスのデータを活用したBIツールの作成についてです。

当時のチームについて紹介しておきます。そのプロジェクトには、データウェアハウスを管理するチームでBIツールを作成したいという要望がありましたが、そこにはデータウェアハウスの管理人しかおらず、アプリケーションを開発できるメンバーがいないということで、私に協力要請がきました。

その時のデータウェアハウスの管理者Aさんは、唯一この3名の中でAWSを触ったことがありました。ちなみに、AさんはそのデータウェアハウスのデータをバックアップするS3コンソールを唯一触ったことがあるということで、彼にAWSのコンソールをお任せしました。残った管理者BさんにはそのままETLの処理を頼み、私がアプリケーションを開発するというチーム構成で進みました。

実際にPoCタスクをいきなり始めたのですが、こちらに関しては問題なく、AさんがAWS環境を構築し、BさんがETLを構築し、最後に私がアプリケーションを開発することで、PoCタスクをすぐに完了させることができました。AWSのすばらしいところだと思います。

検証環境の構築タスクでIaCの導入を決意

1ヶ月でPoC開発を完了したのですが、それも束の間、すぐプロト版を開発することになりになり、その時に今の本番環境と検証環境に加え、もう1個、追加の検証環境が必要だという話になり、そこで検証環境の追加のタスクができました。

環境追加タスクに対応しようとした時に、Aさんはデータウェアハウスのメンテナンスタスクに取り掛かっており、対応できないという状況になりました。Bさんも当然メンテナンスのタスクがあり、またAWSを触ったことがなかったので、そのままメンテナンスのタスクをしてもらい、私がAWSの検証環境追加タスクを行うことになりました。

ですがAさんも初心者だったため、マネジメントコンソールをIaCでは作成していませんでした。また、タグやネーミングルールなども一切なく、無邪気に作成していたため、今どのような状況になっているかが判断できませんでした。そんな中でもさまざまなリソースの情報を参照して、なんとか、なんとか！　追加環境を作成することに成功しました。

そういったところを経て複製はできたのですが、あとから環境の複製を作る難しさをいたく痛感しました。そこで、IaCの導入を決定しました。

CloudFormationはハードルが高かった

吉川：最初はCloudFormationを検討していたのですが、少々ハードルが高かった記憶があります。自身の能力不足もありましたが、プロト開発までにCloudFormationを学べばいいというスタンスで考えていたところ、他のメンバーの学習意欲が若干低いという問題があり、これらの問題を解決しないと、実際の運用時に大きな問題が発生すると判断したため、先にこれらを解決する必要があると思いました。そんな時にCDKを知り、採用することにしました。

CDKを採用したポイント1　ドキュメントが初心者に優しいこと

CDKを採用したポイントの1点目は、ドキュメントが初心者に優しいことです。先ほどもAPIリファレンスの話を吉田真吾さんがされていましたが、CloudFormationのドキュメントと比較していこうと思います。

これがCloudFormationのドキュメントです。CloudFormationのドキュメントは、プロパティごとに網羅的な説明がある反面、AWSのサービス知識が前提にあることや、このように例が長いため、初学者がいきなり取り掛かろうとしても壁になりやすいという問題がありました。

それに対してAPIリファレンスは、何に対してといったところが簡潔に説明されており、CDK自体がサービス知識を前提としない設計になっているため、組み合わせやすいサンプルコードが手に入りました。

実際に量も多く、このように大量に情報が提供されているため、初心者でも迷わずに進むことができます。

CDKを採用したポイント2　静的型チェックが効くこと

吉川：次に、静的型チェックが効くこと。これが私の一番のお気に入りですが、例えばこちら、画面右側にCloudFormationのテンプレなどを記述しています。この中にはあえて誤りをいくつか含めていますが、みなさんはすぐに見つけられたでしょうか。

それでは、誤りについて説明していきます。まずこちらですね。runtimeにnodejs14という値が設定されていますが、実際には許容されない値で、正しくはnodejs14.xという値を設定する必要があります。

次にこちら、Handlerにindex.handlerを設定しているように見えます。しかし、この場合は誤字が入っており、hanblerという値になっています。こちらもなかなか見抜くことができません。

次にMemorySizeです。128MBの指定になっていますが、CloudFormationでは128といったナンバー型の値を指定する必要があります。

最後に、こちらです。roleにlambda-roleという、おそらく名前が設定されていますが、このroleにはarnを設定する必要があります。これらを見抜くことは難しいです。

みなさん、すべての間違いを見つけられましたか。CDKのL1 Constructになるだけで、この問題の一部が解消されます。L1 Constructとは、先ほど亀田さん（※亀田治伸氏）が説明されていましたが、CloudFormationリソース仕様からCDKのリポジトリで自動生成された型になっています。

L1 ConstructとL2 ConstructにおけるTypeScriptチェックの差

吉川：それでは、L1 Constructの場合を見ていきましょう。先ほどのruntimeのnodejsですが、こちらはstring型になっているため、残念ながらL1 Constructでこの問題を検出することはできません。その代わり、TypeScriptの型チェックにおいて存在しないプロパティ名は防ぐことができます。同様に、合わないデータ型、誤ったデータ型も事前に防ぐことができます。roleは、残念ながらL1 Constructでは防ぐことができません。

L1 ConstructからL2 Constructになることによって、この問題が解決します。なお、L2 Constructとは、L1 Constructを拡張した高度なモジュールになっています。

では見ていきましょう。先ほどnodejs14は防ぐことができませんでしたが、L2 Constructの場合、runtimeがenum型になっているため、enumに定義されていない値以外を防ぐことができます。また、先ほどと同様、存在しないプロパティ名や合わないデータ型も、当然防ぐことができます。

最後に、こちらが大きなポイントですが、iamのroleのL2 Constructのインターフェイスが、roleの指定プロパティの型になっています。こうなっていることにより、指定されたインターフェイス以外の値が代入されることを防げ、名前なのかARNなのかを開発者が意識しなくていいようになっています。これらの型が、初心者の初歩的なミスから守ってくれるので、とても助かりました。