オートスケールのベストプラクティスを探る
自動スケール設定を作成するときに適切なプラクティスに従っていない場合は、望ましくない結果につながる条件を作成できます。 このユニットでは、相互に競合するルールを作成しないようにする方法について説明します。
オートスケールの概念
自動スケール設定では、インスタンスを水平方向にスケーリングします。これは、インスタンス数を増やして を で、インスタンス数を減らして を で行います。 自動スケール設定には、インスタンスの最大値、最小値、既定値があります。
自動スケール ジョブは、スケール アウトまたはスケールイン用に構成されたしきい値を超えたかどうかを確認して、スケールする関連メトリックを常に読み取ります。
すべてのしきい値は、インスタンス レベルで計算されます。 たとえば、「インスタンス数が 2 のときに平均 CPU > 80% を 1 つのインスタンスでスケールアウトする」とは、すべてのインスタンスの平均 CPU が 80%を超えたときにスケールアウトすることを意味します。
自動スケールの成功と失敗はすべてアクティビティ ログに記録されます。 その後、アクティビティ ログ アラートを構成して、アクティビティがあるたびに電子メール、SMS、または Webhook 経由で通知を受け取ることができます。
自動スケーリングの最適な方法
自動スケール ルールを作成するときは、次のベスト プラクティスを使用します。
最大値と最小値が異なり、それらの間に十分なマージンがあることを確認します
minimum=2、maximum=2、現在のインスタンス数が 2 の設定がある場合、スケール アクションは発生しません。 インスタンスの最大数と最小数には両端を含めて、十分な余白を確保してください。 自動スケールは、常にこれらの制限の間でスケーリングされます。
診断メトリックに適した統計情報を選択する
診断メトリックには、[平均 ]、[最小 ]、[最大 ]、[合計 ]から選択できます。 最も一般的な統計は Average です。
すべてのメトリックの種類に対してしきい値を慎重に選択する
実際の状況に基づいて、スケールアウトとスケールインのためにさまざまなしきい値を慎重に選択することをお勧めします。
次の例のような自動スケール設定 、アウトとインの条件で同じまたは類似したしきい値を使用することはお勧めしません。
- スレッド数 >= 600 のときにインスタンスを 1 カウント増やす
- スレッド数 <= 600 のときにインスタンスを 1 カウント減らす
混乱を招く可能性のある動作の例を見てみましょう。 次のシーケンスについて考えてみましょう。
- 最初に 2 つのインスタンスがあり、インスタンスあたりの平均スレッド数が 625 に増加するとします。
- 自動スケールでは、3 つ目のインスタンスを追加してスケールアウトします。
- 次に、インスタンス全体の平均スレッド数が 575 に減少すると仮定します。
- スケールインする前に、自動スケールは、スケールインした場合の最終的な状態の推定を試みます。 たとえば、575 x 3 (現在のインスタンス数) = 1,725 / 2 (スケールイン時の最終的なインスタンス数) = 862.5 スレッド。 つまり、平均スレッド数が変わらないか、わずかしか減少しない場合には、スケールインした後でも、自動スケールは直ちに再度スケールアウトする必要があります。 ただし、再びスケールアウトされた場合、プロセス全体が繰り返され、無限ループが発生します。
- この状況 ("フラッピング" と呼ばれる) を回避するために、自動スケールはまったくスケールインしません。 代わりに、次にサービスのジョブを実行する際に、条件をスキップして再評価します。 平均スレッド数が 575 の場合、自動スケーリングが機能しないように見えるため、多くのユーザーが混乱する可能性があります。
スケール イン中の推定は、スケール インとスケールアウトのアクションが継続的に行き来する "フラッピング" 状況を回避することを目的としています。 スケールアウトとスケールインに同じしきい値を選択する場合は、この動作に留意してください。
スケールアウトとスケールインのしきい値の間に適切な余裕を持たせることをお勧めします。 例として、次の優れた規則の組み合わせを考えてみましょう。
- CPU% >= 80 のときにインスタンスを 1 カウント増やす
- CPU% <= 60 のときにインスタンスを 1 カウント減らす
この場合
- 開始するインスタンスが 2 つあるとします。
- インスタンス間の平均 CPU% が 80 になると、3 つ目のインスタンスを追加して自動スケールがスケールアウトされます。
- 時間の経過と同時に CPU% が 60 に低下すると仮定します。
- 自動スケールのスケールイン ルールでは、スケールインする場合の最終的な状態が推定されます。 たとえば、60 x 3 (現在のインスタンス数) = 180 / 2 (スケールイン時の最終的なインスタンス数) = 90。 そのため、自動スケールは、すぐに再びスケールアウトする必要があるため、スケールインしません。 代わりに、スケールインはスキップされます。
- 次回自動スケールがチェックされる際、CPU は引き続き 50 に低下します。 50 x 3 インスタンス = 150 / 2 インスタンス = 75 と推定されます。これはスケールアウトしきい値の 80 を下回っているので、2 つのインスタンスに正常にスケールインされます。
プロファイルで複数のルールが構成されている場合のスケーリングに関する考慮事項
プロファイルで複数のルールを設定する必要がある場合があります。 複数のルールが設定されている場合は、次の一連の自動スケール ルールがサービスによって使用されます。
スケールアウト では、いずれかのルールが満たされた場合に自動スケールが実行されます。 スケールイン で、自動スケールには、すべてのルールを満たす必要があります。
たとえば、次の 4 つの自動スケール ルールがあるとします。
- CPU < 30%の場合は、1 ずつスケールインします。
- メモリ < 50%の場合は、1 ずつスケールインします。
- CPU > 75%の場合は、1 ずつスケールアウトします。
- メモリ > 75%の場合は、1 ずつスケールアウトします
その後、次の処理が行われます。
- CPU が 76% で、メモリが 50%の場合、スケールアウトします。
- CPU が 50% でメモリが 76% 場合はスケールアウトします。
一方、CPU が 25 の% であり、メモリが 51 の% の場合、自動スケールはスケールインしません。 自動スケール インは、CPU が 29% で、メモリが 49% の場合に発生します。これは、両方のスケールイン ルールが true になるためです。
常に安全な既定のインスタンス数を選択する
既定のインスタンス数は重要です。自動スケールでは、メトリックが使用できない場合にサービスをその数にスケーリングするためです。 そのため、ワークロードに安全な既定のインスタンス数を選択します。
自動スケーリング通知の設定
次のいずれかの状況が発生した場合、自動スケーリングがアクティビティログに記録されます。
- 自動スケールがスケール操作を実行する
- 自動スケール サービスによってスケール アクションが正常に完了する
- 自動スケール サービスがスケール アクションを実行できません。
- メトリックは、スケールの決定を行う自動スケール サービスでは使用できません。
- スケールの決定を行うために、メトリックを再び使用 (復旧) できます。
アクティビティ ログ アラートを使用して、自動スケール エンジンの正常性を監視することもできます。 アクティビティ ログ アラートの使用に加えて、自動スケール設定の [通知] タブを使用して、スケール アクションが成功した場合に通知を受け取るように電子メールまたは Webhook 通知を構成することもできます。