はじめに
非同期処理って難しいですよね。
私の開発現場では Shoryuken gem (Ruby) を使って、Amazon SQS を用いた非同期処理を実現しています。
本記事では Amazon SQS 世間一般でのよくある仕組みを解説してみようと思います。
よくある SQS を使った非同期処理
下図の様な、AWS 上に構築された Web アプリケーション (シングルページアプリケーション) を想定します。
- ユーザーがブラウザで操作 (時間のかかる機能の実行指示) をする
- Web サーバーは Amazon SQS にメッセージを投下し、(重い処理はここではせずに) 即座にレスポンスを返す
- Worker サーバーは Amazon SQS 上のメッセージを受信し、処理を開始する
以降、Amazon SQS の説明では上記サーバーをそれぞれ以下の様に表記します。
- Web サーバー →
Client - Worker サーバー →
Worker
Amazon SQS
Amazon SQS を利用する際は AWS SDK や Ruby アプリケーションの場合は Shoryuken の様なライブラリを用いる事が多いと思います。
基本的に次の３つの操作が主になります。
- メッセージを投入する
- メッセージを受信する
- メッセージを削除する
キューにメッセージを投入
Client は非同期処理を Worker に依頼する為に、Amazon SQS にメッセージを投入します。
一般的に Amazon SQS を FIFO で構築した場合は、次に投入するメッセージは後ろに積まれます。
つまり 先に投入されたメッセージから順に処理 されます。
Worker サーバーがメッセージを受け取る
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 によるリトライが発生 してしまいます！
タイムアウトの延長 (Heartbeat)
一般的に Amazon SQS では、アプリケーションの非同期処理の最大時間を計測し、それを超える 可視性タイムアウト を設定する運用が望ましいです。
ただし、処理時間がどの位になるか想定できないケースも多々あるかと思います。
その場合は、受信したメッセージの 可視性タイムアウト を延長 (※正確にはリセット) する方法もあります。
ハートビートという機能を使うと、まだ処理中のメッセージの 可視性タイムアウト を延長できます。
Shoryuken 等では auto_visibility_timeout という Worker option もあります。
