SAA / ドメイン2 レジリエントなアーキテクチャの設計

重要な内容

Amazon SNS (Simple Notification Service)

は、メッセージを publisher から複数の subscriber へ配信するためのマネージドな pub/sub メッセージングサービスです。 1 つの topic にメッセージを publish すると、、、/S、Email、SMS、Mobile Push、 など複数の購読先へ通知できます。

SAA では、SNS を「通知サービス」としてだけ覚えるのではなく、SQS との fanout、Lambda 連携、フィルターポリシー、Standard topic と topic、配信失敗時の 、 暗号化、 との使い分けを判断できることが重要です。

Point
  • SNS = Simple Notification Service の略です。
  • Notification は「通知」という意味です。
  • SNS は「1 つのメッセージを複数の購読先へ通知するサービス」と覚えます。
  • 和訳

概要

は、イベントを発行する側と受け取る側をにするためのサービスです。 publisher は topic にメッセージを送るだけで、どの subscriber が受け取るかを直接意識しません。 subscriber は topic を購読し、自分に必要な通知を受け取ります。

概要の図 Publisherイベント発行元 SNS Topic SQS Queue Lambda Function HTTP/S Endpoint Email / SMS / Mobile Push Amazon Data Firehose

SAA では、「1 つのイベントを複数の処理系へ配る」「 alarm をメール通知する」「 イベントやアプリケーションイベントを複数 consumer に配信する」「 を組み合わせて各 consumer の処理遅延を吸収する」といった文脈で出ます。

見るポイント代表的な判断
複数の購読先へ同じイベントを配るかSNS topic を使います。
各購読先で独立して再試行・バッファリングしたいかSNS + SQS fanout を使います。
購読先ごとに受け取るメッセージを絞りたいかSubscription filter policy を使います。
順序や重複排除が必要かSNS topic と SQS FIFO queue を検討します。
配信失敗を後で調査したいかSubscription ごとに を設定します。
人への通知かEmail、SMS、Mobile Push を検討します。

主要技術

①Topic、Publisher、Subscriber

の中心は topic です。 Publisher は topic にメッセージを送信し、subscriber は topic を購読してメッセージを受け取ります。 Topic は、メッセージ配信の論理的な入口です。

要素役割試験での判断ポイント
Topicメッセージの配信チャネル複数 subscriber へ同じイベントを配る単位です。
Publisherメッセージ発行元アプリケーション、、、 などが該当します。
SubscriptionTopic と endpoint の紐付け購読先ごとの配信方法やフィルターを設定します。
Endpoint実際の配信先、、/S、Email、SMS、Mobile Push などです。

SNS は push 型の配信です。 SQS のように consumer がキューから poll するのではなく、SNS が購読先へメッセージを配信します。 ただし、SQS を subscriber にすると、SNS が SQS にメッセージを入れ、後続の worker が自分のペースで処理できます。

①Topic、Publisher、Subscriberの図 Publish Deliver Invoke POST Publisher SNS Topic SQS Queue Lambda HTTP/S Endpoint

⚠️ 頻出: 「1 つのイベントを複数の独立した処理先へ配信する」は SNS です。「1 つの処理待ち行列を worker が取り出す」は SQS です。

②Fanout と SQS 連携

の代表的な設計パターンは fanout です。 1 つの topic に publish されたメッセージを、複数の queue、、/S endpoint などへ同時に配信します。

SAA では、SNS 単体よりも SNS + SQS の組み合わせが頻出です。 各 subscriber 用に SQS queue を用意すると、処理系ごとに独立したバッファ、再試行、、スケーリングを持てます。

②Fanout と SQS 連携の図 注文アプリ SNS Topic: OrderCreated SQS Queue発送処理 SQS Queue請求処理 SQS Queue分析処理 Shipping Worker Billing Worker Analytics Worker
構成用途判断ポイント
SNS -> Lambdaすぐに関数を起動軽量なイベント処理や通知処理に向きます。
SNS -> SQSバッファ付き非同期処理処理遅延、障害、再試行を queue 側で吸収できます。
SNS -> 複数 SQSFanout複数処理系が同じイベントを独立して処理できます。
SNS -> HTTP/S外部システム通知Webhook 的な連携で使います。
SNS -> Email/SMS人への通知運用通知、アラート、ユーザー通知で使います。

SNS から SQS へ配信する場合、SQS queue policy で SNS topic からの sqs:SendMessage を許可します。 これを忘れると subscription はあってもメッセージ配信に失敗します。

⚠️ 頻出: 「複数システムへ同じイベントを配り、それぞれが独立して処理したい」は SNS + 複数 SQS queue です。1 つの SQS queue を複数処理系で共有すると、各メッセージは通常どれか 1 つの consumer に処理されます。

③Message filtering

の subscription filter policy を使うと、subscriber ごとに受け取るメッセージを絞れます。 デフォルトでは、subscriber は topic に publish されたすべてのメッセージを受け取ります。 フィルターを設定すると、メッセージ属性または 形式のメッセージ本文に基づいて、配信対象を制御できます。

フィルター対象用途試験での判断ポイント
Message attributes属性値で配信先を分けるeventType=order-created などで絞ります。
Message bodyJSON 本文の値で配信先を分けるpayload 内の項目で絞りたい場合に使います。
フィルターなし全 subscriber に配信全処理系が同じイベントを必要とする場合です。
③Message filteringの図 type = order type = payment priority = high SNS Topic Message Order Queue Payment Queue Alert Lambda

フィルターを使うと、不要なメッセージを subscriber 側で捨てる処理を減らせます。 たとえば、注文、決済、配送、分析を同じ topic に publish し、各 subscription が必要なイベントだけを受け取る設計ができます。

ただし、フィルターに依存しすぎると、topic の意味が広がりすぎる場合があります。 ドメインが明確に異なるイベントは topic を分け、同じ topic 内の一部条件分岐には filter policy を使う、という設計が分かりやすいです。

⚠️ 頻出: 「同じ topic から subscriber ごとに必要なイベントだけ受け取りたい」は subscription filter policy です。subscriber 側で全部受け取って捨てるより効率的です。

④Standard topic と FIFO topic

topic には Standard topic と topic があります。 Standard topic は高で一般的な pub/sub に向きます。 FIFO topic は、順序と重複排除が必要なメッセージ配信に使います。

Topic 種別特徴向いている用途
Standard topic高スループット、少なくとも 1 回配信、順序はベストエフォート多くの通知、イベント配信、fanout
FIFO topicメッセージグループ内順序、重複排除注文状態、決済、順序が重要な業務イベント

FIFO topic を使う場合、購読先も FIFO に対応した構成を選びます。 SNS FIFO topic から FIFO queue へ配信すると、順序を保った fanout パターンを作れます。 Standard topic から FIFO queue へ直接順序保証付きで配る、という考え方ではありません。

Point
  • FIFO = First-In, First-Out の略です。
  • 先に入ったメッセージを先に処理する考え方です。
  • SNS FIFO と SQS FIFO を組み合わせると、順序が重要なイベントを複数処理系へ配りやすくなります。
  • 和訳

FIFO topic では、message group ID が順序を保つ単位になります。 同じ message group ID のメッセージは順序を保ち、異なる message group ID は並列性を高められます。 順序が必要な粒度を正しく設計することが重要です。

⚠️ 頻出: 「複数 subscriber へ同じイベントを配りたいが順序も必要」は SNS FIFO topic + SQS FIFO queue を検討します。順序不要で高スループットなら Standard topic が基本です。

⑤配信再試行、DLQ、監視

は subscription ごとにメッセージ配信を試みます。 配信先の endpoint が一時的に失敗する場合、SNS は再試行します。 それでも配信できないメッセージを失わず調査したい場合は、subscription に dead-letter queue を設定します。

⑤配信再試行、DLQ、監視の図 成功 失敗・再試行超過 SNS Topic Subscription Endpoint 配信完了 SQS Dead-letter Queue 調査・再処理
機能用途試験での判断ポイント
Delivery retry一時的な配信失敗への再試行endpoint の一時障害に備えます。
Subscription 配信不能メッセージの隔離subscription 単位で DLQ を設定します。
Delivery status logging配信成功・失敗の可視化 Logs で配信状況を調査します。
CloudWatch metricsPublish 数、失敗数、DLQ などや運用監視に使います。

SNS の DLQ は topic ではなく subscription に設定します。 配信失敗は subscription 単位で発生するため、どの endpoint への配信に失敗したかを追跡しやすくなります。 DLQ には SQS queue を使います。

/S endpoint、、SQS、Email、SMS、Mobile Push など、配信先によって再試行や失敗時の挙動は異なります。 試験では、配信失敗を調査・再処理したいなら subscription DLQ、複数処理系のを高めたいなら SNS + SQS を考えます。

Point
  • DLQ = Dead-letter Queue の略です。
  • 配信や処理に失敗したメッセージを隔離するキューです。
  • SNS では subscription に DLQ を設定し、配信できなかったメッセージを SQS に保存します。

⚠️ 頻出: 「SNS から endpoint への配信失敗を後で調査したい」は subscription DLQ です。「subscriber の処理遅延を吸収したい」は SNS -> SQS の構成にします。

⑥セキュリティ、暗号化、アクセス制御

へのアクセスは ポリシーと topic policy で制御します。 Publisher には sns:Publish、管理者には topic 作成や subscription 管理の権限を付与します。 publish や AWS サービスからの publish では、topic policy で送信元を許可する設計が関係します。

観点関連機能判断ポイント
IAM policyユーザーやロールの操作権限publish、subscribe、管理操作をにします。
Topic policytopic 側のリソースベース制御クロスアカウントやサービス連携で使います。
保存時暗号化message body を キーで保護します。
通信経路の保護暗号化 topic では HTTPS と署名付きリクエストが必要です。
EndpointVPC から private に SNS へ到達インターネットを通らず publish したい場合に使います。
Data protection policy機密データの検出・保護 などの保護要件で検討します。

SNS のサーバー側暗号化は、topic 内に保存されるメッセージ本文を KMS で保護します。 Topic metadata、message metadata、 metrics などは暗号化対象ではありません。 SSE-KMS を使う場合、publisher や AWS サービスが KMS キーを使えるように、KMS キーポリシーと IAM 権限を確認します。

暗号化された SNS topic から暗号化された へ配信する場合も、KMS 権限が関係します。 SNS サービスプリンシパルが必要な KMS 操作をできないと、配信や DLQ 連携が失敗する可能性があります。

⚠️ 頻出: 「SNS topic を KMS で暗号化したのに publish できない」場合、sns:Publish だけでなく KMS キー権限とキーポリシーを確認します。

試験対策

SAA の 問題では、まず「1 つのイベントを複数の購読先へ配る必要があるか」を確認します。 複数 subscriber へ push 配信するなら SNS が候補です。 処理側が自分のペースで取り出すキューが必要なら 、複数の AWS サービス間イベントルーティングや 連携、イベントバスが必要なら も比較します。

SNS と SQS の組み合わせは頻出です。 SNS topic にイベントを publish し、複数の SQS queue が subscribe することで、各処理系が同じイベントを独立して処理できます。 処理遅延や一時障害は各 SQS queue に蓄積されるため、consumer ごとのスケーリングや を分けられます。

問題文のキーワード優先して考える機能理由
1 つのイベントを複数処理系へ配信SNS topicPub/sub で複数 subscriber に配れます。
複数処理系が独立して再試行SNS + SQS fanout各 queue が独自にバッファと DLQ を持てます。
購読先ごとに必要なイベントだけ受信Subscription filter policymessage attributes または body で配信を絞れます。
メールや SMS で通知SNS Email / SMS人への通知に使います。
をイベントで起動SNS -> LambdaTopic publish をきっかけに関数を実行できます。
配信失敗を後で調査Subscription DLQ配信不能メッセージを SQS に隔離できます。
順序保証付き fanoutSNS + SQS FIFOMessage group ID 単位で順序を保てます。
でメッセージを保護SNS Message body を保存時暗号化できます。
から private に publishInterface VPC Endpointインターネットを経由せず SNS に到達できます。
試験対策の図 はい いいえ はい いいえ はい いいえ はい いいえ SNS 設計問題 複数購読先へ配りますか? SNS Topic 処理待ちキューが必要ですか? SQS EventBridge などを検討 購読先ごとにバッファが必要ですか? SNS + SQS fanout SNS -> Lambda / HTTP / Email 受信メッセージを絞りますか? Subscription filter policy 全 subscriber に配信 配信失敗対策は? Subscription DLQ

よくある誤答は、SNS と SQS の役割を混同することです。 SNS はメッセージを配る pub/sub サービスです。 SQS はメッセージをためて consumer が取り出す queue サービスです。 「複数の subscriber 全員に届けたい」なら SNS、「複数 worker のうち誰か 1 つが処理すればよい」なら SQS が基本です。

EventBridge との比較では、SNS はシンプルな高 pub/sub や A2P 通知に向きます。 EventBridge はイベントバス、ルール、SaaS 連携、スキーマ、細かいイベントルーティングに向きます。 問題文に「メール通知」「SMS」「fanout to SQS」「複数 subscriber へ即時通知」があれば SNS を優先して考えます。

コスト面では、publish 数、配信数、endpoint 種別、SMS 配信、KMS 利用、データ転送、 Logs などが影響します。 SAA では具体的な料金暗記より、fanout、フィルタリング、DLQ、暗号化、購読先ごとのを押さえます。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください