SAP新しいソリューションのための設計
あるEコマース企業が、新しい注文確定パイプラインをAWSで設計します。フロントエンドは注文イベントを発行し、下流の在庫引当・課金・通知の各処理を行います。要件は次の通りです。
①同一顧客の注文は発生順に処理されなければならない、
②ネットワーク再送などで同じ注文イベントが重複到達しても二重課金が絶対に発生してはならない（exactly-once相当の重複排除）、
③ピーク時は秒間数千件のスループットが必要、
④下流処理の一時障害時はイベントを失わずリトライしたい。最小の運用負荷でこれらを満たすメッセージング基盤はどれですか。
AAmazon SNS標準トピックにイベントを発行し、複数のSQS標準キューをファンアウト購読、各コンシューマー側でDynamoDB条件付き書き込みにより重複排除と順序管理を実装する
SNS標準・SQS標準はいずれも順序保証と重複排除をサービス側で提供せず、順序・冪等性をすべてDynamoDBの条件付き書き込みで自前実装する必要がある。要件は満たし得るが運用負荷が最小という条件に反する。
BAmazon SQS FIFOキューを顧客IDをメッセージグループIDとして使用し、コンテンツベースの重複排除を有効化、高スループットモードを有効にしてコンシューマーから処理する
✓ 正解
FIFOキューはグループID単位で厳密な順序を保証し、顧客IDをグループIDにすれば同一顧客の順序処理と顧客間の並列を両立できる。コンテンツベース重複排除でexactly-once相当を実現し、高スループットモードで数千TPSも処理でき運用負荷も最小。
CAmazon Kinesis Data Streamsに注文IDをパーティションキーとして書き込み、コンシューマーで処理する。重複は各コンシューマーのアプリログで事後検知して手動補正する
Kinesisはパーティション単位の順序は保てるが、メッセージ重複排除の機能を備えておらず、重複をアプリログで事後検知し手動補正する方式では二重課金を確実に防げないため要件②を満たさない。
DAmazon SQS標準キューにイベントを送信し、可視性タイムアウトとデッドレターキューでリトライを担保、コンシューマーがタイムスタンプ順にソートしてから処理する
SQS標準は少なくとも1回配信で重複が発生し得るうえ順序はベストエフォートで、コンシューマー側のタイムスタンプソートではキュー全体の厳密な順序も重複排除も保証できないため要件①②を満たさない。
解説
SQS FIFOキューはメッセージグループID単位で厳密な順序を保証し、顧客IDをグループIDにすれば「同一顧客は発生順」を満たしつつ、異なる顧客は並列処理できます。
コンテンツベースの重複排除（または明示的なMessageDeduplicationId）により5分の重複排除ウィンドウ内で同一イベントの二重配信を防ぎ、exactly-once相当を実現します。
高スループットモードを有効にするとFIFOでも秒間数千件規模を処理でき、可視性タイムアウトとDLQで一時障害時のリトライ・損失防止も担保できます。マネージドサービスのみで完結するため運用負荷も最小です。
選択肢AのSNS標準＋SQS標準は順序保証も重複排除もサービス側になく、すべてDynamoDBで自前実装する必要があり運用負荷が高い。
選択肢CのKinesisはパーティション単位の順序は保てるが重複排除機能を持たず、事後検知・手動補正では二重課金を確実には防げない。
選択肢DのSQS標準はベストエフォート順序かつ少なくとも1回配信で重複が起こり得るうえ、コンシューマー側ソートではキュー全体の順序を保証できない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →