SQSでLambdaをトリガーする際の挙動
SQSでLambdaをトリガーする際の挙動について理解が曖昧だったので改めて調べてみました。
イベントソースマッピング
SQSでLambda関数をトリガーする場合、イベントソースマッピングというLambdaの機能が使用されます。
イベントソースマッピングは、ストリームやキューからデータを受け取りバッチで処理するLambdaの機能です。SQSでLambda関数をトリガーする際にはこの機能を経由します。他にもKinesis、DynamoDBでトリガーする際に使用されます。
- Lambda側からポーリングでデータを取得
- 複数のデータをバッチでまとめて効率的に処理
- 実行失敗時のデータに対する処理が組み込まれている（SQSならdead letter queue、DynamoDBならon-failure destination）
参考:
SQSでLambda関数をトリガーする際の挙動
- LambdaはSQSをポーリングして、バッチとして同時に複数件のメッセージを受信します
- 1バッチに対して一回のLambda関数が実行されます
- 受信されたメッセージは一時的に非表示になり、他のリソースから処理できなくなります
- 処理が成功した場合、メッセージは削除されます
参考: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
補足：イベントソースマッピングなしで直接トリガーする場合の特徴
API Gateway、S3、AWS IoTなどから直接Lambda関数をトリガーした場合の特徴：
- 1イベントに対して1回のLambda関数の実行
- ポーリングを待たずに、イベント発生直後に関数を実行できるのでリアルタイムな処理に向いている
- 実行失敗時のデータの処理は自前で実装する必要がある
参考: https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html
補足：Lambda関数の同期呼び出しと非同期呼び出し
Lambda関数の呼び出しは同期呼び出しと非同期呼び出しに分類されます。
- 同期呼び出し: 呼び出し元が実行完了まで待機。エラー時は呼び出し元にエラーレスポンスが返される（API Gateway、ALB、Amazon Cognitoなど）
- 非同期呼び出し: 呼び出し元は実行完了を待たない。Lambda側でエラーが発生した場合は自動的に複数回リトライされる（S3、SNS、EventBridgeなど）
With Amazon SQS event source mappings, Lambda polls the queue and invokes your function synchronously with an event.
SQSの場合はイベントソースマッピング内で同期的にLambdaを呼び出してエラーハンドリングをしているそうです。
参考:
SQSでLambda関数をトリガーする際のエラー時の動作
Lambda関数でエラーが発生した際の動作は以下のようになります。
- Lambda関数がエラーで終了した際はメッセージは削除されずに残ります
- 可視性タイムアウトの時間が経過して再表示された際にメッセージは再度実行可能になり、再度ポーリングで取得された時にリトライされます。
参考: https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-errorhandling.html
デッドレターキュー（DLQ）
デッドレターキューが設定されている場合、設定した回数以上リトライされたメッセージは指定されたキューに移動されます（デフォルトは10回）。
デッドレターキューの利点：
- 問題のあるメッセージが繰り返し処理されてシステムのパフォーマンスを下げることを防ぐ
- 問題のあるメッセージを分離することでデバッグや監視をしやすくする
おわりに
今回はSQSでLambda関数をトリガーする際の挙動について調べてました。
- SQSとLambdaの連携においてイベントソースマッピングという仕組みによって、メッセージがバッチで処理される
- 処理に失敗したメッセージは自動的にリトライされ、デッドレターキューを活用することで問題のあるメッセージを適切に処理できる仕組みになっている
これらの特徴を加味した上で設計していきたいです。
Discussion