ピーク負荷を吸収する疎結合アーキテクチャ
受注システムでは、Web アプリが注文を直接バックエンドへ渡し、処理完了を待ってから応答しています。注文が集中するとバックエンドが追いつかず、タイムアウトで注文を取りこぼしています。バックエンドを常時ピークに合わせず急増を吸収したい場合、最も適切な対策はどれですか。
解説を読む（正解: A）
Amazon SQS は、メッセージの送信側と処理側の間にマネージドのキューを置いて両者を疎結合にするサービスです。受注のようにアクセスが急増する処理では、フロントエンドはキューへメッセージを投入した時点で利用者に応答を返せるため、バックエンドの処理速度に引きずられて詰まることがなくなります。キューはメッセージを保持し続けるので、ワーカー側は自分の処理能力に合わせてポーリングで取り出すことができ、キューに滞留しているメッセージ数をメトリクスとして Auto Scaling を働かせれば、必要なときだけワーカーを増やす運用もできます。よって A が正解です。B の Amazon SNS はパブリッシュ/サブスクライブ型の通知サービスで、メッセージを購読者へプッシュ配信するモデルであるため、購読者が処理しきれない分をキューとして貯めておき、後から自分のペースで取り出すというバッファリングの役割は本質的に担いません。C の AWS Step Functions は複数の処理ステップの流れを定義するオーケストレーションサービスであり有用ですが、フロントエンドから同期的に呼び出す構成では結局バックエンド処理の完了を待つことになり、負荷の平準化にはつながりません。D はピーク時と同じ台数を常時起動する案で、注文が少ない時間帯には大量の遊休リソースに対して費用が発生し続け、クラウドの伸縮性を活かせていないため適切ではありません。
マイクロサービス間の疎結合とリクエストの緩衝
マイクロサービス構成のシステムで、受付サービスがリクエストを即座に受け付けて応答を返し、後段の処理サービスが自身の処理能力に合わせて 1 件ずつ取り出し、処理が完了するまで保持したいと考えています。急増するリクエストを取りこぼさないために最も適した AWS サービスはどれですか。
解説を読む（正解: A）
分散システムでは、送信側と受信側の処理速度が一致しないことが常であり、両者を直接つなぐと受信側の能力を超えた瞬間にリクエストが失われます。Amazon SQS はこの問題を解決するフルマネージドのメッセージキューサービスで、送信側はキューにメッセージを入れた時点で応答を返せ、受信側は自分のペースでポーリングして取り出せます。メッセージは既定で最大 4 日間 (設定で最大 14 日間) 保持され、コンシューマーが取り出している間は可視性タイムアウトによって他のコンシューマーから見えなくなり、明示的に削除されるまで消えないため、処理中にワーカーが落ちても再配信されます。急増したトラフィックをキューが吸収するバッファとして働き、1 件ずつ確実に処理したいという要件にも合致するため、A が正解です。C の Amazon SNS はパブリッシュ/サブスクライブ型で、購読者に即座にプッシュ配信する仕組みです。購読者が処理しきれない状態を待って蓄えておく用途には向かず、ピーク吸収の緩衝装置にはなりません。B の AWS Step Functions は複数のステップからなる業務フローを状態遷移として定義・調整するオーケストレーションサービスであり、処理の順序制御は得意ですが、リクエストの急増を溜め込むキューではありません。D の Amazon EventBridge はイベントをルールに従って各ターゲットへルーティングするイベントバスで、こちらもプッシュ型であり、コンシューマー側が取得ペースを決めて 1 件ずつ引き取るというモデルではありません。
同期呼び出しの疎結合化とバックログの吸収
フロントエンドの API がバックエンドのワーカーを同期的に呼び出しているため、負荷が急増するとタイムアウトしてリクエストが失われます。順序は問われませんが、リクエストを失わず、ワーカーが自身のペースで取り出せるようにしたいです。最も運用負荷が低い設計はどれですか。
解説を読む（正解: A）
Amazon SQS は、送信側と受信側を切り離すフルマネージドのメッセージキューサービスです。送信側はキューにメッセージを置くだけで応答を返せるため、受信側の処理が滞っても送信側がブロックされたりタイムアウトしたりすることはありません。メッセージはキューに保持され、ワーカーは自分の処理能力に応じてポーリングで取り出し、処理が完了したら明示的に削除します。処理に失敗した場合は可視性タイムアウト経過後に再びキューに現れるため、リクエストの取りこぼしも防げます。順序が不要でバックログを吸収したいという要件に対して最小の運用負荷で応えられるので A が正解です。B の Amazon SNS はプッシュ型のパブリッシュ／サブスクライブサービスで、購読先へ即座に配信しようとします。購読側が処理しきれない状態でも押し込む形になり、キューのようにバックログを保持して消費者のペースで引き取る仕組みにはなりません。C の Kinesis Data Streams はリアルタイムのストリーミングデータを複数のコンシューマーで順序保証つきに処理する用途で、シャードの容量設計と管理が必要になり、単純なジョブのバッファリングとしては過剰であり運用負荷も高くなります。D はピークに合わせた台数を常時起動するもので、平常時に大量のアイドルリソースへ課金が発生し、しかも同期呼び出しのままなので疎結合化にはなりません。