AWS CDKの良いところ4 エディタ内での開発完結

k.goto氏:次が4番。エディタ内での開発完結。ここがかなりうれしいところかなと思います。スタートアップは、アプリ開発者が多いことが多いかなと思います。ということは、エディタに慣れている方が多いんじゃないのかなと。CDKはエディタ内でできることが非常に多いです。ドキュメント参照とか、リソース更新差分の表示のdiff表示、CDKリソースのユニットテスト、インテグレーションテスト。これはアプリケーションのソースコードではなくCDKの定義ですね。S3バケットとかSQSのキューとか、そういったもののユニットテストとインテグレーションテストも行えるので、開発ルーティンの大部分がエディタ内で完結できます。

(スライドを示して)これはCDKの開発フローの一例となっているんですが、最初にコンストラクトのガワだけでnew Bucketというものを書いておいて、それでドキュメントを見に行って、ドキュメントを基にパラメーターをコピペしたり、補完入力をしたり、必須入力漏れの項目のLintエラーとかを対応したり、diffしたり、ユニットテストをして、インテグレーションテストをして、デプロイをする。また上に戻ったり下に行ったりという一連のルーティンを、全部エディタ内で完結することが可能になります。

ドキュメント参照

先ほど4つ挙げましたが、1つずつ掘り下げていきます。エディタ内でのドキュメント参照。これはCDKのドキュメント、いわゆるAPIリファレンスというのは、CDKはオープンソースなんですが、その内部にあるREADMEファイルとJSDocというコードコメントからなってるんですね。

これらから自動で生成されてWebにアップロードされる。アップロードというか、Webで見られるようになっています。それでCDKのコンストラクトを自分のVSCodeとかのエディタで打って、そのコンストラクトから型参照、コードジャンプでCDKの内部のファイルに飛べるんですね。つまり、そこからREADMEとかJSDocを見に行くことで、エディタでドキュメントを見ることができます。つまり、いちいち見たい項目のドキュメントをWebで検索しなくても、そのままコードジャンプですぐに飛べるので、いろいろな手間が省けるんじゃないのかなと思います。

例です。見えづらいので中は見なくてもいいんですが、上がJSDocで……。これがAWS Backupかなにかのプロパティで、デフォルト値が何で、こういうプロパティですよという説明がソースコードにあって。(スライドを示して)下のものはWebページからスクショしてきたものなんですが、自動で作られている。

これも中身はわからなくてもいいんですが、左側がREADMEファイルというものです。これを基に右側も同じくWebページから取ってきたんですが、丸々自動で作られているので、エディタ内で同じ情報が見られちゃうという特徴があります。

リソース更新差分のdiff表示

2番目にリソース更新差分のdiff表示というものがあります。CloudFormationではリソースの更新差分「〇〇というリソースを作りますよ、更新しますよ」というようなものを、Change Setという機能で確認できます。これはマネコンで確認することが多いかなと思います。

一方で、CDKではエディタ、実際はエディタ付随のターミナルですが、エディタでdiff確認が可能だったりします。これがcdk diffというコマンドです。これを使うことで、エディタで開発しながらその場で更新差分を確認できるという、非常に強い機能になります。

具体例ですが、例えばとあるリソースのThresholdというプロパティを100から90に変えた時に、cdk diffを実行すると、赤い文字から緑に変えたということが視覚的にわかる。

かつ、右上にreplaceと書かれていて。リソースの置き換え、削除されて作り直しされるということをreplaceというんですが、「これが走りますよ」というところまでもわかるというので、非常に便利です。

CDKリソースのユニットテスト

次がCDKリソースのユニットテスト。CDKのユニットテストではこんな感じでいっぱいやれることがあります。

まずCDKスタック。自分で定義したスタックからCloudFormationテンプレートのオブジェクトを生成することができるという関数が用意されています。

それを基にスナップショットテストができます。ここでスナップショットテストとは何かというと、前回のスナップショットと比較をして変更があるかどうかをチェックするテスト。スナップショットとは何かというと、CloudFormationのJSONですね。テンプレートファイルを保存しておいて、前の状態のものと確認する。そのスナップショットテストが、この関数によって行えます。

次はFine-grained Assertions Testというものがあって。これは何かというと、リソースの個数とか、どういうプロパティを持つかというチェックをするユニットテストの方法です。

右側のresourceCountIs。これも用意されている関数です。WAFが1個作られているとか、その下のhasResourcePropertiesというものに、WAFがDefaultAction:{Block: {} }というプロパティをちゃんと持っているかをテストする。

あとは便利なメソッドでMatch.xxみたいな関数も用意されていて。ここでいうと、anyValue()という疑似値を生成する。(anyValue()は)なにかの値を持つというのを生成するメソッドで、なにかの値を持っている。具体的なIPアドレスをユニットテストのソースコードに直打ちすることはあまりやらないので、なにかしらの情報、IPが入っているアドレスというキーがあるかがテストできる。

それとバリデーションテスト。これは意図したエラーになるかというテストもできます。

CDKリソースのインテグレーションテスト

次がインテグレーションテストで、integ-tests-alphaモジュールというものがCDKから出されています。これは名前のとおりαバージョンなんですが、CDKのオープンソースの内部のインテグレーションテストにも使われているので、非常に信頼性が高いツールかなと。これが、CDKで定義をしたスタックを基に実際にデプロイが走る。

実際に生成されたリソースに対するインテグレーションテストを行って、最後に自動削除するというようなものです。

どんなものかというと、左側がLambdaとAPI Gatewayを作るCDKスタック。これは"Hello"というものを返すLambdaです。

(スライドを示して)右側もCDKのソースコードなんですが、左のCDKのスタックを生成して、それに対してhttpApiCallという用意されたメソッドで、実際にAPI Gatewayにリクエストを投げて、レスポンス内容で"Hello"が返るかというところまで全部CDKのコードでテストを行うことが可能です。

このhttpApiCallは、ヘッダーとかメソッドもいろいろ指定できます。

HTTP APIだけじゃなくて、AWS APIの呼び出しも可能です。例えば「デプロイしたSSMのパラメーターストアにこういう値が入っているか」とか。

複数の呼び出しの組み合わせも可能です。StepFunctionsでデプロイして、スタートして、describeしてみてSUCCEEDEDが返ってくるかみたいなものも全部CDKコード上で行えます。

例えばSQSのメッセージで、メッセージを入れてから取れるまでちょっと時間がかかったりする、期待する状態になるまで時間がかかるものは非同期で行うというようなメソッドも用意されています。

ということで、CDKはエディタでできることが非常に多いということが4番でした。

AWS CDKの良いところ5 「Construct Hub」がある

最後です。Construct Hub。スタートアップは作業が多くて、便利なものがあれば使い回したい。すでにできているものが世にあるんだったらそれを使いたいという要望があるかなと。ここで、AWSが(出している)便利なコンストラクトライブラリ集「Construct Hub」、Docker Hubみたいなものがあります。

これは千何百のオープンソースのCDKコンストラクトが公開されていて、オープンソースなので、それぞれになにかあったらプルリクも出せるし、個人で作った自作コンストラクトも公開できます。また、npmインストールみたいなかたちで取ってくるので、複数プロダクトでの再利用も簡単です。ということで、すぐに使える宝の山で工数削減(ができる)というメリットがあります。

(スライドを示して)ちょっと見づらいと思いますが、こんな感じで「Lambda」と勝手に入力したり、左側でTypeScriptとか。どんな人がPublisherで出しているのかということで、AWS公式が出しているかみたいな柔軟なチェックも可能な検索となっています。

ここで、プライベートで自分が作った物を業務で使って工数削減するという裏技もできたりします。

実際に私もやっています。

「Dockle」というDockerイメージのスキャンツールがあるんですね。これをCDKレイヤー上で走らせて、脆弱性検知の際にはECRプッシュをさせないということを全部CDKレイヤー上でやるということをオープンソースとして公開しています。よかったら使ってください。「Trivy」版も近いうちに作りたいなと思っています。

もう1個作っていて。これはニッチですが、500、502、503、504以外のHTTPCode_ELBのアラームを鳴らすアラームというものもオープンソースで公開しています。これを使いたい人はいないかもしれないですが(笑)。よかったらどうぞ。

ただ注意があって、誰でも公開できるので、信頼できる提供者から提供されているということを必ず確認してください。

AWS CDKで生産性を向上できた5つの理由

ということで、CDKで生産性を向上できた5つの理由というかたちで、3つ目と4つ目にいっぱい機能を詰め込みましたが、こんな感じで5つにまとめました。

まとめとして、スタートアップ企業の開発現場から見たCDKの良いところを全部詰めておきました。

最後に宣伝だけさせてください。9月13日JAWS-UG CDK支部のCDKのパネルディスカッションで話をすることになりました。よかったらご覧ください。

自作のAWSツールをオープンソースで開発していまして、CloudFormationスタックを強制削除するツールとか、S3バケットを高速削除・空にするツールとか、Lambdaのいろいろを検索するツールとかを出しているので、よかったら使ってみてください。

ご清聴ありがとうございました。