SAA-C03高パフォーマンスなアーキテクチャの設計MEDIUM複数選択

ある企業が、Amazon EC2 の Auto Scaling グループでのスケールアウト時間(新インスタンスが In Service になるまでの時間)を短縮したい。現在は新インスタンスが起動してから実際にトラフィックを受けられるまでに 5〜8 分かかっており、スパイク時の対応が遅れている。この時間を短縮する方法を 2 つ選択してください。

  1. A. EBS ボリュームの暗号化を無効化して起動時間を短縮する。
  2. B. EC2 インスタンスのインスタンスタイプをより大きいものに変更して起動を高速化する。
  3. C. CloudWatch アラームの評価期間を 1 分から 30 秒に変更してスケールアウトの検知を高速化する。
  4. D. EC2 インスタンスのブートストラップスクリプト(User Data)で行っているパッケージインストールや設定処理を、事前にベイクした AMI(Golden AMI)に含める。起動時は AMI から直接アプリが動く状態にして、User Data での処理時間を最小化する。
  5. E. Auto Scaling グループの Warm Pool を有効化し、インスタンスを事前に起動・初期化した状態でプールしておく。スケールアウト時はプールから直ちに In Service に移行する。
解答と解説を見る

正解: D, E

スケールアウト時間の短縮には 2 つのアプローチが有効。選択肢DのGolden AMI は、User Data でのリアルタイムパッケージインストールや設定処理(通常 2〜5 分)をあらかじめ AMI に組み込むことで、インスタンス起動時の初期化処理を最小化できる。起動後すぐにアプリケーションが動く状態になり、In Service 化が大幅に速まる。選択肢EのWarm Pool はインスタンスを事前に起動・初期化した状態(Stopped または Running)でプールしておき、スケールアウト時は新規起動ではなくプールからの移行(Stopped なら起動数十秒・Running なら即座)で In Service に追加できる。選択肢BのEC2 インスタンスタイプ拡大はコストが増加するが、インスタンス起動時間への直接的な影響は大きくない。起動時間はインスタンスタイプより User Data 処理や OS 起動に依存する部分が大きい。選択肢CのCloudWatch アラームの検知高速化は、スケールアウト開始タイミングを早めることには有効だが、インスタンスが起動してから In Service になるまでの時間(今回の問題)は短縮しない。選択肢AのEBS 暗号化の無効化はセキュリティを低下させ、起動時間への影響も軽微であり推奨されない。

▸ この試験を本気で演習する(全150問・無料)