はじめに
イベントソースに SQS を指定した場合、LambdaFunction は同期的に呼び出される。
S3 をイベントソースに指定した場合（非同期な呼び出し）と振る舞いが異なる。
キューの例外処理を設計するにあたって考慮すべきポイントを整理した。
1. 非同期呼び出しになるイベントソースの場合(S3, SESなど)
- リトライなど、失敗時の動作は Lambda Function 側でコントロールする
1.1 失敗時の動作
リトライ
- デフォルトで 2 回リトライされる
失敗の検知、処理
- すべてのリトライで失敗した場合、 Lambda Function に指定した DeadLetterQueue に通知される
1.2 計画的な停止時のふるまい
- イベントソースマッピングを無効化
- 無効化している間に発生したイベントは失われる(イベントソースマッピングを再度有効化しても処理されない)
- Lambda Function を Throttling
- 2回リトライし、失敗した場合はイベントが DeadLetterQueue に送られる
2. 同期呼び出しになるイベントソース (SQS)
- リトライなど、失敗時の動作は イベントソース（SQS）側でコントロールする
2.1 失敗時の動作
If you configure an Amazon SQS queue as an event source, AWS Lambda will poll a batch of records in the queue and invoke your Lambda function. If the invocation fails or times out, every message in the batch will be returned to the queue, and each will be available for processing once the Visibility Timeout period expires.
- すべての処理中のバッチはキューに戻される
- 戻されたメッセージは可視性タイムアウトが期限切れになると再処理可能になる
リトライ
- メッセージの再処理に関するSQSのパラメータ
- 可視性タイムアウト: 0-12 h (default: 30 sec)
- 他のプログラムが同一のメッセージを処理するのを保留する時間
- 最大受信数: 1-1000
- デッドレターキューに送信されるまでにメッセージを受信できる最大回数
- 保持期間: 1 min - 14 days (default: 4 days)
- 処理しない状態のメッセージがキューに保持される最大期間
- 可視性タイムアウト: 0-12 h (default: 30 sec)
失敗の検知、処理
- SQS側で指定した DeadLetterQueue に入る
2.2 計画的な停止時のふるまい
- イベントソースマッピングを無効化
- メッセージが削除される条件が満たされるまでキューに残る
- Lambda Function を Throttling
- メッセージが削除される条件が満たされるまでキューに残る