ある企業が、Application Load Balancer の背後にある EC2 インスタンスで社内ブラウザベースのアプリケーションを実行しています。インスタンスは複数のアベイラビリティーゾーンにまたがる Auto Scaling グループに属しています。グループは勤務時間中に 20 インスタンスまでスケールアップし、夜間は 2 インスタンスまでスケールダウンします。従業員は、午前中には問題なく動作するものの、一日の始まりにはアプリケーションが非常に遅いと報告しています。コストを低く抑えながら、この苦情に対処するためにスケーリングをどのように変更すべきですか？

このシナリオでは、アプリケーションの遅延は、勤務開始時のインスタンス不足が原因で発生しています。ターゲット追跡スケーリングポリシーは、CPU使用率などの特定のメトリクスを目標値に維持するようにAuto Scalingグループの容量を調整します。より低いCPUしきい値でトリガーするように設定することで、需要が増加し始める前にインスタンスがプロビジョニングされ、アプリケーションの応答性が向上します。クールダウン期間を短縮することで、スケーリングアクションがより迅速に実行され、需要の変化に素早く対応できます。 他の選択肢は、この問題を効果的に解決できません。スケジュールアクションは、需要の予測可能なパターンには適していますが、需要の変動に柔軟に対応できません。特に、最小および最大キャパシティを20に設定するスケジュールアクションは、夜間のコスト削減の目的と矛盾します。ステップスケーリングは、ターゲット追跡よりも設定が複雑で、最適なパフォーマンスを維持するための調整が難しい場合があります。