Q78 — AWS SAA-C03 第10章
第 78/100 問 | ← 第10章
Q678. ソーシャルメディア企業が、ユーザー向けのリワードプログラムWebサイトを構築しています。このサイトでは、ユーザーが動画を作成・アップロードするとポイントが付与されます。ユーザーは獲得したポイントを、提携パートナー企業が提供するギフトや割引と交換できます。各ユーザーは一意のIDで識別され、パートナー企業はこのIDを用いて、ユーザーがリワードを受ける資格があるかを確認します。パートナー企業は、ユーザーにポイントが付与された際に、HTTPエンドポイント経由でそのユーザーIDを通知してほしいと要望しています。毎日、数百社のベンダーが提携パートナーとして登録を希望しています。企業は、Webサイトがパートナーを迅速かつスケーラブルに追加できるアーキテクチャを設計したいと考えています。これらの要件を満たすうち、実装工数が最も少ないソリューションはどれですか?
- A. Amazon Timestreamデータベースを作成し、提携パートナーの一覧を保持します。AWS Lambda関数を実装してこの一覧を読み取り、ユーザーにポイントが付与された際に各パートナーへユーザーIDを送信するように設定します。
- B. Amazon Simple Notification Service(Amazon SNS)トピックを作成します。エンドポイントプロトコルを選択し、パートナーをこのトピックにサブスクライブさせます。ユーザーにポイントが付与された際に、ユーザーIDをこのトピックにパブリッシュします。 ✓
- C. AWS Step Functionsのステートマシンを作成します。各提携パートナーごとにタスクを作成します。ユーザーにポイントが付与された際に、ユーザーIDを入力としてこのステートマシンを起動します。
- D. Amazon Kinesis Data Streamsにデータストリームを作成します。プロデューサーおよびコンシューマーのアプリケーションを実装し、提携パートナーの一覧をこのデータストリームに保存します。ユーザーにポイントが付与された際にユーザーIDを送信します。
正解: B. Amazon Simple Notification Service(Amazon SNS)トピックを作成します。エンドポイントプロトコルを選択し、パートナーをこのトピックにサブスクライブさせます。ユーザーにポイントが付与された際に、ユーザーIDをこのトピックにパブリッシュします。
解説
ユーザーにポイント付与時に提携パートナーにユーザーIDをHTTPエンドポイント経由で通知し、日々数百社規模でパートナーを迅速かつスケーラブルに追加できるアーキテクチャを実現するには、実装工数が最も少ないソリューションは、選択肢Bです:Amazon Simple Notification Service(Amazon SNS)トピックを作成し、適切なエンドポイントプロトコルを選択してパートナーをトピックにサブスクライブさせ、ポイント付与時にユーザーIDをトピックにパブリッシュします。Amazon SNSは、完全マネージド型のプッシュ/サブスクライブ型メッセージングサービスであり、複数の受信者へさまざまなプロトコルや配信メカニズムを用いた通知を簡素化します。具体的な流れは以下の通りです:\1.SNSトピックの作成:企業は中央集約型の通知ハブとして機能するSNSトピックを作成します。これはAWSマネジメントコンソール、またはAWS SDK/APIを用いて容易に作成可能です。\2.エンドポイントプロトコルの選択:パートナーが通知を受信するためのプロトコル(HTTP/HTTPS、メール、SMSなど)を選択します。本ケースでは、ユーザーIDを送信するためHTTPエンドポイントが適しています。\3.パートナーのトピックへのサブスクライブ:ユーザーIDの通知を希望するパートナーは、AWSマネジメントコンソール、SDK、またはAPIを用いて動的にSNSトピックにサブスクライブします。各パートナーは自身のエンドポイントURLを指定し、選択したプロトコルで通知を受け取ります。\4.ユーザーIDのトピックへのパブリッシュ:ユーザーにポイントが付与された際、WebサイトはAWS SDK/APIを用いて該当ユーザーIDをSNSトピックにパブリッシュします。SNSは自動的に全サブスクライバーへ通知を配信し、それぞれの指定エンドポイントにユーザーIDを転送します。Amazon SNSを活用することで、複雑なセットアップや運用管理を必要とせず、パートナーを即座に追加できます。パートナー側も簡単にサブスクライブでき、自身の選好するプロトコルでユーザーIDを受信可能です。このソリューションは、スケーラビリティ、柔軟性、およびパートナー通知の簡易性を兼ね備えています。他の選択肢は、実装工数という観点で最適ではありません:A.Amazon Timestreamデータベースの構築と、パートナー一覧を読み取るLambda関数の実装には追加の設定・管理工数がかかり、パートナーへの直接通知機能も提供しません。C.AWS Step Functionsのステートマシンを構築し、各パートナーごとにタスクを定義するのは、実装・管理の複雑度が高く、過剰な工数を要します。D.Amazon Kinesis Data Streamsのデータストリーム構築、プロデューサー/コンシューマーのアプリケーション開発、パートナー一覧のストリーム内保管などは、本ユースケースには不必要な複雑さとオーバーヘッドを導入します。したがって、正解はBです。