順序保証が必要なコンポーネント間メッセージング 証券会社の注文受付システムをマイクロサービス構成に刷新しています。受付サービスが生成した注文イベントを約定処理サービスへ非同期に引き渡しますが、同一口座の注文は必ず受け付けた順序どおりに、かつ重複なく 1 回だけ処理されなければなりません。処理が遅れた場合でもイベントが失われないよう、一時的に保持できる仕組みも必要です。この要件を満たすサービスを 1 つ選択してください。
A Amazon SES を利用して注文内容をメールとして約定処理サービスへ送信する B Amazon SNS の標準トピックを作成し、約定処理サービスをサブスクライブさせる C Amazon SQS の FIFO キューを利用し、口座 ID をメッセージグループ ID として送信する D Amazon SQS の標準キューを利用し、受信側でタイムスタンプ順に並べ替えてから処理する
解説を読む（正解: C） Amazon SQS の FIFO キューは、送信された順序どおりにメッセージを配信する先入れ先出しと、重複排除による「正確に 1 回の処理」を提供するキューサービスです。メッセージグループ ID の単位で厳密な順序が保証されるため、口座 ID をグループ ID にすれば同一口座の注文の前後関係を崩さずに処理でき、かつ異なる口座どうしは並行処理できてスループットも確保できます。キューはメッセージを保持するため、下流サービスが遅延しても失われません。したがって選択肢 C が正解です。選択肢 B の Amazon SNS 標準トピックはパブリッシュ/サブスクライブ型の通知サービスで、購読者への配信順序は保証されず、購読先が受け取れない場合のバッファとしても機能しにくいため要件を満たしません。選択肢 A の Amazon SES はメールの送受信を担うサービスであり、システム間の順序保証された内部メッセージングの用途には適しません。選択肢 D の SQS 標準キューはベストエフォートの順序付けかつ少なくとも 1 回の配信であるため、受信側でタイムスタンプ順に並べ替えても、未着メッセージを待つバッファリングや重複排除を自前で実装する必要があり、厳密な順序と一意性を保証できません。
SQS のメッセージ保持期間のデフォルト値 動画配信スタートアップが、投稿動画のトランスコードパイプラインをマイクロサービスに分割し、コンポーネント間の連携に Amazon SQS の標準キューを新規作成して利用する予定です。ワーカー側で障害や計画停止が発生した場合に備え、コンシューマーに処理されなかったメッセージがキュー上で 4 日間保持されることを保証したいと考えています。運用負荷を抑えるため、キューへの設定変更は必要最小限にとどめたいという方針もあります。この要件を満たす最適な Amazon SQS の設定はどれですか。
A メッセージ保持期間のデフォルトは 1 日であるため、キューの設定を変更して 4 日間へ延長する。 B Amazon SQS のデフォルト設定をそのまま利用する。 C デッドレターキューを設定し、4 日以上経過したメッセージをそこへ退避して保管する。 D キューの可視性タイムアウトを 4 日間に変更する。
解説を読む（正解: B） Amazon SQS のメッセージ保持期間（MessageRetentionPeriod）は、コンシューマーによって削除されなかったメッセージをキューが保持し続ける時間を指します。設定可能な範囲は 60 秒から 14 日間で、既定値は 4 日間です。ワーカーが一時的に停止していても、この期間内に復旧してメッセージを受信・削除すればデータが失われることはありません。
本シナリオの要件は「未処理のメッセージを 4 日間保持する」ことであり、これは新規に作成した SQS キューの既定値とまったく同じです。したがって追加の設定変更を行う必要はなく、B のようにデフォルト設定のまま利用するのが最も適切です。
A は「メッセージ保持期間の既定値が 1 日である」という誤った前提に基づいており、実際には延長操作そのものが不要です。C のデッドレターキューは、受信回数が maxReceiveCount を超えても処理に成功しなかったメッセージを隔離し、原因調査を行うための仕組みであって、保持期間を延ばす機能ではありません。しかもデッドレターキューへ移動したメッセージの保持期間は、元のキューへ登録された時刻から起算されるため、保管期間の延長には使えません。D の可視性タイムアウトは、あるコンシューマーが受信したメッセージを他のコンシューマーから一時的に見えなくする時間であり、保持期間とは別の概念です。設定できる最大値も 12 時間なので、そもそも 4 日を指定することはできません。
SQS を使ったリクエストの優先度制御 遠隔読影サービスを提供する医療スタートアップでは、提携病院から届く読影依頼を EC2 のワーカーインスタンス群がバックグラウンドで処理しています。依頼には救急外来から届く「緊急」区分と、人間ドックから届く「通常」区分の 2 種類があり、緊急区分は通常区分より必ず先に処理を開始しなければなりません。ワーカーの台数には上限があるため、繁忙時間帯には未処理の依頼が大量に滞留します。この優先度制御をマネージドサービスで実現する方法として最も適切なものを 1 つ選択してください。
A Amazon SQS の標準キューを 1 本だけ作成し、緊急依頼のメッセージにメッセージ属性で優先度を付与して、ワーカーが受信後に優先度の高いものから処理する B 緊急依頼用と通常依頼用に Amazon SQS のキューを 2 本作成し、ワーカーは常に緊急キューを先にポーリングし、そこが空だったときにだけ通常キューをポーリングする C Amazon Route 53 の加重ルーティングポリシーで緊急依頼の送信先に大きな重みを設定し、通常依頼より多くのワーカーへ振り分ける D Amazon SNS のトピックを 1 つ作成し、緊急依頼を先に発行することでサブスクライバーへの配信順序を優先度どおりに保証する
解説を読む（正解: B） Amazon SQS は送信側と処理側を切り離すフルマネージドのメッセージキューですが、1 本のキューの中でメッセージを優先度に応じて並べ替える機能は持っていません。標準キューの順序はベストエフォートであり、FIFO キューで保証されるのも投入順であって優先度順ではありません。そのため AWS が推奨する優先度制御のパターンは「優先度ごとにキューを分離する」ことです。正解の選択肢では緊急用と通常用の 2 本のキューを用意し、ワーカーは必ず緊急キューを先にポーリングし、空だったときにだけ通常キューを処理します。これにより緊急依頼は滞留している通常依頼を追い越して即座に処理され、ワーカー台数が限られていても優先度の逆転が起きません。A は誤りです。メッセージ属性を付けても SQS 自身は並べ替えを行わず、ワーカーが受信できるのはキューの先頭付近のメッセージに限られるため、通常依頼が大量に溜まっていると緊急依頼を受信できるまで待たされます。C も誤りです。Route 53 の加重ルーティングは DNS 応答の返却割合を制御する仕組みであり、すでにキューに溜まっているジョブの処理順序には一切影響しません。D も誤りです。Amazon SNS はプッシュ型のパブリッシュ/サブスクライブサービスで、メッセージのバッファリングも処理順の制御も行わず、サブスクライバー側が処理しきれない場合の滞留吸収ができません。