今更AWS SQSについてのメモ [調査]
はじめに
この記事は、私が会社で SQS を導入する際に学んだことをアウトプットする目的で記載しています。
対象読者は、SQS を使ったことがなく、タスクを非同期で処理したい人です。
SQS [1]の概要
SQS とは
Amazon Simple Queue Service（SQS）は、AWS のメッセージキューサービスです。
フルマネージドのためサーバーの構築や運用を気にする必要がなく、特に AWS Lambda
と連携させることで運用負荷を削減でき、急な負荷にも柔軟に対応できるなどスケーラビリティが高いです。
Amazon MQ との違い
AWS では他に 「Amazon MQ」もありますが、2024 年 12 月時点で、新規に AWS でキューイングサービスを利用するなら「SQS」、既存のもの(IBM MQ など)から移行するなら「Amazon MQ」をお勧めしているようです。[2]
私は、前職では、Redis と Python の Celery を ec2 を立てて使っていました。SQS を使ってみるとほんとに管理が楽です。
用語など
- パブリッシャー(プロデューサーともいう)
- キューにデータを送信する側
- サブスクライバー(コンシューマーともいう)
- キューからデータを受信する側
- メッセージ
- キューに送信されるデータのこと
- enqueue
- キューにデータを送信すること
- dequeue
- キューからデータを受信すること(キューからデータを削除すること)
※厳密には、サブスクライバーがポーリングしたり、キューを削除または再度実行するなどの処理が入りますが、この図は単純化しています。
ユースケース
SQS のユースケースとしては、以下のようなものがあります。
- 非同期タスク
- 非同期にタスクを実行し、レスポンスを早めに返す
- 分散システムの疎結合化
- タスクごとに処理を分けることができる。
- スケール
- タスクごとに処理を分けると、スケールがしやすくなる
今回は、非同期タスクを実行するために SQS を使いました。
大規模なシステムになってくるとスケールやシステムの疎結合が重要になってくると思います。
QUEUE について
queue は、順番待ちやデータの持ち方のことで、FIFO(First In First Out)という特性を持っています。
お店の行列などをイメージするとわかりやすいです。前の人から先に食べる、という感じです。
SQS には、標準キューと FIFO キューがあります。違いとしては以下のようになっています。
- 標準
- メッセージが少なくとも一度は配信されることが保証。複数回実行されることもある。
- メッセージは、基本的には先に入れたものから実行されるが、保証はされない。
- FIFO
- 1 回だけの配信
- メッセージは、先に入れたものから実行される。順序が保障される。
料金は FIFO の方が高いですが、順序が保証されるので、順序が重要な場合は FIFO を使うと良いです。
stack
queue と似たような概念に、stack があります。stack は LIFO(Last In First Out)という特性を持っています。
ブラウザの戻るや、PC で文章を作成している時に戻るなど、最後に入れたものから先に取り出される、という感じです。
SQS の機能
可視性タイムアウト[3]
SQS には、可視性タイムアウトという機能があります。
可視性タイムアウトは、サブスクライバーがメッセージを受信してから、そのメッセージが他のサブスクライバーに見えないようにする時間のことです。
メッセージを消すまでのタイムリミットとも言えます。
この時間を過ぎてもメッセージが処理されない場合、他のサブスクライバーがそのメッセージを受信できるようになります。
FIFO キューでは、メッセージの実行順序を担保するため、
可視性タイムアウトの期限が切れるか、削除されるまで、次のキューは実行されません。
そのため、可視性タイムアウトの時間を長くすると、何か不具合が起きた時に次のキューが実行されるまでの時間が長くなる可能性があります。
配信遅延[4]
コンシューマーの処理が詰まっている時などに、メッセージを受信するまでの時間を遅らせることができます。
例えば、メッセージを送信してから 1 分後に処理を開始するように設定することができます。
FIFO キューの場合は、キュー全体に影響があります。
デッドレターキュー[5]
処理に失敗した時に、メッセージを別のキューに移動させることができます。
デッドレターキューはその失敗したメッセージを保存しておくためのキューです。そのため、デッドレターキューにメッセージが移動されると、元のキューからは削除します。
メッセージ保持期間[6]
SQS は、エンキューの時間からメッセージ保持期間を過ぎたメッセージを自動で削除します。
もし、メッセージがエラーになり、デッドレターキューに移動させたとしても、
デッドレターキューの保持期間が元のキューの保持期間より短い場合、エンキューからの保持期間が過ぎると、デッドレターキューから削除されてしまいます。
そのため、AWS は常にデッドレターキューの保持期間が元のキューの保持期間より長くなるように設定することをお勧めしています。
メッセージ受信待機時間[7]
サブスクライバーは、メッセージを受信する際に、ポーリングを行います。
メッセージ受信待機時間は、サブスクライバーの処理が空になり、メッセージを受信するまでのポーリングの間隔のことです。
この時間ごとにポーリングを行い、メッセージがあれば受信します。そのため、この時間が短いほど、メッセージを早く受信できますが、リクエストが増えるため、コストがかかります。今回私の要件では、非同期で処理が可能で、リアルタイム性も求められていなかったため、受信待機時間は 20 秒に設定しました。
終わりに
ここまで、SQS について調査しました。
次の記事で実際の運用やコードなどについて書いていきます。
Discussion