Amazon SNS（Simple Notification Service）は、AWSが2010年4月に提供開始したフルマネージドのPub/Sub（パブリッシュ・サブスクライブ）型メッセージングサービスです。「トピック」と呼ばれる配信先のグループにメッセージをPublishすると、購読しているサブスクライバー（SQSキュー・Lambda関数・HTTP/HTTPSエンドポイント・メール・SMS・モバイルプッシュ・Firehoseなど）に同時に配信されます。1メッセージを多数の受信者にファンアウト配信できる点が特徴で、SQSが「Pull型のキュー」だったのに対し、SNSは「Push型のPub/Sub」として位置付けられています。イベント駆動アーキテクチャの中核として、AWSの様々なサービスと連携する形で現代的なシステム設計に広く組み込まれています。
この記事の目次
- トピック・サブスクリプション・フィルタリング
- 2010年公開からマルチチャネル化への歩み
- ファンアウトパターンと運用通知
- SQS・EventBridge・Kinesisとの位置関係
- まとめ
トピック・サブスクリプション・フィルタリング
SNSの基本構造は「トピック」と「サブスクリプション」の組み合わせです。Publisherはトピック宛にメッセージを送信し、各サブスクライバーは自分が興味のあるトピックにサブスクリプションを登録しておきます。メッセージがトピックに届くと、登録されているすべてのサブスクライバーに非同期で配信される、典型的なPub/Subモデルです。
サブスクリプションには「フィルタポリシー」を設定でき、メッセージの属性（attributes）に基づいて自分宛のメッセージだけを選別できます。たとえば「region=us-east-1のイベントだけ受け取る」「priority=highだけ通知する」といった絞り込みがSNS側で行えるため、各サブスクライバーが余計なメッセージを処理しなくて済む設計です。FIFOトピックも提供されており、SQS FIFOキューと組み合わせて順序保証付きのファンアウトが可能です。標準トピックは少なくとも1回配信、FIFOトピックは厳密な順序と一度きり配信を提供します。
2010年公開からマルチチャネル化への歩み
SNSは2010年4月に提供開始されました。SQSが既に2006年から存在しており、企業内のシステム間メッセージングを担っていたのに対し、SNSは「アプリ側からエンドユーザー向け通知やマルチエンドポイント配信」を担当する補完的な位置として導入されました。初期からメール・SMS・HTTPエンドポイント配信に対応し、後にSQS・Lambda・モバイルプッシュ通知（APNs、GCM/FCM、ADM、Baidu）へと配信先が拡張されました。
2012年にモバイルプッシュ通知が追加され、iOS/Androidアプリへの通知配信基盤として広く使われるようになります。2020年10月にはFIFOトピックが追加され、順序保証が必要なマイクロサービス間通信での選択肢が広がりました。2023年以降はAmazon Kinesis Data Firehose配信、メッセージアーカイブ・リプレイ機能、Cross-region配信などが追加され、「単なる通知サービス」から「イベント駆動アーキテクチャの中核」へと進化しています。EventBridgeとの役割分担も明確化し、SNSは多チャネル配信に強みを持つ位置付けが定着しました。
ファンアウトパターンと運用通知
SNSの典型的な使い方は「ファンアウトパターン」です。1つの注文確定イベントをSNSトピックに送り、購読している在庫サービス用SQSキュー・決済サービス用SQSキュー・通知サービス用SQSキューに同時に配信する構成は、マイクロサービス設計の定石になっています。各下流サービスは自分のSQSキューだけを見ればよく、上流の事情を知らずに済む疎結合性が生まれます。
運用通知でも広く使われ、CloudWatch Alarmが閾値を超えるとSNSトピックに通知が送られ、メール・Slack（Lambda経由）・SMS・PagerDutyなどに同時に転送される構成がほぼ全てのAWSシステムで使われています。モバイルアプリ向けには、iOSのAPNs・AndroidのFCMを抽象化した統一APIで通知配信ができ、自社で各OSのSDK連携を実装する手間を省けます。Lambdaをサブスクライバーにすれば、SNSメッセージをトリガーに任意の処理を自動実行でき、イベント駆動アーキテクチャの起点として機能します。
SQS・EventBridge・Kinesisとの位置関係
SQSは1メッセージを1つの処理プールに渡すPull型キューで、SNSは1メッセージを複数受信者に配るPush型Pub/Subという違いがあります。「SNS→SQS」のファンアウト構成では、Pub/Subの広がりとキューの安全性を両立でき、現代AWSアーキテクチャの定番パターンです。
EventBridge（旧CloudWatch Events）はルールベースのイベント駆動ハブで、AWS各サービスや外部SaaSのイベントを統合的にルーティングできます。SNSとEventBridgeは似た位置付けですが、SNSは「メール・SMS・モバイルプッシュへの直接配信」が得意で、EventBridgeは「AWSサービス間の複雑なイベントルーティング」が得意、と棲み分けています。Kinesis Data Streamsは順序保証付きの大量データストリーム用で、複数コンシューマが独立に再生できる点が異なります。MSK（Managed Kafka）はApache Kafkaのマネージド版です。SNSはPub/Sub・マルチチャネル配信という独自領域を持ち、各サービスと組み合わせて使われる中核ピースとして定着しています。
まとめ
Amazon SNSは2010年提供開始のPub/Sub型マネージドサービスで、トピック・サブスクリプション・フィルタリングを中核に構成されます。メール・SMS・モバイルプッシュ・SQS・Lambdaなど多チャネル配信を統一APIで実現し、ファンアウトパターンや運用通知の定番ツールになっています。SQS・EventBridge・Kinesisと棲み分けつつ、イベント駆動アーキテクチャの中核として現代のAWSシステムに広く組み込まれている存在です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント