実は意外と仲良し「AWS CDK」と「AWS SAM」　一緒に使う時のTipsと使い分けのポイント

自己紹介とアジェンダ紹介

藤原麻希氏（以下、藤原）：私からは、CDKを使う時にSAMも一緒に使ってあげるといいのではないかというTips、小ネタを話そうと思っています。よろしくお願いします。

（スライドを示して）株式会社ゆめみの藤原麻希です。ふだんはサーバーサイドエンジニアをしていて、PHPを20年近くやっています。最近だと仕事はEC2になぜか乗っているdockerをFargateに移行したりしています。

ついこの間、資格が1つ増えました。近々1個が切れるので、もう1個取ろうかなとがんばっています。

先ほどSAMの話を出したのですが、CDKと一緒に使ったらいいんじゃない？　というツールがいくつかあるので、それを紹介していこうと思っています。

想定視聴者は、今日のCDKの話を聞いてきて、サクッと開発環境を作るぐらいは理解していて、CDKがCloudFormationのテンプートに変換されて、それをデプロイするというのを押さえている人です。

あとは、LambdaとAPI GatewayでAPI1本ぐらいはみなさん作ったことがありますよね？　という前提でやりたいと思います。それからNodeやnpm runを、少しやったことがあるぐらいわかっていればいいかなと思います。

TypeScriptは私もほとんどやっていなくて、CDKの時にTypeScriptだと補完がすごく強力なので使ってみた、ぐらいの経歴でやってがんばっています。

CDKと一緒に使える4つのメジャーツール

（スライドを示して）CDKと一緒に使える日本でメジャーなツールを持ってきました。AWSから出ているSAMとAmplify、右側はTerraform、LocalStackです。LocalStackは本当にこの名のとおり、ローカルで使うツールです。では1個ずつ見ていきます。

（スライドを示して）まずAmplifyです。2021年のre:Invent直前の1週間でドドドッと出たものです。Amplifyの設定で一部オーバーライドするのをCDKで書けるというのが1つです。

例えば、RDSを追加したい場合は、持っていないのでどこか別のところで作る必要があります。RDSで追加したとか、レコグニションで顔認識したいなど、別のリソースを入れたい時に、Amplifyのリソースをここで管理すると、エクスポートしてCDKに統合させられるようになりました。AmplifyはCDKとすごく仲良くしたいようです。

（スライドを示して）それから次は、Terraformです。私はあまり使えていないのですが、このあと発表があると思うので楽しみにしています。CDKをやろうと思った時に、「いや、でも会社でみんなTerraformをやっているんだよな」とどうしても思ってしまっていたのですが、どうもCDKで書いたコードをTerraformのステートファイルに書き出せるらしいので、これはちょっと楽しみにしています。

（スライドを示して）これもサラッといきます。LocalStackです。ローカルで開発する時に、Lambdaはこのあと出てくるSAMコマンドで動かせるのですが、それ以外の、例えばDynamodbやCognito連携など、わりとサーバーレス方面に寄ってはいるのですが、ローカル開発やテスト、CIで使うようなサービスの、モックと言ったらいいのか、正しい呼び方がちょっとわかっていないのですが、AWS非公式のツールです。

Dockerコンテナのかたちで提供されるので、わりとサクッと立てて、そこに対して、データを入れたり書いたりして使えます。これは意外と知らなかったという声をJAWS-UGのハッシュタグで見かけたので、紹介しておきます。

AWS SAMの紹介

（スライドを示して）いよいよAWS SAMです。SAMはServerless Application Modelの頭文字を取っているらしいです。基本はCloudFormationベースです。LambdaだったりAPI Gatewayや、ステートマシンなど、よくサーバーレスで使われるサービスをCloudFormationで書くとやはりけっこうな量になるのですが、すごくギュッとまとめて、必要なところだけを簡潔に書けるようになっているものです。

「cdk synth」をすると、CloudFormationのテンプレートに変換されるというのがあったと思うのですが、その変換されたテンプレートをSAMから読み込むことができます。「sam local ナンタラ」とするとLambdaを動かせます。

（スライドを示して）これは、SAMを使ってアプリケーションを作る時の話です。SAMのインストールを、サクッとしてもらって、initしています。通常だとsam buildをすると、テンプレートファイルをCloudFormationに変換してくれます。

そこにさらにローカルで開発用のコマンドとして、sam localシリーズのコマンドがいくつかあって、invokeというファンクション名で、このファンクションをこのイベントの内容で実行してくれます。

このイベントは、どんなものが入ってくるの？　と私はいつも困って、とりあえずログを仕込んでCloudFormation？　CloudWatch？　CloudWatch Logsで見てからどうしようと考えることがよくありました。

実はこの「sam local generate-event」は、ここのサービス名のところに、このあたりに書いてあるいろいろなものを指定できます。例えば、このalexa-skills-kitはどんなイベントが飛んでくるかぜんぜんわからないのですが、これをやるとJSONの形式で生成してくれるので、それをファイルに保存して、ここで使うことができます。

これはファンクションをそのまま実行するタイプなのですが、「sam local start-api」でポート番号とやると、httpサーバーをこのポート番号で立てて待ち受けられます。そこでデプロイする前にローカルでエンドポイントに対してポストしたり、テストをすることができます。

CDKアプリ作成とデプロイのフロー

藤原：CDKの場合はどうだったかというと、まずbootstrapします。ここのlanguageはなんでも大丈夫です。buildすると、cdk synthをやったあたりでCloudFormationのテンプレートが出てくるので、ここでサブコマンドが登場します。このあたりで使うものだと思ってください。

一緒に使う時は「sam local invoke」、イベントを渡すのは一緒ですが、これがCDKだと（スライドを示して）このあたりにテンプレートが出てきます。それをFTで指定して、最後に実行したいファンクションを渡す感じになります。

同様に「local start-api」でまたテンプレートを渡すと、ここに含まれているファンクションを全部APIで待ち受けてくれます。

（スライドを示して）それで何ができるかというと、読み方にちょっと自信がないのですが、エングロックでしたっけ。例えば、slackから受けるWebhookのAPIを作ろうかなと思う時に、ローカルでテストできないとAPI GatewayとLambdaをデプロイして、そこにポストさせて動かしながら開発していたと思うのですが、1回デプロイするのに何十秒とかかかると、けっこう開発が大変でした。

それがどうなるかというと、エングロックにポストして、それをNATの下にあるお家のマシンで受けて実行できて、ログもその場でターミナルに表示される状態なので、すごく開発がしやすくなるかなと思っています。

SAMとCDKはどう使い分けるといいのか

藤原：（スライドを示して）最後に、SAMがすごくいいなと思っているのですが、CDKとどう使い分けたらいいんだろうというところを考えてみました。良くも悪くもSAMは単一のYAMLファイルです。なので、YAMLファイルでどのぐらいだったらAPIを書き連ねられるだろうと考えた時に、やはりLambdaの10個ぐらいが限度ではないかなと思います。ですから、ある程度大規模になってくるとCDKかなという気はしています。

あと、ポリシーテンプレートがあるので、本当にWebhookがいけるぐらいのAPIを1本2本作るとか、そういう小規模なものだとSAMでサクッと作るのは楽なのですが、お仕事でやるようなAPIを何10本作るのなら、やはりCDKなのではないかなと思っています。

CDKを使うのだけど、ローカル開発は先ほど紹介したようにsamコマンドは使えるので、ちょっと使ってみてください。というわけでCDKとSAMは、意外と仲良しですよという話でした。以上です。

質疑応答

吉田真吾氏（以下、吉田）：ありがとうございました。

新井田晃史氏（以下、新井田）：ありがとうございました。

藤井貴昭氏（以下、藤井）：ありがとうございました。

吉田：新井田さん、質問は来ていますか。

新井田：質問は来ていなかったのですが、Twitterではけっこういろいろ盛り上がっています。僕自身はSAMのリソースとCDKをどう使い分けようかみたいなところがやはりちょっと気になっていたので、その話が聞けてすごくよかったなと思います。

けっこうサーバーレスフレームやSAMを使っているとそのあたりは迷うところだと思います。

★動画よりキャプチャ

藤原：そうですね。このあとのTerraformの話もすごく興味深いので、楽しみに聞きたいと思っています。

吉田：sam localは、CDKの間でSAMを使って生成をして、連携をして、かつ、ローカルでのテスト……先ほど言っていたのはLambdaの処理だけでしたが、それだけではなくてsam localを使えば、Lambdaのテストはsam localでできるんですね。ただそれだと……。

藤原：httpサーバーをかける。

吉田：httpのほうがそうですね。

藤原：うん。

吉田：それでもIAM権限がついているかどうかは見られないですよね。

藤原：そうですね。

吉田：他も完全にクラウド側でのインテグレーションテストするしかないなという感じですよね。なるほど。

藤原：そうですね。

吉田：そのあたりの用法と用量を考えるのが肝かなというところですかね。

藤原：はい。私はもともとPHPerなので、動かないとは言わないですが、基本的にLambdaにPHPはないじゃないですか。

吉田：そうですね。

藤原：なので、一番慣れている言語ではない、例えばTypeScriptやPythonでがんばっているのですが、シンタックスエラーになったりと、まだ慣れていなくてつらいなというところを、いかにデプロイ回数を減らして早く開発するかというのを考えていたら、あ、いいのがあるじゃんと気づいたので、紹介したいなと思いました。

★動画よりキャプチャ

吉田：ありがとうございました。藤井さん、いかがですか。

藤井：はい。私も興味があるところだったので、楽しく聞かせてもらいました。今サーバーレスの環境をどういうふうに作ろうかなと、ちょっと比較していて、私たちの中ではサーバーレスフレームワークを、使っていたりとかするのですが、使ってみないとやはりわからないところがけっこうあります。ああ、SAMはこんなことができるんだなというのが、すごく羨ましく見ていました。

私が見ている感じだと、ホットデプロイはたぶんサーバーレスフレームワークだとできないのではないのかなというので使えていません。なので、そこは大きな違いだなとしみじみ感じていますが、もう動きが始まってしまったので、このままがんばるしかないっていう。

一同：（笑）。

藤井：こういう情報はすごくありがたいです。時々変わっていたりしますし、ありがたく聞かせてもらいました。

藤原：SAMは、けっこうできる子なので、使ってみてください。

吉田：はい、ありがとうございました。