Amazon SQSにおいてキューとトピックはどう違う？

質問

Amazon SQSにおいてキューとトピックはどう違う？ どう使い分ける？

伝言 【電子書籍】[ 中脇初枝 ] 価格:1001円 (2026/5/29 20:56時点) 感想(0件)

解答

まず重要なのは、 SQS に「トピック」はありません。 ここ、かなり混同されやすいです。 AWSでは： SQS = Queue（キュー） SNS = Topic（トピック） です。 ただし実務では： SNS Topic → SQS Queue を組み合わせることが非常に多いので、 一緒に語られがちです。 1. Queue（SQS）とは何か SQSキューは簡単に言うと： 「仕事を順番待ちさせる箱」 です。 Producer がメッセージを入れ、 Consumer が取り出して処理します。 イメージ App → Queue → Worker 特徴： 1メッセージは通常1回処理 非同期化 バッファリング 疎結合 主用途 バックグラウンド処理 ジョブキュー バッチ リトライ 負荷平準化 2. Topic（SNS）とは何か SNSトピックは： 「イベントを複数へ同時配信する仕組み」 です。 イメージ → EmailEvent → Topic → QueueA → QueueB → Lambda つまり： Publish / Subscribe（Pub/Sub） モデル。 3. 一番大きな違い SQS Queue 「誰か1人が処理する前提」 SNS Topic 「複数へ配る前提」 4. 実際どう使い分ける？ SQS向き 「処理してほしい」 例： 画像変換 メール送信ジョブ 注文処理 非同期タスク つまり： “作業依頼” SNS向き 「イベントを知らせたい」 例： ユーザー登録 決済完了 障害通知 デプロイ完了 つまり： “通知・イベント配信” 5. 組み合わせが超重要 実務ではこれが多い。 App ↓SNS Topic ↓ ↓ ↓SQS SQS Lambda 例えば： 「注文完了」 を： 在庫サービス メールサービス 分析基盤 全部に通知したい。 この時： SNSが配信 各SQSが受信 する。 6. なぜ直接SQSへ送らないの？ 直接だと： App → QueueA → QueueB → QueueC となり、 接続先増加 変更影響大 サービス追加面倒 になる。 SNSを挟むと： Producer が配信先を知らなくていい 7. 「イベント駆動」の本質 かなり重要。 SNSは： 「何が起きたか」 を流す。 SQSは： 「誰か処理して」 を流す。 8. FIFOとの関係 SQSには： Standard FIFO があります。 ただSNSとのFIFO組み合わせには制限もある。 設計時は注意。 9. 一言で整理すると SQS Queue 1対1寄り 処理依頼 消費される SNS Topic 1対多 イベント通知 配信される まとめ AWSでは： SQS = Queue SNS = Topic です。 役割： Queue 非同期処理 ジョブ管理 負荷平準化 Topic イベント配信 Pub/Sub 複数通知 実務では： SNSでイベント配信し、 SQSで各サービスが受け取って処理 という組み合わせが非常に多いです。

Linux教科書 LPICレベル1 Version5.0対応 （EXAMPRESS） [ 中島 能和 ] 価格:4180円 (2026/3/20 13:22時点) 感想(2件)

にほんブログ村

人気ブログランキング