サーバーレス中心のプロトタイプ開発を実演
今村優太氏：それでは後半のセッションを始めていきたいと思います。よろしくお願いいたします。まず本セッションの概要について説明させていただきます。
本セッションでは前半で議論いたしました書籍の新刊情報システムについて、APIおよびバッチ処理を構成するサーバーレスな機能を中心として、実際にプロトタイプ開発を行う様子を解説とコーディングを交えてお送りしていきます。
サーバーレス開発の概要を視聴者の方にご体感いただくことを目的としたセッションとなるため、細かい文法の解説というものは今回の内容には含まれておりません。セッションの最後に、今後みなさまでサーバーレス開発を進めるにあたってご参考となるような資料をご案内させていただきます。こちらをお役立ていただければと思います。
またコーディングでは言語としてPython、エディタはVisual Studio Codeを使っていきますが、難易度の高い実装というものは今回含まれておりません。そのためほかの言語が得意な方でも問題なくご視聴いただけるかと思います。
最後にセッション内で作成する成果物については資料のダウンロードリンクよりソースコードを入手することが可能です。こちらもご活用ください。
開発を効率化するツールのご紹介
それではセッションを始めていきましょう。まずはじめにサーバーレスな開発を支援、効率化してくれるツールについて見ていきます。
一番最初にご紹介するのがこちら、AWS Serverless Application Model、通称AWS SAMと呼ばれるものになります。こちらはサーバーレスなアプリケーションのデプロイに特化したAWS CloudFormationの拡張機能といった位置づけになっております。
CloudFormationと同様にYAML、もしくはJASONといった形式でサーバーレスのリソースの定義を記述していきます。CloudFormationで同一の内容を定義した場合と比較して、比較的簡潔にテンプレートを書くことができるという点が大きな特徴となっています。
では実際にどういったものを書くのかというところを簡単にご覧いただきたいと思います。画面の左にお出ししている内容がSAMの機能を用いて書かれたテンプテートになっています。
一方で右側のテンプレートはSAMの機能を用いずに同じリソースを定義した場合のテンプレートです。通常のCloudFormationの文法のみで構築した右側と比較して、はるかにシンプルにテンプレートを定義できているのが見て取れるかと思います。
続いてご紹介するのが、AWS SAM Command Line Interface、AWS SAM CLIと呼ばれるツールになります。こちらは先ほどご紹介したSAMを利用した開発を支援するコマンドラインツールとなっています。サーバーレスアプリケーションの雛形の作成ですとか、作ったアプリケーションのビルド、さらにAWSのデプロイといった一連の操作を行うことができるようになっています。
また開発者のローカルの環境で、LambdaをDockerコンテナとして起動してあげるといったことができます。実装した処理を実際に試していくということができるようになっています。
またLambdaの機能を提供するDockerイメージなんですけれども、AWSが公式に提供しているという点も大きな特徴です。本日のプロトタイプ開発ではこちらのツールを利用してローカル環境でLambdaを起動するといったことをやっていきます。
最後にご紹介するのがこちら、LocalStackというツールになります。こちらはAWSのサービスではないのですけれども。オープンソースとして公開されているクラウド環境のモックを行うためのツールになっております。
AWSのサービスを20種類以上、開発者のローカルの環境でモックをすることができるようになっています。Dockerのイメージとして、こちらもDocker Hubのほうに公開されています。ですので、こちらもDockerのコンテナとして起動することが可能になっています。本セッションで行うプロトタイプ開発では、こちらのLocalStackというツールも、モックの役割として使っていきます。
新刊情報システムのアーキテクチャをおさらい
続いてプロトタイプ開発に入る前に前半のセッションを少しおさらいしてみましょう。まずはAPIについてです。前半のセッションで議論した新刊情報システムですけれども、APIのGUIのアーキテクチャはこのようになっていたかと思います。
GUIの配信にはCloudFrontとS3というサービスを使っておりまして、一方でAPIについてはサーバーレスなコンポーネントがさまざまに利用されていたかと思います。APIの提供としてAPI Gateway、プログラムの実行基盤としてLambdaが使われていて、データベースとしてはAmazon RDS、こちらはMySQLのデータベースが利用されています。
またデータベースの認証情報としてはAWS Secrets Managerと呼ばれる場所にデータベースのユーザー名やパスワードといったものを保存しています。こういったアーキテクチャになっていたかと思います。
今回のプロトタイプ開発では、特にこのAPIの開発にフォーカスして実装していきます。
実装するAPIと用意するデータベース
ではどういったAPIを実装するのかなんですけれども。こちらの2種類を予定しています。
まず1つ目、左側ですね。こちらが新刊の一覧を取得するAPIとしてGET/booksというAPIを予定しています。こちらは単純に新刊の書籍一覧を返すようなAPIを想定しています。
続いて右側ですね、こちらは新刊の予約を行うAPIを想定しています。POST/reservationsというAPIです。こちらはリクエストパラメータとして書籍のIDを受け取りまして、レスポンスとして予約をしたユーザーのIDと書籍のIDを返すような、こういったAPIを今回のプロトタイプ開発では作っていきます。
続いてMySQLのデータベースに用意するテーブルについてご紹介します。
まずupcoming_bookというデータベースを作りまして、テーブルとしては3種類の用意を予定しています。まず1つがbookテーブルですね。こちらは新刊の価格ですとか発売日、あとは名称を保存するテーブルになっています。
次に一番右のuserテーブルというものですね。こちらは非常に簡略化しておりまして、単純にサイト利用者、このサイトを利用する人のメールアドレスを保存するといったテーブルになっています。
最後に真ん中、3つ目のテーブルですけれども、こちらがreservertionテーブルというものになっていまして、予約が入った際に予約をしたユーザーのIDと新刊書籍のID、こちらの対応関係を保存するテーブルというものを用意しておきます。
そして今回のプロトタイプ開発で最終的に用意する開発環境としてはこのようなかたちになります。
まずAWS SAM CLIでLambdaコンテナですね。Lambdaの実行をローカルでテストするような環境を作っていきます。またAmazon RDS、MySQLのデータベースをモックするものとしてMySQLコンテナを用意するのと、あとデータベースの認証情報を保存しておくAWS Secrets Managerですね。このサービスをモックするものとしてLocalStackコンテナを起動します。
コンテナを複数個管理していきますので、Docker ComposeというDockerコンテナを複数マネージできるようなこういったツールも併せて使っていきます。
Dockerコンテナの開発からスタート
では実際にプロトタイプ開発を始めていきましょう。
まずDockerコンテナの開発から始めていきたいと思います。まず、Dockerコンテナの設定ファイルであるdocker-compose.yamlというファイルを作成します。
次にネットワークの設定をしていきますが、記載するcontainer-linkという名前、これはdocker-compose.yaml内でのネットワークの参照名となります。一方でネットワークの実名としては、docker.internalがネットワークの実際の名前となります。
それでは実際にDockerコンテナとして起動するサービスを定義していきます。まず1つ目がLocalStackですね。imageというキーの中にDocker Hubのイメージ名を指定します。今回はlocalstackのlatestイメージを取得しています。
次にLocalStackコンテナが利用するポートの設定をしていきます。「20800」と書きましたけれども、左側がローカルホストからアクセス可能なポート、右側がコンテナ内のポートです。ローカルホストの20800番への通信をコンテナの20800番へルーティングするという設定がこちらになります。
続いてLocalStackコンテナの環境変数を設定していきます。LocalStackコンテナではSERVICESという環境変数に、モックするAWSのサービス名とポートの対応関係を書くことで設定が可能です。今回はデータベースの認証情報を保存するSecrets Managerというサービスを、20800番のポートで公開するという設定を行いました。
最後に接続するネットワークの設定ですが、こちらは先ほど作成したcontainer-linkというネットワークに接続します。これでLocalStackコンテナは完成です。
MySQLのコンテナ作成とデータの投入
さらにもう1つ、同じ容量でMySQLのコンテナも作成します。詳細はMySQLのコンテナイメージのリファレンスをご確認いただければと思いますが、データベース名としてはupcoming_book、ルートユーザーのパスワードとしてmysql、公開ポートとして3306を設定しているかたちになります。
仕上げにdocker-compose up -dというコマンドを打つと、DockerのネットワークとともにLocalStackコンテナとMySQLコンテナが立ち上がります。
次にMySQLのコンテナに接続していきます。MySQLコンテナですけれども、ローカルホスト127.0.0.1ですね。こちらが赤枠で囲ったポート、3306番で公開されていますので、それで接続が可能です。接続ができましたらテーブルの定義とテスト用のデータを随時入れていきます。
テスト用のデータなんですけれども、書籍テーブルのほうには2件の書籍データをテスト用に投入しています。一方でユーザーテーブルの、テスト用のユーザーとしては1件のデータを登録しています。
次にLocalStack、Secrets Managerのモックに対してデータを入れていきたいと思います。データの投入はAWS CLIから行いますけれども、この際endpoint-urlというオプションを使うことで、どのエンドポイントに対してデータの投入を行うかを指定することができます。
今回はローカルホスト20800というのを指定していると思うのですが、この20800というのが、赤枠で囲ったホスト側に公開してるポート20800番と対応しています。
投入する内容としては、MySQLに接続するユーザー名、そしてパスワード、それぞれrootとmysqlという値2種類を入れています。うまくデータが入ったかどうかを最後にget-secret-valurというかたちで確認をしております。はい、うまく入ってますね。
雛形の作成からライブラリの指定まで
続いてAWS SAM CLIを使ってLambda関数の雛形を作るんですけれども、雛形の作成にはこのようにsam initというコマンドを打ちます。
言語の選択です。今回はPython3.8を選択してます。言語ですとかプロジェクト名、こういった設定を入れていきます。今回は雛形としてhello worldのサンプルを選択したんですけれども、例えば関数の実装はこういったかたちでapp.pyというファイルに雛形が入ってきます。
一方でSAMテンプレートのほうはtemplate.yamlというファイルに最初の雛形が作成されます。
それではさっそく今作った雛形を起動してみたいと思います。起動にはこのようにsam local start-apiというコマンドを使います。
こちらを実行するとこのようにアクセスするためのエンドポイントが払い出されます。さらにこのエンドポイントに対してSAMテンプレートで定義している/helloというパスを加えてアクセスをしてあげると、httpのレスポンスが返ってきます。このようなかたちですね。
返ってきた内容はapp.py、関数の実装の中でreturnしている内容と今同じ内容が返っていることがわかります。
続いて今回のプログラムで使うライブラリを2種類指定していきます。1つがboto3というAWSのSDKですね。もう1つがmysql-connector-pythonというMySQLのドライバを使うことにしています。
Pythonではこのように利用するライブラリをrequirements.txtというファイルに指定します。実際に使う際はimportという文に続けて利用するライブラリの名称を記載します。
そして、boto3を使ってSecrets Managerにアクセスします。この時エンドポイントはLocalStackのほうに向けてあげるんですが、URLはlocalstack:20800となっている点にご注意ください。
この時のURLなんですけれども、Docker Composeのサービス名と対応しています。なのでエンドポイントURLのほうはlocalstack:ポート番号が20800というかたちになっています。
ネットワークでコンテナをつなげる
次にSecrets Managerから実際のデータベースの認証情報を取ってくるという処理を書いていきます。この時にdb-credentialsという名前で、今回はSecrets Managerにデータを格納していますので、そのIDを指定しています。
取れてきた値はJASONの形式になっていますので、jasonとして読み込んであげて、それを最後にprint文で標準出力に出してあげています。ここまでできましたら一度ビルドとローカル実行を試してみたいと思います。
ビルドをするにはSAMテンプレートが配置されているディレクトリでsam buildというコマンドを実行します。アプリケーションのビルドがうまくいくと、このようにBuild Succeededと表示されます。
そしてsam local start-apiというコマンドでローカル実行するのですが、この時docker-networkというオプションに、冒頭に定義したコンテナが利用するネットワーク、今回の場合はdocker.internalを指定します。
これによりsam localコマンドで起動するLambdaコンテナとLocalStackおよびMySQLコンテナがネットワークでつながります。
では実際に実行してみましょう。先ほどと同様にAPIに対してhttpのリクエストを投げてみます。すると標準出力のほうにSecrets Managerから取得したデータベースの認証情報が表示されていることがわかります。
書籍の新刊一覧を取得するAPIの作成
続いてこちらの新刊の一覧を取得するAPIをまずは作っていきます。まずデータベースの名前を変数のほうに入れておきます。名前がupcoming_bookですね。続いてSQLなんですけれども、これは単純にbookテーブルという書籍の管理をしているテーブルから全件データを取得してくるというSQLになっています。
ここからMySQLに接続する処理を書くんですが、ホスト名をmysqlとしている点に注目してください。ここもLocalStackと同様にDocker Composeのサービス名を書いてあげるかたちになります。AWSの接続に使う際のユーザー名ですけれども。これはSecrets Managerから取ってきたユーザー名とパスワードを入れてあげているかたちになります。
データベースのconnectionが作成できましたら、connectionからcursorオブジェクトを生成するコードを書いてあげて、あとはSQLを実行するコードを書いてあげるというかたちになります。うまくデータが取れているか、print文で標準出力に出してみたいと思います。最後に忘れずにcursorとconnectionをcloseするコードも書いておきます。
ここまでできましたら、sam buildコマンドで一旦アプリケーションをビルドします。またsam localコマンドでアプリケーションがうまく実行できるか確認をしてみましょう。
ここでAPI側のログを見てみると、このようにデータベースから取れたデータですね、bookテーブルのデータがうまく取れているということがわかります。データさえ取れてくればあとはAPIの仕様にしたがってレスポンスを返してあげるコードを書くだけですね。
今回の仕様ですと、レスポンスは4種類ありまして。書籍のID、そして書籍の名前ですね。続いてがreleaseDateという書籍の発売日ですね。最後に書籍の価格、priceですね。この4種類を配列形式で返してあげるというものになります。
APIのレスポンスの本文なんですけれども、このbodyというところにデータを入れてあげるとレスポンスの本文として認識をします。今回はbooksというキーに対して先ほどのレスポンスデータを詰めてあげるかたちにしています。
ここまでできましたらsam buildコマンドとsam localコマンドでAPIを実際に動かしてみます。実際に動かしてみると、このようにレスポンスがうまく返りました。
続いてSAMテンプレートを少し修正していきます。まずフォルダがhello worldとなってしまっているので、ここの名前をfunctionsというフォルダ名に変えてあげたいと思います。
さらに実行するLambdaのメソッドを表すhandlerという場所があるんですけれども、これもget_handlerという名前に変えてあげたいと思います。
関数の名前もわかりやすくGetBooksFunctionというかたちに変えています。
さらに今まで/helloだったパスも/booksという本来のパスに変えています。
続いてはこちら、右側の新刊予約を行うAPIを作っていきます。まずこちらのGetBooksFunctionの内容をそのままコピーしてきまして、新しくCreateReservationFunctionというものを作ります。
呼び出すメソッドをpost_handlerという新しいメソッドにしてあげて、APIのパスがpost/reservationsですね。
プログラムの実装開始
ここから実装に入るんですけれども、メソッド名は先ほど設定したpost_handlerですね。こちらのAPIなんですけれども、リクエストパラメータを取得する必要があります。こちらはLambdaのeventという引数のbodyというところに入っていきますので、そこから書籍のIDを取得しています。
あとはSQLの実行の部分ですとか、APIのレスポンスの返却のところですね。こういったところは先ほどのgetのAPIとほぼ同一ですので、今回は割愛していきます。
続いて、Secrets ManagerやMySQLのエンドポイントを商用環境とローカル環境で変えるという設定を入れていきます。まずローカル環境で起動した場合、環境変数にAWS_SAM_LOCALというキーワードが入ってきます。
なのでこういったキーワードが入っていた場合、LocalStackですとかMySQLコンテナのほうにエンドポイントを向けてあげるという設定を入れます。
そうでない場合は商用環境のエンドポイントに向けてあげるという必要があります。中でもRDSのエンドポイントのほうは環境変数から取ってきたいと思いますので、SAMテンプレートから環境変数を設定します。
環境変数はEnvironment Variablesというかたちで設定ができますので、そこから設定してあげて環境変数を取ってきます。あとはエンドポイントを今設定した変数のほうにそれぞれ置き換えてあげるということで、商用環境とローカル環境でエンドポイントの切り替えが実現できます。
さらにGUIからアクセスするという観点でCorsの設定も入れることが可能です。Access-Control-Allowメソッドですとか、Allowheaders、Alloworiginといった設定がSAMテンプレートから設定することができます。
また、テンプレートだけでなくLambda関数のほうでも同様のheaderを返してあげる必要があります。Lambda関数からhttpのheaderを返したい時は、headersというキーワードでreturnをしてあげると、httpのheaderとしてheaderが付与された状態で返ってきますので、ここでCorsの設定を入れておきます。あとはsam buildとsam localで実際に動くかどうかを試してみたいと思います。
デプロイのポイント
今回シンプルなんですけれども、GUIを作ってみました。GUIからAPIを投げているんですけれども、こういったかたちでローカルホストに対してリクエストがうまくとおっているということがわかるかと思います。
もう1つ実装した予約のほうも叩いてみようと思うんですけれども。予約のほうもこのようなかたちでうまくリクエストが通りまして、post/reservationというところに到達しているということがわかります。
続いていよいよAWSのほうにデプロイをしていくんですが、このLambdaを配置すべきVPCの設定等を入れていきます。利用するセキュリティグループのIDですとか、このLambdaをデプロイしたいSubnetのID、こういったものを指定していきます。
またSecrets Managerから今回データベースの認証情報を取りますけれども。Secrets Managerへのアクセス権限等も取得できるように権限を設定していきます。
ここまでできましたらsam buildコマンドでアプリケーションをビルドしてあげます。
ビルドが終わりましたら、続いてsam deploy --guidedというオプションを付けてコマンドを実行します。CloudFormationのスタック名ですとか、デプロイするリージョンの名前などを聞かれますので、このあたりの質問項目に答えてあげてデプロイを開始します。
デプロイが無事に終了すると、最後にAWS上のAPIを実行するためのエンドポイントが返ってきますので、今回はこちらに対してAPIを実行してみたいと思います。
今回はAWS上のデータベースにもテスト用のデータを投入した状態で実行していますが、このようにAPIのレスポンスが正しく得られることがわかります。
メール通知のワークロードを対象としたバッチ処理の開発
これでAPIの開発が完了しましたので、続いてバッチ処理の開発に移っていきます。おさらいとなりますが、バッチ処理では今回メール通知のワークロードを対象としていました。
定期的なスケジュールにもとづいてStep Functionsが実行され、CSVの読み取りとデータベースの更新を行うコンテナのサービスをまず起動します。
その後、新刊の予約を行ったユーザーの情報をデータベースから読み出して、実際にメールを送信するAWS Lambdaの関数がStep Functionsから呼び出されます。今回は中でもStep FunctionsとLambdaに絞ってプロトタイプの開発を行っていきたいと思います。
ではバッチ処理の開発に入っていきましょう。まずはsam initコマンドでAPIの際と同様に雛形を作っていきます。選択する言語は同様にPython3.8なのですが、ダウンロードするサンプルアプリとして今回Step Functionsのサンプルアプリを選択しています。
こちらを選択いただくとサンプルとしてStep Functionsの定義がダウンロードされた状態から開発を開始することができます。もしみなさんが開発をVisual Studio Codeでされている場合は、こちらのAWS Toolkitという拡張機能をインストールいただくことをおすすめしています。
こちらをご利用いただくとStep Functionsの先ほどダウンロードした定義をどのような流れになっているか、こういったかたちでビジュアル化することができますので、よりわかりやすく開発ができるかと思います。
続いてLocalStackの設定を少し変更していきます。今回バッチ処理ではメールの送信を行うコンポーネントとしてSESというサービスを利用しますので、こちらのサービスを新たに追加して、Dockerコンテナ、LocalStackのコンテナを再起動しています。
そしてメールの送信元となるアドレスですね。こちらを事前に認証しておく必要がありますので、CLIから実行します。この際のエンドポイントですね、Secrets Managerの時は20800番のポートでしたが、今回は上で設定したように20801番のポートを使っています。
通知の対象となる書籍のデータをあらかじめ入れておきます。今回は8月8日発売の『AWSで簡単サーバーレス』という書籍を通知の対象にしたいと思いますので、こちらの予約ボタンをクリックしてあらかじめ通知予約をしておきます。
VSCodeのほうに戻りまして、バッチ処理で使うライブラリをAPIの時と同様にrequirements.txtに変えていきます。使う内容はAPIのものとまったく一緒ですので、そのままコピー＆ペーストで貼り付けます。
アプリ実装の具体的な処理方法
続いて具体的なアプリの実装に入っていきたいと思います。まずメールの件名ですね。今回は新刊入荷通知という件名にしています。メールの本文ですが、今回はhtml形式でこのような内容を想定しています。名前と価格と発売日が本文に入るようなかたちですね。
さらに今回使うライブラリのインポートをファイルの冒頭で行っておきまして、さらにAPIの時と同様にローカル環境とAWS環境で分ける設定値を定義しておきたいと思います。APIとほとんど一緒なのですが、送信元のメールアドレスだけローカル環境と商用環境で若干異なった値にしています。
それが終わりましたら、今度はSecrets Managerへのアクセスを行うクライアントですね。これもAPIと同様に書いておくんですが、さらに今回SESというメール送信のサービスにもアクセスしますのでこちらに対するクライアントというものも生成しておきます。
続いて具体的な処理を書いていきたいと思うのですが、今回はbatch_handlerというメソッドに処理を書いていきます。まず日本時間で日付けを取得したいと思いますので、taimezoonの情報を一番最初に生成しています。
続いて今回使うSQLですが、このようになっています。発売日当日の書籍一覧と、それを予約しているユーザー、これをまとめて取得する内容となっています。このSQLをAPIの時と同様に実行してあげるというコードを書いています。
続いてSAMテンプレートのほうに今回のLambda関数の定義を書いていきます。今回名前はMailSenderFunctionという名前にしています。具体的な設定値なんですけれども、アプリが置いてあるディレクトリと実行対象のメソッド名ですね。そちらを変更しています。
さらにデータベースですね。AWSの環境のデータベースのエンドポイントを環境変数として指定しています。
ここまでできたら一度ビルドとローカル実行を試してみたいと思います。APIの時とは異なり、バッチ処理の場合はこういったsam local invoke、そのあとにLambda関数名ですね。こちらを記載いただくことでLambda関数をローカル実行することができます。
実際に実行してみた結果がこのようになります。今日収録した日が8月8日なんですけれども、このように8月8日発売の書籍のデータが取れているというのがわかるかと思います。
取得したデータをもとにメール本文を構成
ではこの取得できたデータをもとにメールの本文を構成していきたいと思います。まずメールの本文に書籍の名前、あとは価格、さらに発売日を代入していきます。冒頭で生成したSESにアクセスするためのクライアントを使ってメールの送信を行っていきます。
まずDestinationというパラメータのToAddressesという項目に、配列形式でメールの送信先を指定します。続いてMessageというパラメータにメールの本文と件名を指定します。まずは本文ですね。html形式で送る場合はこのような書き方になります。
さらにSubjectというところに今回のメールのタイトルを指定します。Souceというパラメータにはメールの送信元のアドレスを設定します。本来はここでメールがうまく送信できなかった時の例外などのハンドリングを追加するんですが、今回は割愛しています。
最後、うまくメールが送信できた際には払い出されるMassage IDですね、こちらを標準出力に出力するようにコードを書いています。ここまでできたら、もう一度ビルドとローカル実行を試してみたいと思います。
sam local invokeというコマンドで再度ローカル実行を行った結果がこちらになります。最後にMassage IDというかたちでIDが払い出されていることがわかるかと思いますが、こちらはあくまでモックですので、実際のメールは送られていません。メールを実際に送るにはAWSの環境へのデプロイが必要になります。
Lambda関数を呼び出すStep Functionsの作成
ではこのLambda関数を呼び出すStep Functionsを作っていきたいと思います。AWS Toolkitをご利用の場合だと、このようにCreate a new Step Functionsという選択肢があります。ここからHello worldのサンプルをもとに作っていきたいと思います。
Hello worldのサンプルを実際にレンダリングしてみると、このような流れになっています。ここから内容を一気に削ってしまって、単純にメールを送るというだけのStep Functionsの設定にしてみたいと思います。このようなかたちですね。
これだけではもちろんLambda関数は呼べませんので、ここから関数を実際に呼ぶための設定を入れていきます。まずTypeというキーにTaskと入れまして、続いてリソースというキーにarn:aws:states:::lambda:invokeという値を入れます。このあたりはすべて補完が効くかたちになっているので、選択肢の中からお選びいただけます。
最後にParametersの中にFunctionNameというかたちで呼び出すLambda関数の名前を書きます。FunctionNameの値なんですけれども、${MailSnderFunctionName}というかたちでプレースホルダになっています。こちらはあとでSAMテンプレートのほうから実際の値を代入していきます。
今回Lambda関数の前にコンテナを実行するという要件があったかと思いますので、コンテナ実行の設定も入れていきます。設定の名前は任意で大丈夫なんですが、今回はRun Containerという名前にしています。
続いてコンテナ実行のあとに実行する内容ですね。先ほど定義したSend Emailsという設定にしておきます。次に実行する内容を書くのですが、Typeは先ほどのLambda関数と同一にTaskですね。Resourceには実行内容を書くんですけれども、今回はecs:runTask.syncというコンテナ実行をするというものを選択しています。
次にParametersにコンテナを実行するための詳細設定をしていくんですけれども、この詳細に関しては今回は割愛いたします。ECSのクラスタですとか、タスク定義などをここで指定するかたちですね。これでStep Functionsとしての設定は完了となります。
あとはこの設定ファイル名をasl.jaonという名前に変更してあげています。このasl.jasonという今作った設定ファイルを読み込むようにDefinitionUriというパラメータで設定しているかたちですね。
続いて先ほどのStep Functionsの設定の中でプレースホルダとしていた部分ですね。このMailSnderFunctionNameという箇所なんですけれども、具体的な値はこのSAMテンプレートのDefinitionSubstitutionsという中に設定していきます。
値としてRef MailSnderFunctionという値を設定していますが、こちらは先ほど定義したLambda関数の名前と一致させることで関数の参照が可能になります。
続いてこのStep Functionsをどういったトリガーで実行するかという設定をしていきます。今回は毎日午前0時に実行したいと思いますので、TypeをScheduleとしています。さらに具体的な実行タイミングをScheduleというプロパティにcron式で書くんですけれども。ここをUTCで指定が必要ですので、マイナス9時間した15時で指定しています。
最後にStep Functionsで使うIAMロールの設定をして、Step Functionsの設定は完了です。全体を見やすくするために不要なリソースですとか、雛形の作成の時に生成された今回は使わないリソースはこのように削除してしまいます。
メール受信を確認できればプロトタイプ開発は完了
次にLambda関数で使うIAMポリシー、権限の設定をするのですが、APIの時と同様にSecrets Managerの権限も必要ですが、それに加えてSESというメールを送信するサービスの権限も加えています。許可するメールの送信元アドレスの値をこのようにproduction@example.comと設定しているんですが、こちらはソースコードの中で設定した値と同様のものを設定しています。
ここまでできましたらあとはAPIの時と同様に配置するVPCの設定ですとか、不要なリソースの削除を行いまして、sam buildコマンドでアプリケーションをビルドします。sam deploy--guidedというオプションを付けてAWSの環境に実際にデプロイしていきます。リージョン名ですとか、選択する項目はまったくAPIの値と同様です。
しばらく待つとデプロイ予定のリソース一覧が表示されますので、y、イエスを押して実際にAWS環境へのデプロイを行います。どのようなリソースがデプロイされているかというイベントの一覧がこのように時系列で表示されていきますので、デプロイが完了すると最後にSuccessfuly createdというような表示が行われます。
AWSのStep Functionsのコンソールに入りますと、このようにリソースが作られているということがわかりますので、今回はスケジュールでの実行ではなく手動で実行してみたいと思います。すると実行ステータスがこのように実行中というかたちに変わりまして、しばらく経つと、成功というかたちで記録されます。
スクロールするとこのようにそれぞれのタスクの実行状態ですとか、実行ごとのどのようなログが記録されたかというデータも見ることができます。
実際に届いたメールがこちらになります。このように件名と本文が入った状態で新刊の予約通知を無事受け取ることができました。以上でプロトタイプ開発は完了となります。お疲れ様でした。
サーバーレスの開発をもっと学ぶための参考資料
ここまでサーバーレスの開発を体感してみていかがでしたでしょうか？ 最後により知識を深めたい方向けに参考資料をご紹介させていただきます。これらはどれもインターネットで検索いただければ内容を確認いただけるかと思います。
まず1つ目が『AWS Hands-on for Beginners Serverless』というコンテンツです。こちらはサーバーレスなシステムを自分自身で作る入門者向けのハンズオンとなっておりまして、今回ご紹介いたしましたSAMも開設動画の中に含まれております。
2つ目にご紹介するのが『CI/CD For Serverless Applications』というコンテンツになります。こちらもSAMを利用した開発、およびCI/CDのためのパイプラインを整備するためのハンズオンが含まれております。コンテンツの内容としては英語のみとなりますのでご注意ください。
最後にご紹介するのが『AWS Black Belt Online Seminar（AWS SAM）』の回になります。こちらではSAMの文法など細かい仕様を動画、およびスライドにて解説をしておりますので、ぜひご視聴いただければと思います。
セッションの内容は以上となります。最後までご視聴いただきありがとうございました。