Q36 — AWS SAA-C03 第7章

第 36/65 問 | ← 第7章

Q466. ある会社が、内部で利用するブラウザベースのアプリケーションを運用しています。このアプリケーションは、Application Load Balancer の後ろで Amazon EC2 インスタンス上で動作しており、複数の可用性ゾーンにまたがる Amazon EC2 Auto Scaling グループ内で実行されています。Auto Scaling グループは、業務時間中には最大 20 台までスケールアップしますが、夜間は 2 台までスケールダウンします。従業員から、1 日の始まりにアプリケーションの応答が非常に遅く感じられるという苦情が寄せられています（ただし、午前中半ば以降は正常に動作します）。従業員の苦情に対処しつつ、コストを最小限に抑えるためには、スケーリング設定をどのように変更すべきでしょうか？

• A. オフィスの営業開始直前に、希望容量（desired capacity）を 20 に設定するスケジュールされたアクションを実装する。 ✓
• B. より低い CPU 使用率しきい値でトリガーされるステップスケーリングアクションを実装し、クールダウン期間を短縮する。
• C. より低い CPU 使用率しきい値でトリガーされるターゲットトラッキングアクションを実装し、クールダウン期間を短縮する。
• D. オフィスの営業開始直前に、最小容量および最大容量をともに 20 に設定するスケジュールされたアクションを実装する。

正解: A. オフィスの営業開始直前に、希望容量（desired capacity）を 20 に設定するスケジュールされたアクションを実装する。

解説

本問は、選択肢 A と C のどちらが最適かについて議論がある問題です。業務開始時の急激な負荷増加に対応し、コストを最小限に抑えつつ応答性を確保するには、事前にインスタンス数を増やす「予防的（プロアクティブ）」なアプローチが最も効果的です。各選択肢を検討します： A：オフィス営業開始直前に希望容量を 20 に設定するスケジュールアクションは、需要のピーク到来前に必要なインスタンスを確実に起動させます。これにより、Auto Scaling による段階的なスケールアップ待ちによる初期遅延を回避でき、問題の根本原因を直接解決します。 B：ステップスケーリングは、CPU 使用率などのメトリクスに基づく「反応的（リアクティブ）」なスケーリングであり、しきい値に達するまで待機するため、開始直後の遅延を防げません。クールダウン期間の短縮は、メトリクスの急激な変動時に過剰なスケーリングを引き起こすリスクがあります。 C：ターゲットトラッキングも同様にリアクティブなスケーリングであり、目標値（例：CPU 使用率）を維持するために自動調整しますが、需要の急増に対して即時対応できないため、初動の遅延は解消されません。クールダウン期間の短縮も同様のリスクを伴います。 D：最小・最大容量をともに 20 に固定すると、夜間や低負荷時でも 20 台が常駐し続け、不要なコストが発生します。また、想定を超える負荷が発生した場合の柔軟なスケールアップもできず、可用性リスクも高まります。 したがって、需要のパターンが予測可能（営業開始時間）である点を踏まえ、事前に適切な容量を確保しつつ、コスト効率を維持するには、選択肢 A が最も適切です。