はじめに

非同期処理って難しいですよね。
私の開発現場では Shoryuken gem (Ruby) を使って、Amazon SQS を用いた非同期処理を実現しています。

本記事では Amazon SQS 世間一般でのよくある仕組みを解説してみようと思います。

よくある SQS を使った非同期処理

下図の様な、AWS 上に構築された Web アプリケーション (シングルページアプリケーション) を想定します。

以降、Amazon SQS の説明では上記サーバーをそれぞれ以下の様に表記します。

Amazon SQS を利用する際は AWS SDK や Ruby アプリケーションの場合は Shoryuken の様なライブラリを用いる事が多いと思います。

基本的に次の３つの操作が主になります。

Client は非同期処理を Worker に依頼する為に、Amazon SQS にメッセージを投入します。

一般的に Amazon SQS を FIFO で構築した場合は、次に投入するメッセージは後ろに積まれます。
つまり 先に投入されたメッセージから順に処理 されます。

Worker は FIFO の場合は最も古い (先に入れた) メッセージを受信します。

この時、Amazon SQS では可視性タイムアウトという仕組みがあり、受信したメッセージは (Default では30秒間) 見えなくなります。

下図では、別の Worker (2) が Amazon SQS からメッセージを受信していますが、 message 1 は見えない為、message 2 が受信されます。

一見すると 「メッセージ受信する際に削除してくれればいいじゃん！」 と思うのですが、その理由は後述する「リトライ」にあります。

無事 Worker (1) は、非同期処理を終えました。

その際に Worker は必ず 受信したメッセージを削除 しなければいけません。

その理由は...

前述の通り、Amazon SQS には可視性タイムアウトという仕組みがあり、メッセージが削除されずに一定時間が立つと、また見える様になります。

例えば下図の例では、Worker (1) は message 1 を受信した筈ですが、 処理中 (プログラムコード) に例外が発生して完了しなかった と想定しましょう。

処理に失敗した場合は、メッセージを削除してはいけません。

この場合は可視性タイムアウトにより、メッセージがまた見える様になる事で Worker が再度メッセージを受信してくれる為、結果的に 処理のリトライ が行われる事になります。

コード中で try-catch してリトライ、等はすべきではありません。
コード上でのリトライは、そのサーバーがフリーズした場合等に実施が保証されない為です。

ここで一つ可視性タイムアウトのよくある注意点があります。

タイムアウト時間が、想定する処理にかかる時間 (※最大時間) より小さい場合、まだ処理が終わっていないのに、別の Worker によるリトライが発生 してしまいます！

一般的に Amazon SQS では、アプリケーションの非同期処理の最大時間を計測し、それを超える可視性タイムアウトを設定する運用が望ましいです。

ただし、処理時間がどの位になるか想定できないケースも多々あるかと思います。
その場合は、受信したメッセージの可視性タイムアウトを延長 (※正確にはリセット) する方法もあります。

ハートビートという機能を使うと、まだ処理中のメッセージの可視性タイムアウトを延長できます。
Shoryuken 等では auto_visibility_timeout という Worker option もあります。