Amazon SNS による通知設計 - トピックとサブスクリプションのパターン
Standard と FIFO トピックの使い分け、SQS ファンアウトパターン、サブスクリプションフィルターによる条件付きルーティングを紹介します。
トピック設計とサブスクリプション
SNS トピックは Standard と FIFO の 2 種類があります。Standard トピックはほぼ無制限のスループットを提供し、メッセージの順序はベストエフォートです。FIFO トピックはメッセージグループ ID ごとの厳密な順序保証と、メッセージ重複排除 ID による重複排除を提供します。FIFO トピックのサブスクライバーは SQS FIFO キューに限定されます。サブスクリプションプロトコルは SQS、Lambda、HTTP/HTTPS、メール、SMS、Kinesis Data Firehose に対応しています。メッセージ属性を付与することで、サブスクリプションフィルターポリシーによる条件付きルーティングが可能になります。
ファンアウトパターンの設計
SNS + SQS ファンアウトパターンでは、SNS トピックに複数の SQS キューをサブスクライブし、1 つのパブリッシュで全キューにメッセージを配信します。各キューのコンシューマーは独立して処理を進められるため、1 つのコンシューマーの障害が他に影響しません。この構成は注文処理システムで典型的に使われ、1 件の注文イベントが在庫更新キュー、メール通知キュー、分析記録キューに同時配信されます。ファンアウト先の数に実質的な上限はなく (アカウントあたりのサブスクリプション数クォータは 12,500,000)、新しい処理を追加する際はサブスクリプションを追加するだけでパブリッシャー側の変更が不要です。クロスアカウントファンアウトではトピックポリシーで別アカウントの SQS キューからの Subscribe を許可し、マイクロサービス間を疎結合に保ちます。
サブスクリプションフィルターと配信保証
サブスクリプションフィルターポリシーは属性ベースとペイロードベースの 2 種類があります。属性ベースフィルターはメッセージ属性 (文字列の完全一致、前方一致、数値比較、exists 判定) で条件を定義します。ペイロードベースフィルターはメッセージ本文の JSON パスに対してフィルタリングを実行し、ネストされたフィールドにも対応します。フィルターは SNS 側で評価されるため、条件に合致しないメッセージはサブスクライバーに配信されず、ダウンストリームの処理コストとノイズを削減します。配信失敗時のリトライポリシーはプロトコルごとに異なり、HTTP/HTTPS エンドポイントでは指数バックオフ (最大 23 日間) でリトライします。リトライ後も配信できないメッセージはデッドレターキュー (DLQ) に送信され、後から原因調査や再処理が可能です。DLQ のリドライブ機能で、問題解決後にメッセージを元のサブスクリプションに再配信できます。
FIFO トピックとメッセージ属性
FIFO トピックはメッセージの順序保証と重複排除を提供し、FIFO SQS キューとの組み合わせで厳密な順序処理を実現します。メッセージグループ ID でメッセージを論理的にグループ化し、グループ内の順序を保証します。メッセージ属性でメタデータ (イベントタイプ、優先度、送信元) を付与し、サブスクリプションフィルターポリシーで属性に基づくルーティングを実装します。メッセージデータ保護で PII (個人情報) を自動検出し、マスキングまたは拒否するポリシーを設定できます。 通知設計の統合パターンを深く理解するには、専門書籍 (Amazon)が役立ちます。
設計の落とし穴と運用上の注意点
SNS の最大メッセージサイズは 256 KB で、これを超えるペイロードは S3 に格納しポインタのみを SNS で送信する Extended Client Library パターンを使います。FIFO トピックのスループット上限はメッセージグループあたり毎秒 300 メッセージ (バッチで 3,000) であり、高スループットが必要な場合はメッセージグループ ID を分散させる設計が必要です。フィルターポリシーの複雑さが増すとデバッグが困難になるため、フィルター条件は 1 サブスクリプションあたり 5 属性以下に抑え、複雑なルーティングには EventBridge の利用を検討します。HTTP/HTTPS エンドポイントのサブスクリプション確認が完了しないとメッセージが配信されないため、確認トークンの処理をエンドポイント実装に含めることが必須です。メッセージの暗号化 (SSE) を有効にすると、サブスクライバー側の IAM ロールに KMS の復号権限が必要になる点も見落としがちです。
SNS と EventBridge の使い分け
SNS と EventBridge はどちらもイベント駆動アーキテクチャの中核ですが、特性が異なります。SNS はシンプルなファンアウトとプロトコル多様性 (SQS、Lambda、HTTP、SMS、メール) に優れ、メッセージ配信のレイテンシが低い点が強みです。EventBridge はイベントの構造に対する複雑なルールマッチング (100 以上のフィールドパターン)、スキーマレジストリによる型安全性、SaaS 統合に優れます。実務的な使い分けとして、アプリケーション内部のファンアウト (注文 → 複数キュー) は SNS、サービス間のイベントルーティング (複雑な条件分岐、外部 SaaS イベント) は EventBridge が適しています。SNS は 1 トピックあたりの配信先 (サブスクリプション) 数が圧倒的に多く (12,500,000)、EventBridge は 1 ルールあたり最大 5 ターゲットに制限される代わりに、ルール数でスケールする設計です。
SNS の料金
SNS の Standard トピックへのパブリッシュは 100 万リクエストあたり約 0.50 ドルです。FIFO トピックは 100 万リクエストあたり約 0.30 ドルです。HTTP/S エンドポイントへの配信は 100 万通知あたり約 0.60 ドル、SQS への配信は無料です。SMS 配信は送信先の国に応じた従量課金です。メッセージフィルタリングは追加料金なしで利用でき、不要なメッセージの配信を削減してダウンストリームのコストを最適化します。
まとめ
SNS はトピックベースの Pub/Sub メッセージングで、ファンアウトパターンとサブスクリプションフィルターによる柔軟なメッセージルーティングを提供します。FIFO トピックで順序保証と重複排除を実現し、メッセージデータ保護で PII の自動検出とマスキングを行います。SQS との組み合わせで信頼性の高い非同期処理パイプラインを構築し、DLQ で配信失敗を確実に捕捉します。