![[アップデート] AWS SAM CLIでのテストイベントアップロード時にLambda関数の呼び出しタイプを保存できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-07eaebd66be96825f09534c76d05964b/7c8c45cd92c42f6391edbb4b7133429b/aws-sam.png?w=3840&fm=webp)
[アップデート] AWS SAM CLIでのテストイベントアップロード時にLambda関数の呼び出しタイプを保存できるようになりました
はじめに
2週間ほど前ですがAWS SAM CLI v1.146.0がリリースされました。
AWS SAM CLIではsam remote test-eventを用いることでリモート上(実際のAWS環境上)のテストイベントに対して各種操作ができます。
今回のアップデートにはこのテストイベントのアップロード(sam remote test-event put)に更新が入り、テスト実行時にデフォルトで利用される起動タイプが保存できるようになりました。
起動タイプ自体は元々sam remote invoke実行の際に都度パラメータで引き渡すことで対応できたり、マネジメントコンソールでもしばらく前から設定できたのですが、SAM経由でイベントのデフォルトを指定できるようになったことにより利便性が向上しました。
マネジメントコンソールの設定としてはこの部分になります。
(調べてみると起動タイプの指定は機能としては以前からあったようですがマネジメントコンソールへの追加は比較的最近な気がします)
Lambda関数の起動タイプ
既存機能のため今回は概要レベルでの解説となりますが、Lambda関数にはいくつか起動タイプがあります（同期・非同期・ストリーム・ドライラン、ここでは同期・非同期のみについて触れます）。
- 同期タイプ(RequestResponse)
- AWS Lambda直接実行やAPI Gateway経由でのデフォルトの挙動
- 関数の実行完了まで待ち、その結果を呼び出し元に返す(完了まで待機する)
- 実行失敗時はユーザ側にレスポンスが返るのでそれを用いてユーザ側でリトライ等の制御を入れる
- 非同期タイプ(Event)
- Amazon S3のイベントを起点として呼び出される場合の挙動
- 呼び出し元には実行が成功した時点でレスポンスが返り、その後裏で非同期で実行される
- 処理に失敗した場合所定の回数自動でリトライされる
- リトライ回数超過後の失敗処理が必要な場合はEventBridge等を利用して拾い上げる必要がある
改めて言葉にすると少し難しいですが、ざっくりユーザがインターフェースとなり呼び出しをし、レスポンスを確認するようなタイプが前者、イベント駆動で呼び出しがチェーンしていくようなケースは非同期タイプが利用されているとイメージしておくのが良いかなと思っています。
なおLambda関数直接呼び出しが「同期」なのはあくまでデフォルトで実行時に指定することで変更が可能です。
そのためS3からイベントが渡ってくるようなケースをより実際に近い形でテストしたい場合は非同期タイプでテスト実行をする形になります。
使ってみる
起動タイプはイベント保存に利用する際に使うsam remote test-event putの際にオプションとしてinvocation-typeを指定することでアップロードすることが可能となります。イベントデータの本体(JSON)に含ませるわけではないのでご注意ください。
## 非同期
% sam remote test-event put --name async-test --file events/event.json --invocation-type Event
## 同期
% sam remote test-event put --name async-test --file events/event.json --invocation-type RequestResponse
イベントのデータではないならどこで持つのか、というところですが実態としてはEventBridgeのスキーマ情報のメタデータとなります。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/testing-functions.html#creating-shareable-events
Lambda は、共有可能なテストイベントをスキーマとして lambda-testevent-schemas という名前の Amazon EventBridge (CloudWatch Events) スキーマレジストリに保存します。Lambda はこのレジストリを使用して、作成した共有可能なテストイベントを保存したり呼び出したりするので
Lambda関数の共有されているテストデータはEventBridgeのスキーマ情報として持つ仕様となっています。
https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-schema.html
EventBridge は、OpenAPI 3 と JSONSchema Draft4 の両方のフォーマットをサポートしています。
フォーマットとしては上記２種類が現時点ではサポートされています。
例えば以下のようなイベントをアップロードしてみると
% cat events/hello-event.json
{
"message": "Hello world"
}
% sam remote test-event put --name async-hello --file events/hello-event.json --invocation-type Event
Put remote event 'async-hello' completed successfully
こんな感じのスキーマ情報が作成されます。テストデータの本体に加えて各種メタデータを持つ形になります。
{
"openapi": "3.0.0",
"info": {
"version": "1.0.0",
"title": "Event"
},
"paths": {},
"components": {
"schemas": {
"Event": {
"type": "object",
"required": ["message"],
"properties": {
"message": {
"type": "string"
}
}
}
},
"examples": {
"async-hello": {
"value": {
"message": "Hello world"
},
"x-metadata": {
"invocationType": "Event"
}
}
}
}
}
--invocation-type Eventで指定した値はメタデータとしてexamples内のx-metadataにマッピングされます。
なおスキーマに保存されている情報はあくまでデフォルトの値であり、sam remote invokeで実行する場合にInvocationTypeを指定することにより実行時に別途上書き可能です。
## Eventの場合は非同期なのでレスポンスがない
% sam remote invoke --test-event-name async-hello
Invoking Lambda Function HelloWorldFunction
## 同期指定で実行
% sam remote invoke --test-event-name async-hello --parameter InvocationType='RequestResponse'
Invoking Lambda Function HelloWorldFunction
START RequestId: 86c1be2f-a66a-40c8-821a-515a7c9a6222 Version: $LATEST
END RequestId: 86c1be2f-a66a-40c8-821a-515a7c9a6222
REPORT RequestId: 86c1be2f-a66a-40c8-821a-515a7c9a6222 Duration: 2.37 ms Billed Duration: 104 ms Memory Size: 256 MB Max Memory Used: 35 MB Init Duration: 101.49 ms
{"statusCode": 200, "body": {"message": "Hello world"}}%
終わりに
新しく追加されたAWS SAM CLIでのテストイベントへの起動タイプの設定を試しました。
前述の通りsam remote invoke側のparameterの指定でも対応できるため、今回のアップデート前でもsamconfigに書き込むことで実質的にデフォルト値の指定自体はできました。
ただ全員がその設定ファイルを持つ必要がある、あくまでSAM CLIの世界の話なのでマネジメントコンソールで作業する人も混ざると対応しきれなかったのがカバーされる形になるので運用次第では助かるアップデートではないでしょうか。
