Q36 — AWS SAA-C03 第4章

第 36/105 問 | ← 第4章

Q231. ある企業の注文システムは、クライアントからAmazon EC2インスタンスへリクエストを送信します。EC2インスタンスは注文を処理した後、Amazon RDS上のデータベースに注文を保存します。ユーザーは、システム障害が発生した際に注文を再処理しなければならないと報告しています。この企業は、システム障害が発生した場合でも注文を自動的に処理できる耐障害性の高いソリューションを望んでいます。これらの要件を満たすために、ソリューションアーキテクトは何を行うべきでしょうか？

• A. EC2インスタンスをAuto Scalingグループに移動します。Amazon EventBridge（Amazon CloudWatch Events）ルールを作成し、Amazon Elastic Container Service（Amazon ECS）タスクをターゲットとして指定します。
• B. EC2インスタンスをApplication Load Balancer（ALB）の背後に配置されたAuto Scalingグループに移動します。注文システムを更新して、ALBのエンドポイントへメッセージを送信するようにします。
• C. EC2インスタンスをAuto Scalingグループに移動します。注文システムがAmazon Simple Queue Service（Amazon SQS）キューへメッセージを送信するように設定します。また、EC2インスタンスがキューからメッセージを消費するように設定します。 ✓
• D. Amazon Simple Notification Service（Amazon SNS）トピックを作成します。AWS Lambda関数を作成し、その関数をSNSトピックにサブスクライブします。注文システムがSNSトピックへメッセージを送信するように設定します。さらに、AWS Systems Manager Run Commandを使用して、EC2インスタンスに対しメッセージ処理を実行するコマンドを送信します。

正解: C. EC2インスタンスをAuto Scalingグループに移動します。注文システムがAmazon Simple Queue Service（Amazon SQS）キューへメッセージを送信するように設定します。また、EC2インスタンスがキューからメッセージを消費するように設定します。

解説

このシナリオでは、注文処理の失敗時に再処理が必要になるという課題があり、これは一時的な障害やEC2インスタンスの停止などによる処理のロストを示唆しています。耐障害性を高めるには、注文リクエストを一時的に保持・永続化できる非同期処理アーキテクチャが適しています。Amazon SQSは、メッセージの永続性・重複防止・可視性タイムアウトなどの機能により、処理中の失敗を検出し、再試行を可能にします。EC2インスタンスをAuto Scalingグループに配置し、SQSキューからメッセージをプルして処理することで、インスタンスの増減や障害にも柔軟に対応でき、注文のロストを防ぎます。選択肢AはECSタスクへの移行を提案していますが、問題文ではEC2ベースの処理を継続することが前提であり、またEventBridgeはイベント駆動型トリガーであり、注文処理の信頼性保証には不十分です。選択肢BはALB経由の同期通信であり、バックエンド障害時にクライアント側でタイムアウト・再送が発生し、再処理の原因となります。選択肢DはSNS＋Lambda＋Run Commandという複雑な連携となり、Run Commandは一時的なコマンド実行に適しており、継続的・スケーラブルな注文処理には不向きです。したがって、最も適切なのは選択肢Cです。