助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)

問題ID : 30612

ある企業では、食材配達の注文システムを設計している。
第1段階の処理は、ユーザーから注文が入ると決済を行う。第2段階の処理は、決済完了後、食材を配達スタッフへ伝達する処理と、注文内容をデータベースへ登録する処理がある。伝達処理とデータベースへの登録処理は並列して行いたい。
注文は必ず受注した通りに処理されなければならず、また、複数回処理されてはならない。
本システムの要件を満たすには、どのサービスを採用するのがよいか（2つ選択）。

Amazon SNS FIFOトピック

Amazon SNS 標準トピック

Amazon SQS FIFOキュー

Amazon SQS 標準キュー

Amazon Kinesis Data Streams

正解

Amazon SNS FIFOトピック

Amazon SQS FIFOキュー

解説

Amazon SNSはフルマネージドのメッセージングサービスです。「メッセージ」とはシステム間を連携する通知やデータのことで、EメールやSMS、Lambda関数、Amazon SQSを通して、複数のアプリケーションやユーザーに対して同時にメッセージを配信します。Amazon SNSはプッシュ型なので、サブクライバー（購買者）の状態に関わらずメッセージを配信します。

Amazon SQSはフルマネージドのメッセージキューイングサービスです。「メッセージキューイング」とは個々のサービスやシステムをメッセージを使用して連携する仕組みのことで、サービス同士の橋渡しを担います。Amazon SQSはプル型なので、受信側の都合の良いタイミングでSQSへポーリング（問い合わせ）を行って、メッセージを受け取ります。

SNSでは「FIFOトピック」を作成できます。SNS 標準トピックではメッセージの配信順序は考慮されませんが、「SNS FIFOトピック」ではメッセージが順序付けられて「SQS FIFOキュー」に配信されます。メッセージが必ず1回だけ配信されるようになるので、順序付きの処理や重複を避ける必要があるケースで使用します。なお、FIFO（First In First Out）とは「先入れ先出し」の意味で、メッセージを受け取った順番に配信します。

本設問のケースでは、
・第1段階の決済処理の完了後に、第2段階の処理を行う
・第2段階の2つの処理（伝達処理とデータベース登録処理）は並列で行う
という点から、SNSとSQSによる連携処理を行うのが適切です。
また、
・注文は必ず受注した順番で処理する
・複数回処理されてはならない（重複排除）
という要件から、SNSのFIFOトピックと、SQSのFIFOキューを採用します。

以上より正解は
・Amazon SNS FIFOトピック
・Amazon SQS FIFOキュー
です。

その他の選択肢については以下の通りです。

・Amazon SNS 標準トピック
・Amazon SQS 標準キュー
SNSの標準トピック、SQSの標準キューでは、処理するメッセージの順序性が保証されません。また、メッセージの重複排除も搭載されていないため、同じ注文を複数回処理してしまう可能性があります。
本設問の要件に適していないので、誤りです。

・Amazon Kinesis Data Streams
IoTデバイスなどから送信されるストリーミングデータを収集するサービスです。
本設問の要件であるメッセージの受理や仲介を行うサービスではないので、誤りです。

参考

【Amazon Simple Notification Service（SNS）】
Amazon Simple Notification Service（SNS）はフルマネージドのメッセージングサービスです。「メッセージ」とはシステム間を連携する通知やデータのことで、EメールやSMS、Lambda関数、Amazon SQSを通して、複数のアプリケーションやユーザーに対して同時にメッセージを配信します。Amazon SNSはプッシュ型なので、サブクライバー（購買者）の状態に関わらずメッセージを配信します。

利用できる通知方法（プロトコル）には、Eメール、HTTP/HTTPSやモバイル（iOS、Android）端末へのプッシュ通知などがあります。
なお、SNSはほぼ無制限にスケーリングできるため、突発的にメッセージが増加した場合にも対応できます。

■SNSのユースケース
SNSのユースケースには以下のようなものがあります。
○複数ユーザーに対して一斉に通知を行うケース
新サービスやメンテナンスなどのお知らせがある場合、SNSを利用して複数の購読者（ユーザー）へ一斉に通知できます。

○イベントの発生を契機にリアルタイムで処理を行いたいケース
プッシュ通知はイベントが発生したことをリアルタイムに通知できます。例えばCloudWatchで異常を検知したら即座に通知したい場合や、商品の納入や搬出などのイベントをトラッキングして次の処理を起動させたいケースなどで活用できます。

○システム内のコンポーネントを低い結合度（疎結合）で連携するケース
メッセージの発行者は、購読者がどのようなプロトコルでメッセージを受け取るのか、どんな購読者がいるのかなどを意識せずにメッセージを発行できます。新たに購読者を増やしても発行者への影響はありませんので、コンポーネント間の結合度を低く（疎結合に）システムを構築できます。

○複数のコンポーネントで並列に処理を行うシステム
1つのメッセージを複数の購読者（コンポーネント）が受信できますので、例えばユーザーの画像投稿を契機に、データベースへ登録する処理、サムネイルを作成する処理、画像を解析する処理など、独立したそれぞれの処理を並列に進めるようなシステムを実装できます。

■SNSのしくみ
SNSは以下のような仕組みになっています。

SNSにおける情報の単位は「トピック」で管理されます。
トピック所有者（トピックオーナー）が作成したトピックに対して、「発行者（Publisher：パブリッシャ）」がメッセージを発行します。メッセージの受信者は「購読者（Subscriber：サブスクライバ）」といい、得たい情報のトピックを選択して受信登録します。

・発行者（Publisher）
発行者（Publisher）は、Amazon SNSにおけるメッセージを発信するアプリケーションなどです。発行者はメッセージを発行したいトピックを選択してメッセージを配信します。購読者の存在やプロトコルの種類などは意識する必要はありません。
以下はマネジメントコンソールからメッセージを発行する画面の例です。

・購読者（Subscriber）
メッセージを受け取る（購読する）アプリケーションやユーザーです。購読者は通知を得たいトピックに対してプロトコルを選択して登録します。
以下は実際のサブスクリプション（購読）の登録画面です。

■トピックの種類
SNSでトピックを作成する際には「FIFO（First In First Out）」または「標準（スタンダード）」のいずれかを選択します。
「FIFO」を選択すると、「標準」の機能である暗号化やフィルタリング機能などに加えて、メッセージが順序付けられてAmazon SQSのFIFOキューへ配信されます（FIFOトピックを選択した場合、プロトコルに指定できるのはSQSのみです）。また、FIFOトピックではメッセージの重複排除機能を有効化できます。標準トピックではメッセージの配信は「少なくとも1回」であるのに対して、重複排除を有効にすると、メッセージは必ず1回だけ配信されるようになります。
FIFOトピックは、イベントが発生した順番通りに処理したい場合や、処理が重複してはいけないようなケースで利用します。
※Amazon SQSの詳細は、分野「SQS」を参照してください。

■トピックの例
SNSトピックの例としては、Amazon CloudWatchで監視しているリソースの状態に応じてメールで通知させるケースがあります。
予めSNSでトピックを作成しておき、CloudWatch Events（EventBridge）のマネジメントコンソールから作成したトピックを選択します。

上述の例ではEC2インスタンスの状態が変化した際に通知するように設定していますので、例えば起動中のインスタンスが終了すると購読者には以下のように通知されます（メール通知の例）。

■配信失敗時のSQSデッドレターキューの利用
SNSでは、SNSトピックからメッセージの配信に失敗した場合、通常はメッセージを破棄してしまいます。メッセージの破棄を防ぐには、配信不能メッセージをAmazon SQSのデッドレターキューに送信するようにサブスクリプションを設定します。
例えばサブスクリプションがLambda関数の場合、デッドレターキューに保持されたメッセージをLambda関数がポーリングすることで、SNSトピックから配信された全てのメッセージがLambda関数で処理されるようになります。