メニュー
Amazon EC2 Auto Scaling (日本語)
ユーザーガイド

スケーリングクールダウン

クールダウン期間は Auto Scaling グループにおける構成可能な設定で、以前の規模の拡大や縮小が適用される前に、追加のインスタンスを起動または終了しないようにします。Auto Scaling グループが簡易スケーリングポリシーを使用して動的にスケールした後、クールダウン期間が完了するのを待ってから規模の拡大や縮小を再開します。Auto Scaling グループを手動でスケールすると、デフォルトではクールダウン期間を待つことはありませんが、デフォルトをオーバーライドしてクールダウン期間を採用できます。インスタンスが正常でなくなった場合、Auto Scaling グループはクールダウン期間の完了を待つことなく、異常のあるインスタンスを置き換えます。

重要

クールダウン期間は、ステップスケーリングポリシーまたはスケジュールされたスケーリングではサポートされていません。

Auto Scaling は、デフォルトのクールダウン期間およびスケーリング固有のクールダウン期間の両方をサポートします。

例: クールダウン

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

 ウェブ層およびアプリケーション層との基本的なネットワークアーキテクチャ。

アプリケーション層の Auto Scaling グループに適切な数の EC2 インスタンスがあるようにするため、インスタンスの CPUUtilization メトリクスが 90 パーセントを超えたときにスケールアウトする CloudWatch アラームを作成します。アラームが発生した場合、Auto Scaling グループは別のインスタンスを起動して設定します。

 CloudWatch アラームとスケーリングポリシーの連携の例

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

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

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

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

デフォルトのクールダウン期間は、Auto Scaling グループの作成時に適用されます。そのデフォルト値は 300 秒です。このクールダウン期間は、簡易スケーリングポリシーで発生するすべての動的な規模の拡大や縮小に適用されます。また、オプションで手動の規模の拡大や縮小に適用されるようにリクエストすることもできます。

 デフォルトのクールダウンによるスケーリングアクションへの影響を示すフローチャート。

Auto Scaling グループを作成する際にデフォルトのクールダウン期間を設定するには、AWS マネジメントコンソール、create-auto-scaling-group コマンド (AWS CLI)、または CreateAutoScalingGroup API オペレーションを使用します。

デフォルトのクールダウン期間は、いつでも AWS マネジメントコンソール、update-auto-scaling-group コマンド (AWS CLI)、または UpdateAutoScalingGroup API オペレーションを使用して変更できます。

スケーリング固有のクールダウン

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

スケーリング固有のクールダウンで一般的なのは、スケールインポリシー (特定の条件またはメトリクスに基づいてインスタンスを削除するポリシー) での使用です。このポリシーはインスタンスを削除するため、Amazon EC2 Auto Scaling が追加のインスタンスを削除するかどうかを判断するために必要な時間が減ります。デフォルトのクールダウン期間である 300 秒は長すぎます。スケーリング固有のクールダウン期間として 180 秒をスケールインポリシーに適用することで、コストを削減できます。

スケーリング固有のクールダウン期間を作成するには、AWS マネジメントコンソール、put-scaling-policy コマンド (AWS CLI)、または PutScalingPolicy API オペレーションを使用します。

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

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

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

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

Auto Scaling グループにライフサイクルフックを追加できます。これらのフックにより、Auto Scaling グループ内でのインスタンスの起動と終了方法の制御が可能になり、インスタンスがサービスに配置されるか終了する前に、インスタンスでアクションを実行することができます。

ライフサイクルフックは、Auto Scaling グループ、手動スケーリング、または簡易スケーリングポリシーに設定されたクールダウン期間に影響する場合があります。クールダウン期間は、インスタンスが待機状態から抜けるまで開始されません。

クールダウンとスポットインスタンス

Auto Scaling グループを作成して、オンデマンドまたはリザーブドインスタンスの代わりにスポットインスタンスを使用することができます。クールダウンの期間は、スポットインスタンスの入札が成功した時点から開始されます。