AWS Solutions Architect · レッスン

SNS トピックとファンアウトアーキテクチャ

1つの SNS トピックにメッセージを発行し、複数の SQS キュー、Lambda 関数、HTTP エンドポイントへ同時にファンアウトします。

「SNS トピックとファンアウトアーキテクチャ」はCoddyKit上の無料AWS Solutions Architectレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

Amazon SNSとは

Amazon Simple Notification Service (SNS) は、フルマネージドのpub/subメッセージングサービスです。パブリッシャーはSNSのtopicにメッセージを送信し、SNSはそのメッセージをすべてのsubscriberに即座に配信します。SQSがプル型であるのに対し、SNSはプッシュ型であり、メッセージが発行されるとすぐにサブスクライバーへ配信します。そのため、複数の下流システムにイベントを同時にブロードキャストする用途に適しています。

SNSトピック：StandardとFIFO

SQSと同様に、SNSにも2種類のトピックがあります。Standard topics は、ベストエフォートのメッセージ順序、少なくとも1回の配信、ほぼ無制限のスループットを提供し、SQS、Lambda、HTTPエンドポイント、メール、SMS、モバイルプッシュに配信できます。FIFO topics は、厳密な順序性と正確に1回の配信を保証しますが、配信先はFIFO SQSサブスクライバーに限られます。FIFOトピックはバッチ処理時に毎秒最大3,000メッセージをサポートし、複数のサブスクライバー間でイベントの順序を維持する必要がある場合に使用します。

aws sns create-topic --name 'OrderEvents'

# Create FIFO topic
aws sns create-topic \
  --name 'OrderEvents.fifo' \
  --attributes '{"FifoTopic": "true", "ContentBasedDeduplication": "true"}'

SNSサブスクライバーの種類

SNSは、プロトコルに基づく複数のサブスクライバータイプをサポートしています。

SQS: 耐久性のあるキューイング（非同期処理で最も一般的）
Lambda: 直接呼び出し（SNSから見ると同期的）
HTTP/HTTPS: 外部エンドポイントへのWebhook配信
Email / Email-JSON: 人への通知
SMS: テキストメッセージの配信
Mobile Push: プラットフォームアプリケーション経由のFCM、APNs
Firehose: Kinesis Data Firehose経由でS3またはRedshiftにストリーミング

# Subscribe an SQS queue to an SNS topic
aws sns subscribe \
  --topic-arn 'arn:aws:sns:us-east-1:123456789012:OrderEvents' \
  --protocol sqs \
  --notification-endpoint 'arn:aws:sqs:us-east-1:123456789012:InventoryQueue'

ファンアウトアーキテクチャパターン

Fan-out はSNSの中核的なパターンです。トピックに1つのメッセージを発行すると、SNSがすべてのサブスクライバーに同時に配信します。たとえば、新しい注文イベントを、倉庫でのフルフィルメント用のSQSキュー、在庫更新用の別のSQSキュー、不正検出用のLambda関数、運用チーム向けのメールサブスクリプションにファンアウトできます。各サブスクライバーは相互に結合することなく、イベントを独立して処理します。これは、単一のコンシューマーが複数のシステムへルーティングする方式よりも、はるかにスケーラブルです。

SNS + SQSファンアウト：ベストプラクティス

推奨されるパターンは、SNSとSQSを組み合わせる方法です。SNSに発行し、複数のSQSキューにファンアウトします。これにより、次の利点が得られます。

Durability: コンシューマーが停止していても、メッセージはSQSでキューに蓄積されます
Independent scaling: 各コンシューマーがそれぞれのペースで処理できます
Decoupling: パブリッシャーを変更せず、SNSにサブスクライブするだけで新しいコンシューマーを追加できます
Retry resilience: SQSがVisibility TimeoutとDLQを提供します

Lambdaを直接サブスクライバーにすると、SQSが提供するバッファリングがないため、SNS→SQS→Lambdaの3層パターンのほうが高い耐障害性を備えています。

メッセージ配信の再試行とDLQ

SNSがサブスクライバーへの配信に失敗した場合（HTTPエンドポイントが5xxを返す、Lambdaが例外をスローする、SQSが利用できないなど）、exponential backoff 戦略で再試行します。再試行ポリシーはプロトコルによって異なります。HTTPエンドポイントでは、最大4回の即時再試行に加え、23日間にわたる指数バックオフが行われます。LambdaとSQSでは、それぞれ独自の再試行メカニズムによって再試行が管理されます。SNS Topic DLQ を設定すると、すべての配信再試行を使い果たしたメッセージを収集でき、イベントが暗黙のうちに失われることを防げます。

SNSへのメッセージ発行

AWS SDKまたはCLIを使用してSNSに発行します。各メッセージには、Subject（メール用）、Message 本文（最大256 KB）、ルーティング用のMessage Attributesを含めることができます。異なるサブスクライバータイプ（SQS、メール、モバイル）に対しては、Message Structure を使用してプロトコルごとに異なる内容を送信できます。プロトコル固有のキーを持つJSONにより、サブスクライバータイプごとにペイロードを調整できます。

aws sns publish \
  --topic-arn 'arn:aws:sns:us-east-1:123456789012:OrderEvents' \
  --message '{"orderId": "12345", "status": "PLACED", "amount": 99.99}' \
  --subject 'New Order Placed' \
  --message-attributes '{
    "orderType": {"DataType": "String", "StringValue": "PREMIUM"}
  }'

SNSサブスクリプションフィルターポリシー

Subscription filter policies を使用すると、message attributes に基づいて、各サブスクライバーが関係するメッセージだけを受信できるようになります。フィルタリングしない場合、すべてのサブスクライバーが発行されたすべてのメッセージを受信します。フィルターポリシーを設定すると、サブスクライバーは必要な属性値を指定できます。たとえば、'PREMIUM' 注文用のキューは {"orderType": ["PREMIUM"]} というフィルターでサブスクライブし、'STANDARD' キューは ["STANDARD"] でフィルタリングします。各サブスクライバーは関係するサブセットだけを処理するため、不要な処理を削減できます。

aws sns set-subscription-attributes \
  --subscription-arn 'arn:aws:sns:...:subscription/...' \
  --attribute-name FilterPolicy \
  --attribute-value '{"orderType": ["PREMIUM"], "region": ["US", "EU"]}'

モバイルプッシュ通知向けのSNS

SNSは、iOS（APNs）およびAndroid（FCM/GCM）デバイスへの直接的なmobile push notificationsをサポートしています。デバストークンをプラットフォームエンドポイントARNとして登録し、そのエンドポイントに直接発行するか、プラットフォームアプリケーションのサブスクライバーを持つトピックに発行します。大規模にデバイスへ直接通知する場合（数百万台のデバイスなど）は、SNSとSQS fan-outを組み合わせます。SNSが通知イベントをSQSにルーティングし、ワーカーサービスが大量のトークン解決と配信を大規模に処理します。

SNSメッセージの暗号化とアクセス制御

AWS KMSを使用したserver-side encryptionでSNSメッセージを保護します。これにより、SNSのインフラストラクチャ内で保管中のメッセージが暗号化されます。アクセス制御には、resource-based policies（誰がトピックに発行またはトピックからサブスクライブできるか）とIAM policiesの両方を使用します。S3バケットからSNSトピックへ通知を発行できるようにするには、トピックのリソースポリシーでS3サービスプリンシパルに sns:Publish を許可します。不正なイベント注入を防ぐため、発行元は必ず許可されたソースに制限してください。

SNSとSQS：補完関係にあるサービス

SNSとSQSは代替関係ではなく、補完関係にあります。SNS（プッシュ型）は複数のコンシューマーに即座にブロードキャストするためのもので、複数のシステムがイベントに反応する必要がある場合に使用します。SQS（プル型）は、再試行とDLQを備えた、信頼性と耐久性の高い単一コンシューマー処理のためのもので、1つのコンシューマーが各メッセージを自身のペースで正確に1回処理する必要がある場合に使用します。SNS→SQSファンアウトパターンなら、SNSによるブロードキャスト配信とSQSによる耐久性のある再試行可能な処理の両方を実現できます。この組み合わせは、SAA-C03の試験シナリオで頻繁に登場します。

クイックチェック

このレッスンで学んだ AWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、SNS topics によって、SQS、Lambda、HTTP、SMS、メールなどのサブスクライバーへプッシュ型のpub/subブロードキャストを同時に提供できること、fan-out architecture によって、1つのSNSトピックから複数のSQSキューへ配信し、耐久性があり、個別にスケーリング可能なマルチコンシューマーのイベント処理を実現できること、そしてsubscription filter policies によって、メッセージ属性に基づき関係するイベントだけを各サブスクライバーにルーティングし、不要な処理を削減できることを学びました。次は、SQSメッセージフィルタリングとSNS + SQS統合について詳しく説明します。

よくある質問

「SNS トピックとファンアウトアーキテクチャ」レッスンは無料ですか？

はい。「SNS トピックとファンアウトアーキテクチャ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「SNS トピックとファンアウトアーキテクチャ」で何を学びますか？

1つの SNS トピックにメッセージを発行し、複数の SQS キュー、Lambda 関数、HTTP エンドポイントへ同時にファンアウトします。ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「SNS トピックとファンアウトアーキテクチャ」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AWS Solutions Architectに戻る