Q58 — AWS SAA-C03 第14章

第 58/100 問 | ← 第14章

Q1058. ある企業は、顧客からの注文を処理する3層構成のWebアプリケーションを運用しています。Web層はApplication Load Balancerの後ろに配置されたAmazon EC2インスタンスで構成されています。処理層はEC2インスタンスで構成されています。同社は、Amazon Simple Queue Service（Amazon SQS）を用いてWeb層と処理層を非同期にデカップリングしました。ストレージ層にはAmazon DynamoDBを使用しています。ピーク時において、一部のユーザーから注文処理の遅延やハングが報告されています。同社は、これらの遅延発生時にEC2インスタンスのCPU使用率が100%に達し、SQSキューが満杯になっていることを確認しています。ピーク時のタイミングは変動的かつ予測不可能です。同社は、アプリケーションのパフォーマンスを向上させる必要があります。この要件を満たすソリューションはどれですか？

正解: D. Amazon EC2 Auto Scalingのターゲットトラッキングポリシーを活用し、処理層のインスタンス数を自動的に増加させます。スケーリングの判断基準としてSQSキューのApproximateNumberOfMessages属性を使用します。

解説

アプリケーションのパフォーマンスを向上させ、ピーク時の注文処理遅延および高CPU使用率の問題に対処するには、最も適したソリューションは以下の通りです： D. Amazon EC2 Auto Scalingのターゲットトラッキングポリシーを活用し、処理層のインスタンス数を自動的に増加させます。スケーリングの判断基準としてSQSキューのApproximateNumberOfMessages属性を使用します。 解説： 1. Auto Scalingのターゲットトラッキングポリシー： 　・ターゲットトラッキングスケーリングポリシーは、リアルタイムのメトリクスに基づいてAuto Scalingグループ内のEC2インスタンス数を自動調整します。これにより、需要の増加に応じて処理層が確実にスケールアウトできます。 2. ApproximateNumberOfMessagesの活用： 　・SQSキューのApproximateNumberOfMessages属性をスケーリング指標として使用することで、キュー内のメッセージ数が事前に定義したしきい値を超えた際に即座に処理層をスケールアウトできます。これはSQSキューのバックログ発生を直接解消し、注文処理の効率化に直結します。 3. 動的なスケーリング： 　・ピーク時が変動的かつ予測不可能であるため、実際のワークロードに基づく動的スケーリングが不可欠です。スケジュールによるスケーリングでは、突発的な負荷増加に迅速に対応できず、結果として処理遅延が発生します。 他の選択肢の検討： A. スケジュールによるAuto Scalingの利用： 　・ピーク時が予測不可能なため、スケジュールによるスケーリングは不適切です。需要の急増に即応できず、処理遅延を招く可能性があります。 B. Amazon ElastiCache for Redisの導入： 　・キャッシュはパフォーマンス向上に寄与しますが、処理層のCPU使用率過多やSQSキューのバックログという根本的な課題を解決しません。また、アーキテクチャの複雑化を招き、即時の課題解決にはつながりません。 C. Amazon CloudFrontディストリビューションの追加： 　・CloudFrontは主に静的コンテンツのキャッシュおよびWebアプリケーションのレイテンシー低減に有効ですが、処理層の注文処理能力不足という本質的な課題には一切対応しません。 結論： 選択肢Dは、実際の需要に基づいて処理層を動的にスケールアウトできる堅牢なソリューションであり、ピーク時のパフォーマンス問題およびSQSキューのバックログ管理を同時に解決します。