SQSについて

SQSについて

投稿日：2019年1月2日更新日：2019年6月9日

以前、少しQueueの登録について書きましたが、今回はAWSのキューサービスであるSQSについて。

以前のリンク

Queueの登録と実際の処理に関して

SQSのポイントについて簡単にまとめて置きたいことなど。

Contents

Queueとは?

以前のリンクでも書きましたが、ある処理をあらかじめ登録しておき、処理自体はまた別の機会に行うようなケースです。

一般的には非同期的な処理をしたいとき(具体的には時間のかかる処理や分散する必要のある処理をしたいケース)が多いと思われます。DBがらみのでデータを大量に登録するとか、ネットワークがらみなどですかね・・・スクレイピングアプリとか作ったら色々使えるケースが多そうです。

昔、倉庫管理アプリを作っていた時にこの話題によくなりましたね。倉庫管理アプリでは引き当てという処理が必要になるケースが多いのですが、結構時間のかかる処理でユーザーはこれが終わるまで画面の前で待ってなければいけなかったりします。

それをキューに登録しておき、夜間に実行するようにすれば、いちいち待たなくていいというような話題が当時出ていました。結局実現しませんでしたが・・

自分が実行したのは以下のケースです。

エンドポイントにSQSのarnを書いておき、SNS→SQSと連携させる方法です。

メジャーな言語であればAPIが実装されていますので、プログラムの中でこれを書く方法もあります。

ちなみにテストで実行する場合は、AWSのshellが一番便利かと思います。(下記参照)

どの方法でも後述するアクセス制限が必要になってきます。

AWSではQueueの処理に関して権限があります。

画面側で設定することになりますが、権限を解放していないとQueueの処理が適切にできません。「アクセス許可」というタブで適切に設定しましょう。

メッセージのチェック自体のことをポーリングというようです。

ポーリングの時間が長いか短いかの違い。一般的にはロングポーリングの方がメリットが大きいため、ロングポーリングが推奨される。

要するに登録された順番と実行する順番を守るタイプです。順番を守る代わりにややスピードは落ちるようです。

登録された順番と実行される順番を必ずしも保障しないパターンです。行列に並んだ順番と処理される順番が必ずしも一致しないのと似ています。

排他制御の時間です。要はあるキューが実行中にこの時間が短いと二重に処理をしてしまう可能性があります。処理がどのくらいで終わるかを考えましょう。SQSの場合、設定時間は１秒から12時間まであるようです。

実務でハマりました・・・あるキューが正常に終わった時のみ、キューの削除をするようにしたんですが、そうするとエラー起こしたキューは、

となってしまうんですよね・・・

この場合、一度削除して別の処理をするか、デッドレターキューという別のキューにする仕組みが必要のようです。