SAP新しいソリューションのための設計
あるEコマースSaaS企業は、チェックアウト処理を担うマイクロサービスから注文確定イベントを在庫管理サービスへ連携しています。現在はイベントを非同期メッセージングで受け渡していますが、稀にメッセージが重複配信され、同一注文で在庫が二重に引き当てられる障害が発生しています。要件として、(1) 同一顧客の注文は発生順に処理されること、(2) 重複配信があっても在庫引き当ては一度だけ行われること、(3) スループットは顧客ごとに分散され、全体で高いピークにも耐えることが求められます。この要件を最も確実に満たす設計はどれですか。
A注文イベントを Amazon Kinesis Data Streams へ送信し、パーティションキーに顧客IDを指定してシャード内の順序を保証する。Lambda コンシューマーがシーケンス番号でチェックポイントを記録し、処理済みイベントを再取得しないよう制御する
Kinesis Data Streams はシャード内順序を保証するものの配信は at-least-once であり、リシャードや再処理で重複が発生し得る。シーケンス番号のチェックポイントは進行管理であって冪等性を保証せず、二重引き当てを確実には防げない。
B注文イベントを Amazon SQS FIFO キューへ送信し、メッセージグループIDに顧客IDを指定して顧客単位の順序を保証する。コンテンツベースの重複排除を有効化し、消費側は Amazon DynamoDB の条件付き書き込みで冪等キーを管理する
✓ 正解
FIFO キューのメッセージグループID（顧客ID）で顧客単位の順序と並列分散を両立し、コンテンツベース重複排除と DynamoDB 条件付き書き込みの冪等制御を重ねることで、順序・一度だけの引き当て・分散スループットの3要件をすべて確実に満たす。
C注文イベントを Amazon SNS FIFO トピックへ発行し、複数の標準 Amazon SQS キューへファンアウトする。各消費サービスが独立にポーリングし、可視性タイムアウトを延長することで同一メッセージの重複処理を回避する
SNS FIFO から標準 SQS キューへファンアウトすると配信先での順序保証・重複排除が失われる。可視性タイムアウトの延長は処理中の再配信を遅らせるだけで重複配信そのものを排除できず、二重引き当てを防げない。
D注文イベントを Amazon SQS 標準キューへ送信し AWS Lambda で処理する。可視性タイムアウトを処理時間の3倍に設定し、Amazon DynamoDB の TTL テーブルに処理済みIDを保存して一定期間の重複を抑止する
SQS 標準キューはベストエフォート順序で要件(1)の発生順処理を満たせない。可視性タイムアウトの調整は重複配信を防ぐ仕組みではなく、DynamoDB による抑止はあるが順序要件を満たさない点で不十分である。
解説
SQS FIFO キューはメッセージグループID単位で厳密な順序を保証し、異なるグループID（顧客ID）は並列処理されるため、顧客単位の順序保証とスループットの分散を同時に満たせます。5分間のコンテンツベース重複排除に加え、消費側で DynamoDB の条件付き書き込み（属性の非存在チェック）による冪等キー管理を行うことで、重複配信があっても在庫引き当てを一度だけに限定できます。順序・重複排除・分散スループットの3要件を最も確実に満たす構成です。
選択肢の Kinesis Data Streams はシャード内順序を保証しますが at-least-once 配信のため重複が起こり得るため、チェックポイントだけでは二重引き当てを防げない。
選択肢の SNS FIFO からのファンアウト先が標準 SQS キューだと FIFO の順序・重複排除特性が失われ、可視性タイムアウトの延長は重複排除の代替にならない。
選択肢の SQS 標準キューは順序保証がなく要件(1)を満たせず、可視性タイムアウトの調整も重複配信自体を防ぐものではない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →