先に結論
SQS は、処理をその場で直結させず、いったんメッセージとしてためて後ろで処理するための AWS のキューサービスです。
正式には Amazon Simple Queue Service といいます。
初心者向けにかなりざっくり言うと、今すぐ返したい処理 と あとでやればよい処理 を切り分けるための箱です。
たとえば、
- 会員登録のあとに確認メールを送りたい
- 注文完了のあとに在庫更新や通知を動かしたい
- 画像変換やCSV出力のような重い処理を後ろへ回したい
という場面で、全部をその場で同期実行するとレスポンスが重くなったり、途中の失敗が全体へ波及したりします。
そこで、先にメッセージだけキューへ入れて、実処理は後ろのワーカーが拾って進める、という構成を取ります。
この記事は、2026年4月24日時点で AWS 公式の
What is Amazon Simple Queue Service?Amazon SQS queue typesAmazon SQS visibility timeoutAmazon SQS short and long pollingUsing dead-letter queues in Amazon SQSをもとに整理しています。
SQSとは何か
AWS公式では、Amazon SQS は 分散したソフトウェアシステムやコンポーネントを統合し、疎結合にするための、安全で耐久性があり可用性の高いホスト型キュー と説明されています。
少し言い換えると、処理同士を直接ベタ結合させずに、間へキューを挟むサービス です。
たとえば、APIサーバーがメール送信処理を直接呼ぶ構成だと、
となりがちです。
ここで SQS を挟むと、
という流れにできます。
これが 非同期処理でキューを入れる という話の正体です。
なぜキューを入れるのか
SQS を使う理由は、単に AWS のサービスだからではありません。
同期で直結すると困る場面を減らせるからです。
1. レスポンスを軽くしやすい
ユーザーへすぐ返したい処理と、裏で進めればよい処理を分けられます。
メール送信、ログ集約、通知、画像変換、外部連携などは、キューへ逃がす代表例です。
2. 一時的な負荷の山をならせる
急に大量の依頼が来ても、SQS にいったんためて、ワーカー側で順番に処理できます。
これによって、後段システムへ一気に負荷が流れ込みにくくなります。
3. 障害の影響を分離しやすい
たとえば通知サービスが一時的に落ちても、メインAPIまで全部巻き込まずに済む設計を取りやすくなります。
注文は受けたが通知はあとで再試行する という切り分けがしやすくなります。
4. 処理の担当を分けやすい
送る側は メッセージを入れる責任、受ける側は メッセージを処理する責任 に分かれます。
この分離によって、構成を後から伸ばしやすくなります。
SQS で覚えるべき基本の流れ
SQS の基本はかなりシンプルです。
- Producer がメッセージを送る
- Queue にメッセージがたまる
- Consumer / Worker がメッセージを受け取る
- 処理が成功したら削除する
ここで大事なのは、受け取っただけでは消えない ことです。
SQS では、処理が終わったら明示的に削除する前提です。
この性質があるからこそ、途中でワーカーが落ちても、メッセージを再処理できる余地が残ります。
Standard queue と FIFO queue の違い
AWS公式では、SQS には Standard queue と FIFO queue の2種類があると説明されています。
| 種類 | 向いている場面 |
|---|---|
| Standard queue | 高スループットを優先したい場面 |
| FIFO queue | 順序や重複抑制をより強く意識したい場面 |
Standard queue
Standard queue は、非常に高いスループットで使いやすい一方、少なくとも1回配送 と ベストエフォート順序 が前提です。
つまり、
- 同じメッセージが重複して届くことがある
- 順番が完全には保証されないことがある
という前提で受け側を作る必要があります。
だからこそ Standard queue を使うときは、同じ処理が2回走っても壊れない ように、冪等性を意識するのがかなり大事です。
FIFO queue
FIFO queue は、順序を保ちたい、重複を抑えたい場面向けです。
たとえば、
- 注文イベントを順番どおり処理したい
- 同じ要求を二重に処理したくない
といったケースです。
ただし、最初から何でも FIFO にするより、本当に順序保証が必要か を先に考えるほうが実務では大事です。
高スループット優先なら Standard queue のほうが自然な場面も多いです。
visibility timeout とは何か
SQS を理解するときに、visibility timeout はかなり重要です。
AWS公式では、メッセージを受信したあと、一定時間ほかのコンシューマーから見えなくする仕組みとして説明されています。
これは何のためにあるかというと、同じメッセージを複数ワーカーが同時に処理しにくくするため です。
流れとしてはこうです。
- ワーカーAがメッセージを受け取る
- そのメッセージは visibility timeout の間、ほかから見えなくなる
- ワーカーAが処理を終えて削除すれば完了
- もし削除前に失敗したら、タイムアウト後にまた見えるようになる
このため、visibility timeout は 再試行までの猶予 と考えると分かりやすいです。
短すぎると、まだ処理中なのに再配信されやすくなります。
長すぎると、失敗時の再試行が遅くなります。
処理時間に合わせて調整が必要です。
長 polling を使う理由
AWS公式では、long polling は空レスポンスを減らして、SQS 利用コストや無駄なポーリングを減らす方法として説明されています。
短 polling だと、
- メッセージがないのに何度も取りに行く
- 実はあるのに取れない空振りが起こる
ことがあります。
long polling を使うと、一定時間待ちながらメッセージを受け取れるので、無駄な取りに行き方が減ります。
SQS をちゃんと運用するなら、ここはかなり基本です。
Dead-Letter Queue は何のためにあるのか
失敗が続くメッセージを、いつまでも同じキューで回し続けると、全体が詰まりやすくなります。
そこで使うのが Dead-Letter Queue です。
AWS公式では、一定回数以上うまく処理できなかったメッセージを移す先として DLQ が説明されています。
つまり、
- 何度か再試行しても失敗する
- これ以上は本流キューに置かない
- 別の場所へ逃がして調査する
という整理です。
DLQ があると、失敗メッセージの調査や再投入をしやすくなります。
SQS を本番で使うなら、かなり基本の設計要素です。
どんな場面で SQS を使うのか
SQS は次のような場面でよく使われます。
特に、今すぐ画面へ返す必要はないが、確実には処理したい ものと相性がよいです。
よくある誤解
1. SQS を入れれば処理が速くなる
正確には、前段のレスポンスを軽くしやすくなる のであって、処理そのものが消えるわけではありません。
後ろではちゃんとワーカーが処理する必要があります。
2. SQS は順番どおりに動く
Standard queue では、その前提ではありません。
順序が重要なら FIFO queue を検討する必要があります。
3. 受け取ったら自動で完了する
これも違います。
受け取ったあとに処理が成功し、削除してはじめて完了です。
4. 再試行は気にしなくてよい
むしろかなり重要です。
重複処理、visibility timeout、DLQ、冪等性は最初から意識したほうが事故が減ります。
まとめ
SQS は、非同期処理で キューを1枚挟む ための AWS のサービスです。
処理を同期で直結せず、メッセージとしてためて後ろのワーカーへ渡すことで、レスポンス改善、負荷平準化、障害分離がしやすくなります。
最初に押さえるなら、
- SQS = メッセージをためる箱
- 送る側と処理する側を分ける
- Standard と FIFO がある
- visibility timeout と削除が重要
- 失敗時は DLQ を考える
この5つでかなり全体像が見えます。
この記事と一緒に読む
- ジョブキューとは？重い処理を後ろに回す理由
- Auto Scalingとは？EC2の台数を自動で増減する基本をAWSで整理
- API Gatewayとは？Lambdaの前段で何をしているのか
- Lambda
- CloudWatch
参考リンク
- AWS Docs: What is Amazon Simple Queue Service?
- AWS Docs: Amazon SQS queue types
- AWS Docs: Amazon SQS visibility timeout
- AWS Docs: Amazon SQS short and long polling
- AWS Docs: Using dead-letter queues in Amazon SQS