すべてのプロダクト
Search
ドキュメントセンター

Auto Scaling:スケールインガイド

最終更新日:Sep 11, 2024

ビジネスワークロードが減少すると、Auto Scalingはスケーリンググループのスケールインイベントをトリガーします。 これにより、リソースの調整が自動化され、リソースコストが最小限に抑えられます。 このトピックでは、グレースフルスケールイン操作を実行する方法について説明します。

概要のスケールインプロセス

スケーリンググループでスケールインプロセスがトリガーされると、設定されたスケールインポリシーに基づいて、スケーリンググループから削除するインスタンスが選択されます。 削除されたインスタンスは、定義済みのインスタンス再利用モードに基づいて再利用されます。 次の図に示すように、構成はスケールインプロセスのフェーズによって異なります。

image

スケールインイベントのトリガー

スケールイン境界を制御して毎日のビジネス要件を満たす

  • 実装方法: スケーリンググループの [最小インスタンス数] パラメーターを設定します。

    [最小インスタンス数] パラメーターには、スケーリンググループ内のインスタンス数の下限を指定します。 スケールインリクエストが開始されると、スケールインプロセスが完了した後にスケーリンググループ内のインスタンスの数が下限を下回った場合、Auto Scalingはスケールインリクエストを拒否します。 これにより、スケーリンググループ内のリソースが不足し、日々のビジネス要件を満たすことができなくなるのを防ぎます。

  • 操作: 詳細については、「スケーリンググループの管理」をご参照ください。

ワークロード層に基づくインスタンスのスケールイン (ステップスケーリングルール)

  • 実装方法: スケーリンググループのステップスケーリングルールを作成します。

    ステップスケーリングルールを作成して、ワークロード層に基づいてスケールインを有効にすることができます。 この方法は、複数のインスタンスの迅速な削除によって引き起こされるシステムの過負荷または中断を効果的に防ぎ、グレースフルスケールインイベントを保証します。 たとえば、スケーリンググループの次のCPU使用率層に基づいて、カスタムスケールインソリューションを設計します。

    • 平均CPU使用率が20% を下回った場合、5つのインスタンスでスケーリングします。

    • 平均CPU使用率が20% 〜30% の場合、3つのECSインスタンスでスケーリングします。

    • 平均CPU使用率が30% 〜50% の場合、1つのECSインスタンスでスケーリングします。

この場合、次の図に示すように、ステップスケーリングルールを作成できます。 image

クールダウン期間とイベントトリガータスクを設定して、スケールイン率と頻度を制御します

クールダウン期間とイベントトリガータスクを設定して、頻繁なスケールイン操作によるビジネスの不安定さを防ぎ、スケールインイベントを適切に行うことができます。

方法1: クールダウン期間の設定

  • 実装方法: スケーリンググループとスケーリングルールのクールダウン期間を設定します。

    クールダウン期間は、イベントトリガータスクによってトリガーされる2つの連続したスケーリング操作の最小間隔を指定します。 この設定では、スケールイン周波数を制御できます。

  • 操作: 詳細については、「クールダウン期間」をご参照ください。

方法2: イベントトリガータスクのトリガー頻度を設定

  • 実装方法: イベントトリガータスクには、[統計期間][条件][トリガー後] のパラメーターを設定します。

    これらのパラメーターを使用して、イベントトリガータスクによってトリガーされるスケールイン操作の頻度を制御できます。

  • 操作: 詳細については、「アラームタスクの作成」をご参照ください。

方法3: ターゲット追跡スケーリングルールのトリガー頻度を設定

  • 実装方法: ターゲット追跡スケーリングルールの [スケールインアラートのしきい値] パラメーターを設定します。

    ターゲット追跡スケーリングルールを作成すると、イベントトリガータスクが自動的に作成されます。 このパラメーターには、自動的に作成されたイベントトリガータスクがスケールインアラートをトリガーするまでに、アラート条件が満たされる必要がある連続回数を指定します。

  • 操作: 詳細については、「ターゲット追跡スケーリングルール」をご参照ください。

スケールインイベントがトリガーされる時刻の指定

ビジネス要件に基づいて、スケールインイベントがトリガーされる時間を指定できます。 これは、優雅なスケールインイベントを実装します。 次のいずれかの方法を使用できます。

方法1: 単純なスケーリングルールを手動で実行

単純なスケーリングルールを手動で実行して、スケールインイベントをトリガーできます。 詳細については、「スケーリングルールの管理」をご参照ください。

説明

このメソッドはAPI操作をサポートします。 詳細については、「ExecuteScalingRule」および「ScaleWithAdjustment」をご参照ください。

方法2: スケーリンググループ内のインスタンス数を変更してスケールインイベントをトリガーする

[最大インスタンス数] または [期待インスタンス数] パラメーターを変更して、スケールインイベントをトリガーできます。 Auto Scalingは、2つのパラメーターの設定に基づいてスケーリンググループ内のインスタンス数を調整し、期待されるスケールイン効果を確保します。 詳細については、「スケーリンググループの管理」をご参照ください。

説明

このメソッドはAPI操作をサポートします。 詳細については、「ModifyScalingGroup」をご参照ください。

スケールインするインスタンスの選択

デフォルトでは、Auto Scalingは、スケーリンググループのvSwitchの指定された順序に基づいてインスタンスをスケーリングします (優先度ポリシー) 。 スケールインポリシーを変更して、ビジネス要件に基づいてスケールインするインスタンスを選択できます。

重要
  • ミッションクリティカルなインスタンスをスケールインしたくない場合は、このインスタンスを保護状態にして、予期しないインスタンスのスケールインによるビジネスの中断を防ぐことができます。 詳細については、「インスタンスを手動で保護状態にする、またはインスタンスを保護状態から移動する」をご参照ください。

  • Elastic Container Instanceタイプのスケーリンググループは、スケールインポリシーおよびスケーリングポリシーパラメーターをサポートしていません。 デフォルトでは、Auto Scalingは、最も古いスケーリング設定から作成されたエラスティックコンテナインスタンスをスケーリンググループから優先的に削除し、次に最も古いエラスティックコンテナインスタンスをスケーリンググループから削除します。

解決策1: スケールインプロセスが完了した後、ゾーン間のインスタンスの分散のバランスをとる

このソリューションにより、ディザスタリカバリが保証されます。 このソリューションを使用する場合、ディザスタリカバリを実装するためのスケールインプロセスが完了した後、インスタンスは複数のゾーンに均等に分散されます。

  • 実装方法: スケーリングポリシーパラメーターを分散ポリシーに設定します。

    バランス分散ポリシーを有効にすると、Auto Scalingはインスタンス数が最も多いゾーンからインスタンスを優先的にスケールインします。 分散分散ポリシーが有効になった後もスケールインプロセスを継続する場合は、スケールインポリシーパラメーターを [以前のスケーリング設定から作成][以前のインスタンス] 、または [最近のインスタンス] に設定します。

  • 操作: 詳細については、「シナリオ2: 分散ポリシー + スケールインポリシー」をご参照ください。

解決策2: 単価が最も高いインスタンスのスケールインに優先順位を付ける (コスト最適化ポリシー)

このソリューションは、費用対効果を保証します。 コスト最適化ポリシーを有効にして、費用対効果のレベルが最も低いインスタンスでスケーリングできます。 これは、リソース利用を改善する。

  • 実装方法: [スケーリングポリシー] ポリシーを [コスト最適化ポリシー] に設定します。

    コスト最適化ポリシーを有効にすると、Auto Scalingは、スケーリンググループの単価が最も高いインスタンスで優先的にスケーリングします。 コスト最適化ポリシーが有効になった後もスケールインプロセスを継続する場合は、スケールインポリシーパラメーターを初期のスケーリング設定から作成されたインスタンス初期のインスタンス、または最新のインスタンスに設定します。

  • 操作: 詳細については、「シナリオ3: コスト最適化ポリシー + スケールインポリシー」をご参照ください。

説明

このソリューションは、リソースコストのバランスを取るのに役立ちます。 スケーリンググループ内のプリエンプティブルインスタンスと従量課金インスタンスの比率を設定できます。

解決策3: カスタム組み合わせポリシーを作成する

ソリューション1とソリューション2を組み合わせることができます。

  • 実装方法: スケーリンググループのスケーリングポリシーパラメーターをカスタム組み合わせポリシーに設定します。

    カスタム組み合わせポリシーを有効にすると、従量課金インスタンスとプリエンプティブルインスタンスの比率を調整したり、複数のゾーン間でリソース容量のバランスを取ったり、従量課金インスタンスとプリエンプティブルインスタンスの容量計画ポリシーを作成したりできます。

  • 操作: 詳細については、「スケーリングポリシーとスケールインポリシーの組み合わせ」をご参照ください。

解決策4: カスタムスケールインポリシーの作成

Auto Scalingでサポートされているスケールインポリシーがビジネス要件を満たさない場合は、このソリューションで説明されているとおり、Function Computeを使用してカスタムスケールインポリシーを作成できます。

  • 実装方法: スケールインポリシーパラメーターをカスタムポリシーに設定します。

    Function Computeのプログラミング言語を使用して、カスタムのスケールインポリシーを作成できます。 スケールインイベントがトリガーされるたびに、function Computeで作成した関数が呼び出されます。 ビジネス要件に基づいて、関数の作成時にスケールインできるインスタンスとできないインスタンスを定義できます。

  • 操作: 詳細については、「Function Computeを使用したECSインスタンスのカスタムスケールインポリシーの作成」をご参照ください。

インスタンスの優雅なスケール

スケールインプロセスは、スケールイン標準を満たすインスタンスが進行中のタスクを完了した場合にのみ進行します。 グレースフルスケールインとして知られるこのプロセスは、スケールイン操作によるビジネスの中断を防ぎます。

  • 実装方法: ライフサイクルフックを作成します。

    スケールインプロセスがトリガーされると、ライフサイクルフックを有効にして、進行中のタスクを持つインスタンスを [保留中の削除] 状態にすることができます。 ライフサイクルフックの有効期間中に、インスタンスに対して操作を実行できます。 進行中のタスクを完了するのにより長い期間が必要な場合は、API操作を呼び出してライフサイクルフックの有効期間を延長できます。

  • 操作: 詳細については、「概要」および「RecordLifecycleActionHeartbeat」をご参照ください。

重要
  • Elastic Container Instanceタイプのスケーリンググループは、ライフサイクルフック機能をサポートしていません。 Elastic Container Instanceタイプのスケーリンググループを使用する場合、このソリューションは使用できません。

  • 同様のスケールイン効果でインスタンスを直接削除、削除、または停止した場合、ライフサイクルフックは有効になりません。 このソリューションは使用できません。

スケーリングされたインスタンスの再利用

スケールイン効率を向上させるため、デフォルトのインスタンス再利用モードは強制リリースです。 このモードでは、Auto Scalingはスケーリンググループから削除されたインスタンスを直接リリースします。 インスタンスのリリース後、リソースは保持されません。 他のインスタンス再利用モードを使用することもできます。 詳細については、「スケーリンググループの管理」をご参照ください。