[小ネタ]SQSとKinesis Data Streamsを使う際はエラー時のリトライ回数に注意しよう

はじめに

CX事業本部の佐藤智樹です。

今回はSQSとKinesis Data Streamsを使う際にそれぞれエラー時のリトライ回数かどれぐらいになるのか注意して設定しようという話です。 大した話ではないですが、初めて使う時に適当な設定で作ると余計なリソース消費=思わぬ費用請求や処理が詰まる可能性があります。自分はIaCでさっと設定する際に忘れてしまうことがあったので備忘録として残します。

対象となる読者は、SQSやKinesis Data Streamsを使う方です。これから使う方も既に使っている方も改めてさらっと確認すると助かるかもしれないです。

結論

SQSはメッセージ保持期間、Kinesis Data Streamsはデータ保持期間に気をつけよう。

言葉の整理

記事のタイトルとしては、感覚的に分かりやすくするために「リトライ回数」という言葉を使いましたがSQS、Kinesis Data Streamsそれぞれの個別の名前の設定値によってリトライ回数が変わります。本章以降は以下の名前を使用します。

SQSの場合

SQSはメッセージ保持期間の間データを保持し続けます。デフォルトでは4日間で、60秒から14日間まで設定できます。詳細は公式資料をご確認ください。これにより、Lambdaなどをイベント配信先に設定してエラーになった場合、可視性タイムアウトなどに応じて一定期間後自動でリトライ処理が走ります。

ここで問題なのが、SQSをLambdaと繋いでLambdaがエラーになるコードを上げて放置してしまった場合などです。エラーとなった処理は再実行されるため、4日間ずっとLambdaがリトライされます。Lambdaは無料の実行時間枠もありますが、時間のかかる処理の途中で転けている場合思いの外実行時間を消費する可能性があります。

初めてSQSを利用する際はメッセージ保持期間を小さめに設定した後、要件に応じて時間を伸ばしたりDLQに飛ばす設定を行うことをおすすめします。

Kinesis Data Streamsの場合

Kinesis Data Streamsは基本データ保持期間の間データを保持し続けます。デフォルトでは、コンソールから設定した場合データ保持期間が24時間になります。

こちらもSQSと同様にエラーが発生した場合、データ保持期間分繰り返しが発生するので最大24時間繰り返しになります。こちらはコンソールの場合Lambda側にエラー時の設定があるので適切にバッチ分割や再試行、障害時の送信先を設定しましょう。

(余談：Lambdaなどでポーリングする際、エラー時に再試行で何回繰り返すのか、レコード最長有効期間でいつまで繰り返すのか設定もできます。デフォルトでは両方「-1」でデータ保持期間を優先するようになっています。 以下のリンクのMaximumRecordAgeInSeconds、MaximumRetryAttempts部分より)

AWS::Lambda::EventSourceMapping - AWS CloudFormation

感想

久々にSQSをAWS CDKから設定したところ、デフォルトの4日間繰り返しになっていたため記事にしました。少し前にKinesis Data StreamをAWS CDKで設定したときは、データ保持期間が7日間になっていてエラーを放置すると恐ろしく繰り返される設定になっていたのですが最近は改善されているみたいです。

SQS、Kinesis Data Streamsの設定に少しでも役立てば幸いです。

参考資料