どうもこんにちはtacomsの @yo sano です。
弊社では以下のようなLambdaからSQSにメッセージを送信してLambdaが処理していく構成がいくつかあります。今回はこの構成の一部で発生した事象について書いていければと思います。
何が発生していたか
SQSのメトリクスである「NumberOfMessagesReceived」およびLambda(consumer側)の「Invocations」の数がどうも期待通りになっていませんでした。バッチサイズが1の場合、「NumberOfMessagesReceived」「Invocations」それぞれのメトリクスが同じになる想定でした。しかし「NumberOfMessagesReceived」「Invocations」のメトリクスが期待の半分程度にしかなっていませんでした。またメッセージ送信側のLambdaのメトリクスやログは全く問題なかったです。
何が原因だったか
結論を書いてしまうと、Lamndaのエラー数が原因でした。
メッセージを受け取るLambdaをモニタリングしていると、エラー数がそこそこありました。今回はその部分を解決することで上記メトリクスも期待通りの挙動になりました。
If your function code caused the error, Lambda will stop processing and retrying the invocation. In the meantime, Lambda gradually backs off, reducing the amount of concurrency allocated to your Amazon SQS event source mapping。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-sqs.html#services-sqs-backoff-strategy より引用
どうエラー数を減らしたか
一般的に2つ手段があります。
1. ReportBatchItemFailuresを導入する
複数のメッセージを処理している場合に、一部が失敗したとしても該当のメッセージだけを返せば良いと言う機能になります。この機能の概要および実装方法については多くの記事があると思いますので、そちらを参考にしていただければと思います。個人的には以下の記事などが参考になりました。
2. アプリケーションの実装を見直し、修正する
アプリケーションのエラーハンドリングなどが該当するかと思います。
最後に
ちゃんとドキュメント読もう！！
Discussion