🖥
AWS SQS の可視性タイムアウトとは？何故そんなものがあるのだろうか？ を少しだけ考えてみる。( #AWS )
可視性タイムアウトがなかったらどうなるか。
- AWS がキューからWorkerにメッセージを渡した瞬間に、メッセージを物理削除してしまったら、ジョブ処理が失敗した時に、復帰できないだろう。なぜなら物理削除されているので。
- AWS がキューからWorkerにメッセージ渡した後mお、メッセージを残したままだと、他のWorkerや他のプロセスが、処理が成功する前、あるいは失敗する前に、同じメッセージを受け取ってしまうかもしれない。これでは重複処理が起こるのではないだろうか。
- つまり、AWSはメッセージを一定時間論理削除して、ロックしておき、他のプロセスからは見えない状態にしておいて、重複処理されないように守っておく必要がある。これが可視性タイムアウトという分かりにくい名前じゃないだろうか。あーもう単にメッセージロックとかでも良いのでは？
- すなわち、たとえば1分かかる処理がある場合、可視性タイムアウトを30秒にしてしまうと、処理が成功する前にロックが外れ、他のプロセスがメッセージを処理してしまう可能性がある。なので可視性タイムアウトの設定は、処理にかかるであろう時間よりも長めに設定しておく必要がある。
- AWS SQSが一定期間、メッセージを論理削除して、まるで物理削除されているかのように扱う振る舞いが可視性タイムアウトの仕組みではないか。
- Workerは処理が成功したタイミングや処理を諦めたタイミングで、AWS SQSにメッセージを送信して、メッセージ自体を削除する必要がある。これにも可視性タイムアウトの仕組みが関係している気がするが、うまく言語化できるまでは至っていない。
参考
引用の通りですが、SQS には可視性タイムアウトという設定値があって、Shoryuken の worker が SQS から>メッセージを受け取ると、SQS 側はメッセージを一定時間、論理削除します。
worker はジョブが完了すると SQS 側にメッセージの削除要求を投げて、論理削除されていたメッセージを物理削除します。
もし、 worker 側で処理に失敗、または可視性タイムアウトの設定時間を経過しても処理が終わらなかった場合、SQS 側で論理削除を解除して、次のリクエストでメッセージを再配信します。
この仕組みがあるため、 Shoryuken 側でリトライを設定していなくとも、失敗した処理は再度実行されるようになります。
万が一 worker のプロセスが死んでしまっても、 SQS 上でメッセージはちゃんと生きている訳です。
Shoryuken を導入しようとして諦めた話 - Qiita
Original by Github issue
チャットメンバー募集
何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。
公開日時
2019-10-20
Discussion