Q40 — AWS SAP-C02 第3章

第 40/75 問 | ← 第3章

Q265. ある企業が、現在ロードバランサ付きのAmazon EC2インスタンスファームでWebホスティング、データベースAPIサービス、およびビジネスロジックを実行している小売注文用Webアプリケーションをリファクタリングしようとしています。この企業は、疎結合でスケーラブルなアーキテクチャを構築し、失敗した注文を保持できる仕組みを備えつつ、運用コストを最小限に抑える必要があります。 これらの要件を満たすソリューションはどれですか？

正解: C. WebホスティングにはAmazon S3、データベースAPIサービスにはAWS AppSyncを使用します。注文キューにはAmazon Simple Queue Service (Amazon SQS) を使用し、ビジネスロジックにはAWS Lambdaを採用します。失敗した注文の保持には、Amazon SQSのデッドレターキュー (DLQ) を利用します。

解説

選択肢Cでは、WebホスティングにAmazon S3、データベースAPIサービスにAWS AppSyncを採用しています。これらはどちらもサーバーレスで、高いスケーラビリティを持ち、運用コストの削減に貢献します。注文キューにはAmazon SQSを用いることで、高可用性・耐久性に優れたメッセージングサービスを実現できます。ビジネスロジックにはAWS Lambdaを活用し、リクエスト数に応じて自動的にスケールするサーバーレス実行環境を提供します。また、失敗した注文の保持にはAmazon SQSのデッドレターキュー（DLQ）を用いるため、処理に失敗したメッセージを確実にキャプチャし、後続の再処理が可能になります。 選択肢Aでは、Amazon S3とAmazon API Gatewayに加え、ビジネスロジックにAmazon ECSを提案していますが、ECSはコンテナ管理に追加の運用複雑さを伴い、AWS Lambdaのようなサーバーレスアプローチよりも冗長です。選択肢Bでは、AWS Elastic BeanstalkをWebホスティングに用いていますが、これは管理されたサービスではありますが、Amazon S3やAWS AppSyncといった完全サーバーレス構成と比較するとコストが高くなる可能性があります。また、失敗注文の保持にAmazon S3 Glacier Deep Archiveを用いるのは、復元に長い時間がかかるため不適切です。選択肢Dでは、注文キューにAmazon SESを用いることは、メッセージの信頼性あるキューイングや失敗注文の保持という目的には不向きです。さらに、Amazon EKSは運用負荷が大きく、Amazon ESも失敗注文の保持という用途にはコスト効率が悪く、非推奨です。なお、本問においてAppSyncとAPI Gatewayの優劣は本質的ではなく、失敗注文の保持にはSQSのロングポーリングよりデッドレターキュー（DLQ）の方が適しています。ヒント：GraphQL API（AppSync）＋サーバーレス＋失敗注文用DLQへのリファクタリング。