翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する
CloudWatch は、Auto Scaling インスタンス全体で CPU やネットワーク I/O などの使用状況データを収集し、集計します。これらのメトリクスを使用して、選択したメトリクスの値の増減に応じて Auto Scaling グループ内にあるインスタンスの数を調整するスケーリングポリシーを作成します。
インスタンスが InService
状態になってから、集約されたメトリクスに使用状況データが反映されるまでの待機時間を指定できます。この指定された時間は、デフォルトのインスタンスウォームアップと呼ばれます。これは、アプリケーショントラフィックの処理をまだ行っておらず、コンピューティングリソースの使用率が一時的に高くなっている可能性がある個々のインスタンスのメトリクスが、動的スケーリングに影響を与えないようにします。
ターゲット追跡ポリシーとステップスケーリングポリシーのパフォーマンスを最適化するには、デフォルトのインスタンスウォームアップを有効にして設定することを強くお勧めします。デフォルトでは有効ではなく設定されてもいません。
デフォルトのインスタンスウォームアップを有効にするときは、Auto Scaling グループがインスタンスメンテナンスポリシーを使用するように設定されている場合、またはインスタンスの更新を使用してインスタンスを置き換える場合、インスタンスが初期化を完了する前に最小の正常な割合にカウントされないようにできることに注意してください。
内容
パフォーマンスのスケーリングに関する考慮事項
ほとんどのアプリケーションでは、機能ごとに異なるウォームアップ時間を設けるよりも、1 つのデフォルトのインスタンスウォームアップ時間をすべての機能に適用するほうが便利です。例えば、デフォルトのインスタンスウォームアップを設定しない場合、インスタンスの更新機能はデフォルトのウォームアップ時間としてヘルスチェックの猶予期間を使用します。ターゲット追跡ポリシーとステップスケーリングポリシーがある場合は、デフォルトのクールダウンに設定された値をデフォルトのウォームアップ時間として使用します。予測スケーリングポリシーがある場合、デフォルトのウォームアップ時間はありません。
インスタンスがウォームアップしている間、動的スケーリングポリシーは、ウォームアップしていないインスタンスのメトリクス値がポリシーのアラーム上限しきい値 (またはターゲット追跡スケーリングポリシーのターゲット利用率) より大きい場合にのみスケールアウトします。需要が減少すると、動的スケーリングは控えめになり、アプリケーションの可用性を保護します。これにより、新しいインスタンスがウォームアップを完了するまで、動的スケーリングのスケールインアクティブティがブロックされます。
スケールアウト時には、Amazon EC2 Auto Scaling は、グループに追加するインスタンス数を決定するにあたって、ウォームアップ中のインスタンスをグループのキャパシティの一部と見なします。したがって、同程度の量のキャパシティの追加を必要とする複数のアラーム違反は、単一のスケーリングアクティビティになります。その目的は、スケールアウトを継続的に (ただし過剰になることなく) 行うことです。
デフォルトのインスタンスウォームアップが有効になっていない場合、メトリクスを CloudWatch に送信して現在のキャパシティーにカウントするまでのインスタンスの待機時間は、インスタンスごとに異なります。そのため、実際に発生しているワークロードと比較して、予期せずスケーリングポリシーが実行される可能性があります。
例えば、オンとオフのワークロードパターンが繰り返されるアプリケーションを考えてみましょう。予測スケーリングポリシーを使用して、インスタンス数を増やすかどうかを繰り返し決定します。予測スケーリングポリシーにはデフォルトのウォームアップ時間がないため、インスタンスは集約されたメトリクスにすぐに反映されます。これらのインスタンスの起動時のリソース使用量が多い場合、インスタンスを追加すると、集約されたメトリックスが急増する可能性があります。使用量が安定するまでにかかる時間によっては、これらの指標を使用する動的スケーリングポリシーに影響する可能性があります。動的スケーリングポリシーのアラーム上限しきい値を超えると、グループのサイズは再び大きくなります。新しいインスタンスがウォームアップしている間、スケールインアクティビティはブロックされます。
デフォルトのインスタンスウォームアップ時間を選択する
デフォルトのインスタンスのウォームアップを設定する上で重要なのは、インスタンスが InService
の状態に達した後、初期化を終了し、リソースの消費が安定するまでに必要な時間を決定することです。インスタンスのウォームアップ時間を選択するときは、正当なトラフィックの使用状況データを収集しつつ、スタートアップ時の一時的な使用量の急増に関連するデータ収集を最小限に抑えるという最適なバランスを保つようにします。
Auto Scaling グループが Elastic Load Balancing ロードバランサーにアタッチされているとします。新しいインスタンスが起動を完了すると、InService
状態に入る前にロードバランサーに登録されます。インスタンスが InService
状態になった後も、リソースの消費は引き続き一時的に急増する場合があり、安定化する時間が必要です。例えば、大量のアセットをダウンロードしてキャッシュする必要があるアプリケーションサーバーのリソース消費が安定するまでにかかる時間は、ダウンロードする大量のアセットがない軽量のウェブサーバーよりも長くなります。インスタンスのウォームアップは、リソース消費の安定化に必要な遅延時間を提供します。
重要
ウォームアップ時間に必要な時間がわからない場合は、300 秒から開始できます。次に、アプリケーションに最適なスケーリングパフォーマンスが得られるまで、徐々に減らすか、増やします。最適にするには、これを数回実行する必要がある場合があります。あるいは、独自のウォームアップ時間 (EstimatedInstanceWarmup
) が設定されているスケーリングポリシーがある場合は、この値を使用して開始することもできます。詳細については、「事前に設定されたインスタンスのウォームアップ時間を含むスケーリングポリシーを検索する」を参照してください。
スタートアップ時に実行される設定タスクやスクリプトを伴うユースケースにライフサイクルフックの使用を検討してください。ライフサイクルフックは、インスタンスが初期化を終了するまで、新しいインスタンスがサービスに使用されるのを遅らせることができます。ライフサイクルフックは特に、完了に時間がかかるブートストラップスクリプトがある場合に便利です。ライフサイクルフックを追加すると、デフォルトのインスタンスウォームアップの値を減らすことができます。ライフサイクルフック使用の詳細については、「Amazon EC2 Auto Scaling のライフサイクルフック」を参照してください。