翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon EC2 Auto Scaling のスケーリングクールダウン

スケーリングクールダウンは、以前のアクティビティの影響が表示される前に、Auto Scaling グループが追加インスタンスを起動または終了するのを防ぐのに役立ちます。

簡易スケーリングを使用する場合、Auto Scaling グループは、簡易スケーリングポリシーを使用してスケーリングした後、クールダウン期間が完了するまで待機し、簡易スケーリングポリシーによって開始されるそれ以上のスケーリングアクティビティを開始できます。適切なクールダウン期間により、古いメトリクスに基づいて追加のスケーリングアクティビティが開始されるのを防ぐことができます。デフォルトでは、すべての簡易スケーリングポリシーは、Auto Scaling グループに関連付けられたデフォルトのクールダウン期間を使用しますが、次のセクションで説明するように、特定のポリシーに対して別のクールダウン期間を設定できます。簡易スケーリングについての詳細は、「ステップとシンプルなスケーリングポリシー」を参照してください。

クールダウン期間中、スケジュールされたアクションがスケジュールされた時間に開始されるか、ターゲット追跡またはステップスケーリングポリシーによりスケーリングアクティビティが開始されると、クールダウン期間が終了するのを待たずに、それらのスケーリングアクティビティがすぐにトリガーされます。インスタンスが正常でなくなった場合、Amazon EC2 Auto Scaling は、クールダウン期間の完了を待つことなく、異常のあるインスタンスを置き換えます。

Auto Scaling グループを手動でスケールすると、デフォルトではクールダウン期間が完了するまで待機することはありませんが、この動作を上書きし、API コール時のクールダウン期間を採用できます。

デフォルトのクールダウン期間

デフォルトのクールダウン期間は、簡易スケーリングポリシーのスケーリングアクティビティに適用されます。オプションで、手動のスケーリングアクティビティに適用されるようにリクエストすることもできます。時間の長さは、インスタンスの起動時間やその他のアプリケーションのニーズに基づいて設定できます。

使用すると、AWS Management Consoleを使用して Auto Scaling グループを更新するか、AWS CLIまたは SDK を使用して Auto Scaling グループを作成または更新する場合、オプションのデフォルトのクールダウンパラメータを設定できます。デフォルトのクールダウン期間の値が指定されていない場合、デフォルト値は 300 秒です。

デフォルトのクールダウン期間を変更するには (コンソール)

通常の方法で Auto Scaling グループを作成します。Auto Scaling グループを作成したら、グループを編集してデフォルトのクールダウン期間を指定します。

デフォルトのクールダウン期間を変更するには (AWS CLI)

以下のいずれかのコマンドを使用します。

スケール固有のクールダウン期間

Auto Scaling グループのデフォルトのクールダウン期間を指定することに加えて、特定の簡易スケーリングポリシーに適用されるクールダウンを作成できます。スケーリング固有のクールダウン期間は、デフォルトのクールダウンの期間をオーバーライドします。

スケール固有のクールダウン期間の一般的な使用方法の 1 つは、スケールインポリシーを使用することです。このポリシーはインスタンスを削除するため、Amazon EC2 Auto Scaling は、追加のインスタンスを削除するかどうかを判断するために必要な時間が減ります。インスタンスを終了するオペレーションは、インスタンスを起動するよりもはるかに高速です。したがって、デフォルトのクールダウン期間である 300 秒は長すぎます。この場合、スケールインポリシーの値をより短い 180 秒に設定したスケーリング固有のクールダウン期間を使用すると、グループのスケールインを迅速に行えるようになるため、コストを削減できます。

スケーリング固有のクールダウン期間を指定するには、簡易スケーリングポリシーを作成または更新するときに、オプションのクールダウンパラメータを使用します。詳細については、「ステップとシンプルなスケーリングポリシー」を参照してください。

単純なスケーリングクールダウンシナリオの例

次のシナリオを検討してください。Web アプリケーションがAWS。このウェブアプリケーションは、ウェブ、アプリケーション、およびデータベースの 3 つの基本的な層で構成されます。アプリケーションがトラフィックの需要を満たすリソースが常にあるようにするには、2 つの Auto Scaling グループを作成します。1 つはウェブ層用、もう 1 つはアプリケーション層用です。

アプリケーション層のグループに適切な数の EC2 インスタンスがあることを確認するために、スケーリングポリシーに関連付けられた CloudWatch メトリクスの値が、連続した指定期間に指定されたしきい値を超えた場合にスケールアウトする簡易スケーリングポリシーを作成できます。CloudWatch アラームによってスケーリングポリシーがトリガーされると、Auto Scaling グループは起動し、別のインスタンスを設定します。

これらのインスタンスは、設定スクリプトを使用して、インスタンスがサービスに配置される前にソフトウェアをインストールして設定します。その結果、インスタンスが起動してから完全稼働までに約 2～3 分かかります。実際の時間は、インスタンスのサイズ、および完了する起動スクリプトがあるかどうかなど、いくつかの要因によって決まります。

ここで、トラフィックの急増が発生し、CloudWatch アラームが発生します。このときに、Auto Scaling グループは需要の増加を処理するためにインスタンスを起動します。ただし、インスタンスは起動に数分かかるという問題があります。その間、標準解像度アラームで CloudWatch アラームが毎分発生し続け、アラームが起動するたびに Auto Scaling グループが別のインスタンスを起動する可能性があります。

ただし、クールダウン期間が実施されると、Auto Scaling グループは、特定の期間が経過するまで、インスタンスを起動し、簡易スケーリングポリシーによる規模の拡大や縮小をブロックします。(デフォルト値は 300 秒です)。これにより、新しく起動されたインスタンスには、アプリケーショントラフィックの処理を開始するための時間が与えられます。クールダウン期間が終了すると、クールダウン期間後にトリガーされたスケーリングアクティビティを再開できます。CloudWatch アラームが再度発生した場合、Auto Scaling グループは別のインスタンスを起動し、クールダウン期間が再度有効になります。ただし、追加のインスタンスがメトリクス値を戻すために十分だった場合、グループは現在のサイズのままになります。

クールダウンと複数のインスタンス

前のセクションでは、1 つのインスタンスが起動または終了する際のクールダウン期間による Auto Scaling グループへの影響を示す例を紹介しました。ただし、Auto Scaling グループが複数のインスタンスを一度に起動することもあります。たとえば、特定のメトリクスのしきい値に達したときに、が 3 つのインスタンスを起動するように選択する場合があります。

複数のインスタンスでは、最後のインスタンスが起動または終了を完了すると、クールダウン期間 (デフォルトのクールダウンまたはスケーリング固有のクールダウン) が有効になります。

クールダウンとライフサイクルフック

Auto Scaling グループにライフサイクルフックを追加することもできます。これらのフックにより、Auto Scaling グループ内でのインスタンスの起動と終了方法の制御が可能になり、インスタンスがサービスに配置されるか終了する前に、インスタンスでカスタムアクションを実行することができます。ライフサイクルアクションが発生し、インスタンスが待機状態になると、簡易スケーリングポリシーによるスケーリングアクティビティが一時停止されます。詳細については、「Amazon EC2 Auto Scaling ライフサイクルフック」を参照してください。

ライフサイクルフックは、Auto Scaling グループに設定されたクールダウン期間の開始時間に影響する場合があります。たとえば、インスタンスの起動でカスタムアクションをサポートするライフサイクルフックのある Auto Scaling グループについて考えてみましょう。簡易スケーリングポリシーによってアプリケーションの需要が増加すると、グループはインスタンスを起動して容量を追加します。ライフサイクルフックがあるため、インスタンスは Pending:Wait 状態になり、トラフィックの処理にまだ使用できないことが示されます。インスタンスが待機状態になると、簡易スケーリングポリシーによるスケーリングアクティビティは一時停止されます。インスタンスが InService 状態になると、クールダウン期間が開始します。クールダウン期間が終了すると、クールダウン期間後にトリガーされたスケーリングアクティビティを再開できます。

ライフサイクルフックの実行後にすべてのクールダウンが適用されるわけではない

通常、インスタンスが終了するとき、クールダウン期間は、インスタンスが Terminating:Wait 状態から移行した後 (ライフサイクルフックの実行が完了した後) まで開始されません。

ただし、Elastic Load Balancing では、終了するインスタンスがロードバランサーによる Connection Draining (登録解除の遅延) を終了し、ライフサイクルフックを待たない場合に Auto Scaling グループがクールダウン期間を開始します。これは、スケールインとスケールアウトの両方の簡易スケーリングポリシーを持つグループで役立ちます。クールダウン期間の目的は、前のアクティビティの効果が現れたらすぐに次のスケーリングアクティビティを実行できるようにすることです。インスタンスが終了するときにアプリケーションの需要が急増した場合、一時停止された簡易スケーリングポリシーによるスケーリングアクティビティはすべて、Connection Draining とクールダウン期間の終了後に再開できます。それ以外の場合は、3 つのアクティビティ（接続の排水、ライフサイクルフック、クールダウン期間）をすべて完了するまで待つと、Auto Scaling グループがスケーリングを一時停止するのに必要な時間が大幅に長くなります。