Q8 — AWS SAA-C03 第8章

第 8/65 問 | ← 第8章

Q503. ある企業が、AWS クラウド上に三層構成のECサイトアプリケーションをホスティングしています。同社はウェブサイトを Amazon S3 でホストし、販売リクエストを処理する API と統合しています。API は Application Load Balancer（ALB）の背後に配置された3台の Amazon EC2 インスタンス上で動作しており、静的および動的なフロントエンドコンテンツと、販売リクエストを非同期で処理するバックエンドワーカーから構成されています。同社は、新製品の発売イベント時に、販売リクエスト数が大幅かつ急激に増加すると予想しています。すべてのリクエストが正常に処理されるようにするために、ソリューションアーキテクトは何を推奨すべきでしょうか？

正解: D. 静的コンテンツ向けに Amazon CloudFront ディストリビューションを追加し、ウェブサイトからのリクエストを受信して EC2 インスタンスによる後続処理を行うために Amazon Simple Queue Service（Amazon SQS）キューを追加します。

解説

このシナリオでは、販売リクエスト（＝APIへのバックエンド処理リクエスト）が急増し、非同期で確実に処理される必要があります。静的コンテンツ（HTML、CSS、JavaScript、画像など）は Amazon S3 でホストされており、CloudFront を活用することでキャッシュ・配信効率が向上し、ALB／EC2 への負荷を軽減できます。一方、動的コンテンツ（APIリクエスト）は、単純なスケーリングだけでは突発的かつ急激な負荷変動に柔軟に対応しづらく、一時的な過負荷やリクエストの失敗リスクがあります。SQS を導入することで、リクエストをキューに一時保存し、バックエンドの EC2 ワーカーが自身の処理能力に応じて非同期で確実に処理できるようになります（プル型の非同期処理）。これは、スパイク時の可用性・耐障害性・スケーラビリティを高めるベストプラクティスです。選択肢A・Cは動的コンテンツへのCloudFront適用を提案していますが、CloudFrontは主にHTTP/HTTPSベースの静的・キャッシュ可能なコンテンツ向けであり、通常のAPI（特にPOST／状態変更を伴うリクエスト）には不適切です。選択肢BはAuto Scalingによるスケーリングを提案していますが、スパイクが「突然」かつ「短期間」である場合、起動遅延（インスタンス起動＋アプリケーション初期化）によりリクエストロスが発生する可能性があります。したがって、静的コンテンツの高速配信（CloudFront）と、動的リクエストの非同期バッファリング（SQS）を組み合わせた選択肢Dが最も適切です。