SAA弾力性に優れたアーキテクチャの設計
あるオンラインメディア企業では、フロントエンドの EC2 インスタンス群が、画像変換を行うバックエンドの EC2 インスタンス群を同期的に HTTP で呼び出しています。キャンペーン時にリクエストが急増するとバックエンドが過負荷となり、タイムアウトやリクエストの消失が発生します。処理順序は重要ではなく、急増を吸収しつつリクエストを失わない疎結合な構成に変更したいと考えています。最も適切な構成はどれですか。
Aフロントエンドとバックエンドの間に Amazon SQS 標準キューを配置し、バックエンドはキューをポーリングして処理し、キュー長に応じて Auto Scaling でスケールする
✓ 正解
標準キューがリクエストをバッファリングしてフロントエンドとバックエンドを非同期に分離するため、急増を吸収しメッセージ消失を防げます。バックエンドはキュー長に応じた Auto Scaling で追従でき、順序不問のため標準キューが最適です。
Bフロントエンドとバックエンドの間に Amazon SNS トピックを配置し、バックエンドをサブスクライバーとして登録してリクエストをプッシュ配信する
SNS はプッシュ型でメッセージを永続的にバッファリングしないため、過負荷のバックエンドへ配信が集中して保護できず、配信失敗時にリクエストが失われるため、急増吸収と消失防止の要件を満たせません。
Cバックエンドの EC2 インスタンスタイプをより大きなものに変更し、垂直スケーリングで瞬間的な処理能力を高める
垂直スケーリングはインスタンスサイズの上限があり同期結合も解消されないため、想定を超える急増ではバックエンドが過負荷となりリクエストを失う可能性があり、疎結合化という要件にも応えていません。
Dフロントエンドとバックエンドの間に Application Load Balancer を追加し、同期リクエストを複数のバックエンドへ均等に分散する
ALB はリクエストを分散しますが同期呼び出しのままでバッファ機能を持たないため、全バックエンドが処理能力を超えればタイムアウトやリクエスト消失が発生し、急増を吸収する疎結合構成にはなりません。
解説
Amazon SQS 標準キューをフロントエンドとバックエンドの間に挟むことで両者を非同期に疎結合化し、急増したリクエストをキューにバッファリングして消失を防ぎます。
バックエンドは自身の処理能力に応じてポーリングでき、キュー長（ApproximateNumberOfMessagesVisible）をメトリクスにした Auto Scaling で需要に追従します。処理順序が重要でないため標準キューが適します。
選択肢Bの SNS はプッシュ型でメッセージを保持・バッファリングしないため、過負荷時にバックエンドを保護できず消失も防げない。
選択肢Cの垂直スケーリングは同期結合のままで上限があり、急増時にリクエストを失う。
選択肢Dの ALB は分散するだけで同期呼び出しのままバッファがなく、全バックエンドが過負荷になればリクエストを失う。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →