ある企業では、シンプルなスケーリングポリシーを使用するAuto Scalingグループ内の3つのEC2インスタンスで実行されているワーカーアプリケーションでメッセージを処理しています。ワーカーはAmazon SQSキューからメッセージをポーリングします。メッセージの散発的な急増により処理パフォーマンスが低下しており、SysOps管理者は、より高いキューボリュームを処理するためにAuto Scalingグループをスケーリングする必要があります。この要件を最もよく満たすアプローチはどれですか？

このアプローチは、SQSキューの負荷に基づいてAuto Scalingグループを動的に調整するため、最も効果的です。CloudWatchメトリクス数式を使用して「インスタンスあたりの可視メッセージ数」を計算することで、各インスタンスが処理すべき作業量を正確に把握できます。このメトリクスに基づいてターゲット追跡スケーリングポリシーを設定すると、キューのメッセージ量が増加したときに自動的にインスタンスが追加され、処理能力が向上します。 他の選択肢は以下の理由で不適切です。 最も古いメッセージの経過時間：これはキューの遅延を示すものであり、処理能力のニーズを直接反映しません。 ALBRequestCountPerTarget：ワーカーアプリケーションはALBを介して直接リクエストを受け取らないため、このメトリクスは関連性がありません。 スケジュールされたスケーリングポリシー：メッセージの散発的な急増に対応できないため、動的な負荷変動には不向きです。