Pub/Subアーキテクチャパターンは、AWS（Amazon Web Services）でも非常に重要な役割を果たしています。
AWSでは、Pub/Subを実現するために「Amazon SNS」と「Amazon SQS」という2つのサービスが組み合わせて活用されることが多く、この組み合わせはAWSアーキテクチャの定番パターンとなっています。
本記事では、AWSのPub/Subサービスとしての Amazon SNSとSQSの仕組みと使い方について、メッセージング・通知・キュー・マイクロサービス・イベント処理といったキーワードを交えながら、わかりやすく丁寧に解説していきます。
AWSを活用したシステム開発・アーキテクチャに関心がある方にとって、必ず参考になる内容です。
ぜひ最後まで読み進めてください。
目次
AWS Pub/Subサービスとは何か？結論からわかりやすく解説
それではまず、AWSにおけるPub/Sub関連サービスの概要について解説していきます。
AWSにおけるPub/Subサービスとは、主に「Amazon SNS（Simple Notification Service）」と「Amazon SQS（Simple Queue Service）」という2つのAWSサービスを組み合わせることで実現するメッセージング・通知の仕組みのことです。
AWSにはGoogle Cloud Pub/Subのような「Pub/Sub」という名称のサービスは存在しませんが、SNSとSQSを組み合わせることで、Pub/Subアーキテクチャパターンを実装することができます。
AWSにおけるSNSとSQSの組み合わせの核心は「SNSがPub/Subのパブリッシャー側・配信側を担い、SQSがサブスクライバー側のメッセージ保持・処理を担う」という分業です。SNS単体ではメッセージを保持しないため、配信先がオフラインの場合にメッセージが失われる可能性がありますが、SQSを組み合わせることでメッセージを確実に保持・処理できるようになります。この組み合わせが「SNS+SQSパターン」または「ファンアウトパターン」として広く知られています。
SNSとSQSのそれぞれの役割と特性を理解することが、AWSでのPub/Sub実装を理解する上での鍵となります。
Amazon SNSとは
Amazon SNS（Simple Notification Service）とは、AWSが提供するフルマネージドのパブリッシュ・サブスクライブ型メッセージングサービスで、1つのメッセージを複数の宛先（エンドポイント）に同時に配信できる通知サービスです。
SNSの主な特徴を整理しましょう。
【Amazon SNSの主な特徴】
トピックにメッセージをパブリッシュし複数のサブスクライバーに同時配信できる
配信先としてSQS・Lambda・HTTP/S・メール・SMSなど多様なエンドポイントに対応
メッセージは配信後に保持されない（揮発性）
高スループット・低レイテンシーのメッセージ配信が可能
SNSは配信後にメッセージを保持しないため、配信先が一時的に利用不可能な場合はメッセージが失われる可能性があります。
この課題を解決するために、SNSのサブスクライバーとしてSQSを設定し、SQSがメッセージを確実に保持してから処理するという組み合わせが広く採用されているのです。
Amazon SQSとは
Amazon SQS（Simple Queue Service）とは、AWSが提供するフルマネージドのメッセージキューサービスで、メッセージを確実に保持・配信し、処理が完了するまでメッセージを安全に保管する仕組みです。
| 項目 | Amazon SNS | Amazon SQS |
|---|---|---|
| 主な役割 | 通知・配信（パブリッシュ側） | メッセージ保持・処理（キュー側） |
| メッセージの保持 | しない（配信後消失） | する（最大14日間保持） |
| 配信モデル | プッシュ（SNSが配信先に送る） | プル（処理側がキューから取得） |
| 受信者の数 | 複数（ファンアウト） | 基本的に1つのコンシューマーが処理 |
SQSはメッセージを確実に保持するため、コンシューマー（処理側）が一時的にダウンしていても、メッセージは失われません。
SNS+SQSファンアウトパターン
SNSとSQSを組み合わせた最も一般的なパターンが「ファンアウトパターン」です。
この構成では、パブリッシャーがSNSトピックにメッセージを送り、複数のSQSキューがそのSNSトピックをサブスクライブします。
各SQSキューは独立して、それぞれの処理を担うワーカー（Lambda・EC2など）にメッセージを届けます。
この構成により、1つのSNSトピックへのパブリッシュで、複数の独立したSQSキューにメッセージが届き、それぞれの処理が非同期・並行して実行される、典型的なPub/Subパターンが実現されるのです。
Amazon SQSの詳細機能
続いては、AWSのPub/Sub実装において重要な役割を担うAmazon SQSの詳細な機能について確認していきます。
SQSには、信頼性・柔軟性を高めるための様々な機能が備わっています。
スタンダードキューとFIFOキュー
Amazon SQSには「スタンダードキュー」と「FIFOキュー」という2種類のキューが提供されています。
スタンダードキューは、高スループット・at least once配信・ベストエフォートの順序保証という特性を持つ基本的なキューです。
FIFOキューは、First-In-First-Out（先入れ先出し）の厳密な順序保証と、exactly once（厳密に1回）の配信保証を提供するキューです。
| 項目 | スタンダードキュー | FIFOキュー |
|---|---|---|
| スループット | ほぼ無制限 | 1秒あたり最大300件（バッチなら3000件） |
| 順序保証 | ベストエフォート（順序は保証しない） | 厳密な順序保証 |
| 重複配信 | 稀に発生する可能性あり | 完全に防止 |
処理の順序や重複が問題となるビジネスロジック（金融取引・状態管理など）ではFIFOキューが、高スループットが求められる大量データ処理ではスタンダードキューが適しています。
可視性タイムアウトとデッドレターキュー
Amazon SQSの信頼性を支える重要な機能のひとつが「可視性タイムアウト（Visibility Timeout）」です。
コンシューマーがキューからメッセージを受け取ると、そのメッセージは一時的に他のコンシューマーから見えなくなります（非表示状態）。
処理が完了したらメッセージを削除しますが、処理が完了しないまま可視性タイムアウトの時間が経過すると、メッセージは再びキューに表示され、別のコンシューマーが処理を再試行できるようになるという仕組みです。
また、Amazon SQSもデッドレターキュー（DLQ）をサポートしており、規定回数の再試行後も処理できないメッセージを、別のキューに退避させることができます。
遅延キューとメッセージタイマー
Amazon SQSには、メッセージの配信を意図的に遅らせるための機能も用意されています。
【遅延配信の機能】
遅延キュー（Delay Queue） キュー全体にデフォルトの遅延時間を設定する（最大15分）
メッセージタイマー 個々のメッセージに対して遅延時間を設定する
活用例 注文確定後5分後に確認メールを送る・スケジュールされた処理を一定時間後に実行する
こうした遅延機能は、特定のタイミングで処理を行う必要があるビジネスロジックを、シンプルに実装するための便利な仕組みです。
AWSでのPub/Sub活用パターンと他サービスとの連携
続いては、AWSにおけるPub/Sub（SNS+SQS）の代表的な活用パターンと、他のAWSサービスとの連携について確認していきます。
AWSのエコシステムを理解することで、より効果的なシステム設計ができるようになります。
イベント駆動アーキテクチャでの活用
AWSでのSNS+SQSの組み合わせは、イベント駆動アーキテクチャの中核として機能します。
【AWSイベント駆動アーキテクチャの典型的なパターン】
ユーザーが注文を確定するとバックエンドが「注文確定」イベントをSNSトピックに発行する
SNSが3つのSQSキューにメッセージをファンアウト配信する
Lambda A がSQSキュー1からメッセージを受け取り在庫を更新する
Lambda B がSQSキュー2からメッセージを受け取り確認メールを送信する
Lambda C がSQSキュー3からメッセージを受け取り分析データを記録する
このパターンにより、各Lambdaが独立して非同期に処理を行い、一方が失敗しても他には影響しないという、疎結合で堅牢なシステムを実現できます。
Amazon EventBridgeとの関係
近年AWSでは、SNS+SQSに加えて「Amazon EventBridge」も、イベント駆動アーキテクチャの重要なサービスとして注目されています。
EventBridgeは、AWSサービス・SaaS・カスタムアプリケーションからのイベントをルーティングするためのサーバーレスイベントバスサービスです。
| サービス | 強み | 向いている用途 |
|---|---|---|
| SNS+SQS | シンプルな構成・高スループット・豊富な統合 | アプリケーション間の通知・メッセージキューイング |
| EventBridge | イベントルーティング・スケジューリング・SaaS統合 | AWS内外のイベント連携・スケジュール処理 |
用途によってこれらのサービスを使い分けたり組み合わせたりすることで、AWSでの強力なイベント駆動システムを構築することができます。
Google Cloud Pub/SubとAWSの比較
Google Cloud Pub/SubとAWSのSNS+SQSを比較することで、各プラットフォームの特徴の違いが見えてきます。
Google Cloud Pub/Subは単一サービスとしてPub/Subの機能を包括的に提供するのに対し、AWSはSNSとSQSという目的の異なるサービスを組み合わせることでPub/Subを実現するというアプローチの違いがあるといえます。
どちらのアプローチが優れているかは用途によって異なりますが、AWSのアプローチは各コンポーネントを目的に応じて組み合わせる柔軟性があり、Google Cloudのアプローチはシンプルさと一貫したAPIという利点があります。
まとめ
本記事では、AWSのPub/SubサービスとしてのAmazon SNSとSQSについて、SNSとSQSの役割の違い・SNS+SQSファンアウトパターン、SQSの詳細機能（スタンダードキューとFIFOキュー・可視性タイムアウト・デッドレターキュー・遅延キュー）、イベント駆動アーキテクチャでの活用・EventBridgeとの関係・Google Cloud Pub/Subとの比較まで幅広く解説しました。
AWSでのPub/Subは、主にSNS（通知・配信）とSQS（キュー・保持）の組み合わせによって実現されており、SNS+SQSファンアウトパターンがAWSにおけるPub/Sub実装の定番となっています。
SQSにはスタンダードキューとFIFOキューという種類があり、可視性タイムアウト・デッドレターキュー・遅延キューなどの機能が信頼性の高いメッセージ処理を実現します。
AWSのイベント駆動アーキテクチャでは、SNS+SQSに加えてEventBridgeも重要な役割を担うようになっており、目的に応じてこれらのサービスを使い分けることが重要です。
次の記事では、リアルタイム通知プロトコルとして知られる「PubSubHubbub」について解説していきます。
