BETA

SQSでLambdaを蹴るときは気をつけましょうというお話

投稿日:2019-08-12
最終更新:2019-08-12

書きなぐる

結論

SQSを使うときは、

  • 冪等性を担保する
  • Dead Letter Queueを使う or ECSからのポーリングにする

背景

AWSでは、Simple Queue Service(SQS)へのキューイングをトリガーとしてLamdbaの関数を実行することができる。
通常通り使えていれば問題がないのだが、仮にエラーハンドリングをミスっていたり異常に処理に時間がかかってしまったりすると大変。

そもそもの大前提として、冪等性が担保されていないと事故ったときの影響範囲が大きい。
例えばメール送信をSNS経由でSQSに格納し、Lambdaを起動させて送る、という構成にしていた場合に事故るとメールが何度も送られうる。

対策としては、下記の通り。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/retries-on-errors.html

呼び出しが失敗、またはタイムアウトした場合、バッチのメッセージはすべてキューに返り、可視性タイムアウト期間が過ぎると処理に使用できるようになります。

上記にもある通り、実行に失敗したあとは処理が再試行される。
再実行して治る問題であれば良いのだけれど、バグってたり想定外のデータサイズが来てしまうなどでエラーが再現し続ける場合は何度でも関数が実行される。

Dead Letter Queueの設定以下にある、再処理ポリシーの使用にチェックを入れると設定ができる。
ただし、マネージメントコンソール上でメッセージを確認したりすると消費されるので注意。

あるいは、リアルタイム性がそこまで必要ないのであれば、ECS上からCronでQueueへ読みに行く実装をしてしまった方が安全かもしれない。
特に再実行性という点に関して扱いやすい。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@anizozinaの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!