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