Q54 — AWS SAA-C03 第17章

第 54/89 問 | ← 第17章

Q1354. メディア出版会社が、ユーザーが自身の書籍を印刷できるアプリケーションをAWS上で構築しています。アプリケーションのフロントエンドはDockerコンテナで実行されます。注文の流入量は大きく変動し、一時的に会社の書籍印刷機の処理能力を超えることがあります。注文処理のペイロードは最大4 MBです。同社は、流入する注文をスケーラブルに処理できるソリューションを開発する必要があります。この要件を満たすソリューションはどれですか？

正解: C. Amazon SQS を使用して流入注文をキュー化します。注文処理用の AWS Lambda 関数を作成します。フロントエンドアプリケーションを、AWS Fargate 起動タイプを使用した Amazon ECS 上にデプロイします。

解説

正解は C です。「Amazon SQS を使用して流入注文をキュー化します。注文処理用の AWS Lambda 関数を作成します。フロントエンドアプリケーションを、AWS Fargate 起動タイプを使用した Amazon ECS 上にデプロイします。」 理由： 要件は以下の通りです。 ・流入注文量の変動に対応可能なスケーラブルなソリューション。 ・印刷機の処理能力を超える注文を受付可能（注文受付と処理の非同期・分離）。 ・注文ペイロードは最大4 MB（メッセージサイズ制限への配慮が必要）。 ・フロントエンドはDockerコンテナで実行（コンテナベースのデプロイメント）。 選択肢Cが正しい理由： ・Amazon SQS（Standard Queue）： 　– 注文受付と処理を分離：需要が印刷能力を超えた場合でも注文をキューにためられます。 　– 変動するトラフィックへの対応：自動的にスケールし、大量の注文を処理可能です。 　– メッセージサイズ：標準では256 KBまでですが、SQS Extended Clientライブラリを使えば最大2 GBまで対応可能。また、4 MBのペイロードについては、S3に保存した後、SQSメッセージ内にそのS3オブジェクトURLを含める方法も有効です。 ・AWS Lambdaによる注文処理： 　– サーバーレスな自動スケーリング：SQSキューから注文を自動的に取得・処理できます。 　– コスト効率：実際の実行時間のみ課金されるため、コスト最適化に寄与します。 ・Amazon ECS（AWS Fargate起動タイプ）によるフロントエンドデプロイ： 　– Dockerコンテナ対応：ECS + Fargateは、完全マネージド型のコンテナオーケストレーションサービスです。 　– スケーラビリティ：EC2インスタンスの管理不要で、Fargateが自動的にスケールします。 他の選択肢が不適切な理由： A：Lambda@EdgeはCloudFront CDN上のエッジロケーションで実行されるものであり、バックエンドの注文処理には不適切です。また、Amazon EKSはKubernetes基盤であり、本ユースケースでは過剰な複雑さ（Fargate単体で十分）です。 B：AWS Fargateは、ECSまたはEKSと組み合わせてコンテナを実行するサービスであり、単体でSQSメッセージを処理することはできません。SQSからのトリガーはLambdaが担当し、フロントエンドのデプロイ先はECS/EKS＋Fargateである必要があります。 D：Amazon SNSはプッシュ型のPub/Subサービスであり、キュー機能を持たないため、サブスクライバーが一時的に利用不可の場合に注文が失われるリスクがあります。また、Lambda@Edgeは注文処理に不適切であり、Amazon EC2は手動でのスケーリングが必要なため、変動するワークロードへのスケーラビリティ要件を満たしません。 重要な検討事項： ・SQS vs. SNS：SQSは生産者と消費者を分離し、メッセージの永続性を保証するキューです。一方、SNSは複数のサブスクライバーへメッセージを配信するプッシュ型サービスであり、順序保証や再試行メカニズムがありません。注文処理という信頼性と順序性が求められる用途では、SQSが適切です。 ・4 MBという大規模ペイロードへの対応：SQSの標準メッセージサイズ上限は256 KBですが、S3にペイロードを保存し、SQSメッセージにはそのS3 URLを格納する方法や、SQS Extended Clientライブラリの活用により対応可能です。 ・フロントエンドのデプロイ：Dockerコンテナをサーバー管理なしで実行するには、Amazon ECS＋Fargateが最もシンプルかつ適切です。EKSはKubernetes特有の機能が必要な場合に限られ、EC2はスケーリングの手間と運用負荷が大きいため不適切です。 結論： 選択肢Cは、以下のすべての要件を満たす唯一のソリューションです。 ・SQSによる受付／処理の分離とスケーラビリティ。 ・Lambdaによるサーバーレスな注文処理。 ・ECS＋FargateによるスケーラブルなDockerフロントエンド。 他の選択肢は、サービスの誤用（Lambda@Edge、SNS）やスケーラビリティ不足（EC2）といった点で要件を満たしません。