Q38 — AWS SAA-C03 第5章

第 38/65 問 | ← 第5章

Q338. ある企業が急速に成長しているフードデリバリーサービスを提供しています。この成長に伴い、注文処理システムがピーク時のトラフィック時間帯にスケーリングの問題を抱えています。現在のアーキテクチャは以下のとおりです。 ・アプリケーションから注文を受信するため、Amazon EC2 Auto Scalingグループで実行される一連のAmazon EC2インスタンス ・注文を履行（フルフィル）するため、別のAmazon EC2 Auto Scalingグループで実行される一連のAmazon EC2インスタンス 注文受付プロセスは高速ですが、注文履行プロセスには時間がかかります。また、スケーリングイベントによってデータが失われてはなりません。 ソリューションアーキテクトは、ピーク時のトラフィック時間帯において、注文受付プロセスと注文履行プロセスの両方が適切にスケールできるようにする必要があります。さらに、このソリューションは、企業のAWSリソースの利用効率を最適化しなければなりません。 これらの要件を満たすソリューションはどれですか？

正解: D. Amazon Simple Queue Service (Amazon SQS)キューを2つ作成します。1つは注文受付用、もう1つは注文履行用です。EC2インスタンスをそれぞれ対応するキューからメッセージをポーリングするように設定します。インスタンスあたりのバックログ（backlog per instance）を基にしたカスタムメトリクスを作成し、このメトリクスに基づいてAuto Scalingグループをスケールさせます。

解説

バックログ／インスタンス値がターゲット値に達すると、スケールアウトが発生します。たとえば、現在のバックログ／インスタンス値が150メッセージ（合計1,500メッセージ ÷ 10台の実行中インスタンス）である場合、Auto Scalingグループはこのターゲット値を維持するために5台分スケールアウトします。バックログ／インスタンスとは：SQSキューの長さ（キューから取得可能なメッセージ数）を示すApproximateNumberOfMessages属性の値を、Auto Scalingグループの実行中インスタンス数（InService状態のインスタンス数）で割った値です。オプションAは、CPU使用率に基づくスケーリングであり、ネットワーク遅延やディスクI/Oなどの他のボトルネック要因を無視し、非ピーク時における過剰なリソース確保（オーバープロビジョニング）を招く可能性があります。オプションBは、新たなAuto Scalingグループを動的に作成するという非効率なアプローチであり、実際の負荷と連動せず、リソース最適化に反します。オプションCはキューによるデカップリングを実現しますが、「キューからの通知」に基づくスケーリングは、SQSにはそのような通知機能は存在しないため技術的に不正確です。一方、オプションDは、SQSキューを活用して注文受付と履行を確実に分離し、バックログ／インスタンスという負荷に直接関連する意味のある指標に基づいてスケーリングを行うため、データ損失を防ぎつつ、リソース利用効率を最大化できます。したがって、このシナリオにおいて最も適切なソリューションはDです。