自動スケールのベスト プラクティス

Azure Monitor の自動スケーリングは、Virtual Machine Scale SetsCloud ServicesApp Service - Web Apps、および API Management サービスにのみ適用されます。

自動スケールの概念

  • 1 つのリソースで使用できる自動スケール設定は 1 つ に限られます。
  • 自動スケール設定では、1 つ以上のプロファイルを使用できます。また、プロファイルごとに 1 つ以上の自動スケール ルールを設定できます。
  • 自動スケール設定では、インスタンスが水平方向にスケールされます。つまり、インスタンス数を増やしてスケール "アウト" し、インスタンス数を減らしてスケール "イン" します。 自動スケール設定には、インタンスの最大値、最小値、既定値があります。
  • 自動スケール ジョブでは、スケールに使用する関連付けられたメトリックを常に読み取り、スケールアウトまたはスケールインの構成済みのしきい値を超えているかどうかをチェックします。 自動スケールで使用できるメトリックの一覧については、「Azure Monitor の自動スケールの一般的なメトリック」をご覧ください。
  • しきい値はすべてインスタンス レベルで計算されます。 たとえば、"インスタンス数が 2 で、平均 CPU 使用率が 80% を超えたときに、インスタンスを 1 つ増やしてスケールアウトする" とは、全インスタンスの平均 CPU 使用率が 80% を超えたときにスケールアウトすることを意味します。
  • すべての自動スケール エラーがアクティビティ ログに記録されます。 その後、自動スケーリング エラーが発生したときに必ず、電子メール、SMS、または Webhook で通知されるように、アクティビティ ログ アラートを構成できます。
  • 同様に、正常なスケール アクションすべてが、アクティビティ ログに記録されます。 その後、自動スケーリング操作が正常に実行されたときに必ず、電子メール、SMS、または webhook で通知されるように、アクティビティ ログ アラートを構成できます。 また、正常なスケール操作が行われたときに通知されるように、自動スケール設定の通知タブで、電子メールまたは webhook の通知を構成することもできます。

自動スケールのベスト プラクティス

自動スケールを使用するときは、次のベスト プラクティスを使用します。

最大値と最小値が異なっており、これらの値に十分な差があることを確認する

最小値が 2 で最大値も 2 の設定があり、現在のインスタンス数が 2 の場合、スケール操作が実行されない可能性があります。 インスタンスの最大数と最小数に十分な差を付けておきます。 自動スケールでは、常にこれらの制限の範囲でスケールします。

手動スケールは、自動スケールの最小値と最大値によってリセットされる

インスタンス数を最大値を上回る値または下回る値に手動で更新した場合、自動スケール エンジンにより、自動的に最小値 (下回る場合) または最大値 (上回る場合) にスケールされます。 たとえば、3 ~ 6 の範囲を設定します。 実行中のインスタンスが 1 つの場合は、自動スケーリング エンジンにより、次回の実行時にインスタンスが 3 つにスケーリングされます。 同様に、スケーリングを 8 インスタンスに手動で設定すると、自動スケーリングが次回実行されたときに 6 インスタンスに戻ります。 自動スケーリング ルールもリセットしない限り、手動スケールの効果は一時的です。

増減を実行するスケールアウトとスケールインのルールの組み合わせを常に使用する

組み合わせの一方のみを使用すると、自動スケーリングは、プロファイルで定義されている最大または最小のインスタンス数に達するまで、単一方向 (スケールアウトかスケールイン) のみの動作を行います。 これは最適とは言えません。可用性を確保するために、使用率が高い時間帯にリソースをスケールアップするのが理想的です。 同様に、使用率が低いときは、コストを節約するため、リソースをスケールダウンするのが望ましいやりかたです。

診断メトリックに適切な統計を選択する

診断メトリックの場合、スケールに使用するメトリックとして、"平均"、"最小"、"最大"、"合計" の中から選択できます。 最も一般的な統計は 平均 です。

どのメトリックの種類でもしきい値を慎重に選択する

実際の状況に基づいて、スケールアウトとスケールインに異なるしきい値を慎重に選択することをお勧めします。

スケールアウトとスケールインの条件に同じまたは近いしきい値を指定した次の例のような自動スケール設定は お勧めできません

  • スレッド数が 600 以上のときにインスタンスを 1 つ増やす
  • スレッド数が 600 以下のときにインスタンスを 1 つ減らす

混乱を招くと思われる動作につながる可能性のある例を見てみましょう。 次の例を考えます。

  1. 最初に 2 つのインスタンスがあり、インスタンスあたりの平均スレッド数が 625 に増加したとします。
  2. 自動スケーリングによって 3 つ目のインスタンスが追加され、スケールアウトされます。
  3. 次に、インスタンスの平均スレッド数が 575 に減少したとします。
  4. 自動スケールでは、スケールダウンを実行する前に、スケールインした場合の最終状態の推定を試みます。 たとえば、575 x 3 (現在のインスタンス数) = 1,725 / 2 (スケールダウンしたときの最終的なインスタンス数) = 862.5 スレッドになります。 つまり、スケールインした後も、平均スレッド数に変化がない場合や少し減少しただけである場合、自動スケールですぐにスケールアウトを再度実行する必要があります。 しかし、再度スケールアップすると、このプロセス全体が繰り返されることになり、無限ループが発生します。
  5. この状態 ("締まりのない" といいます) を回避するために、スケールダウンはまったく実行されません。 代わりに、スケールダウンをスキップし、サービスのジョブが次回実行されたときに、条件が再評価されます。 平均スレッド数が 575 のときに自動スケーリングが機能していないように見えるため、このフラッピング状態は、多くのユーザーを混乱させるおそれがあります。

スケールイン時の推定動作は、スケールインとスケールアウトが連続して交互に行われる "締まりのない" 状態を回避するためのものです。 スケールアウトとスケールインに同じしきい値を使用する場合は、この動作に留意してください。

スケールアウトとスケールインのしきい値に十分な差を付けておくことをお勧めします。 たとえば、次の有効なルールの組み合わせについて考えてみます。

  • CPU 使用率が 80 以上のときにインスタンスを 1 つ増やす
  • CPU 使用率が 60 以下のときにインスタンスを 1 つ減らす

この場合、次のようになります。

  1. 最初に 2 つのインスタンスがあるとします。
  2. 全インスタンスの平均 CPU 使用率が 80 に達すると、3 つ目のインスタンスが追加され、スケールアウトされます。
  3. 時間の経過と共に、CPU 使用率が 60 に低下したとします。
  4. 自動スケールのスケールイン ルールにより、スケールインした場合の最終状態が推定されます。 たとえば、60 x 3 (現在のインスタンス数) = 180 / 2 (スケールダウンしたときの最終的なインスタンス数) = 90 になります。 そのため、すぐにスケールアウトを再度実行しなければならないので、スケールインは実行されません。 代わりに、スケールダウンがスキップされます。
  5. 次回チェックされたときに、CPU 使用率が引き続き 50 に低下していると、 再び推定が行われます。50 x 3 インスタンス = 150 / 2 インスタンス = 75 となり、スケールアウトのしきい値である 80 を下回っているため、2 つのインスタンスに正常にスケールインされます。

注意

インスタンスのターゲット数にスケーリングした結果として、フラッピングが発生する可能性があることが自動スケール エンジンによって検出されると、現在の数とターゲットの数との間のインスタンス数の差に対するスケーリングも試行されます。 この範囲内でフラッピングが発生しなかった場合、新しいターゲットで自動スケーリングによるスケール操作が続行されます。

特殊なメトリックのスケーリングしきい値に関する考慮事項

Storage や Service Bus のキューの長さメトリックなどの特殊なメトリックでは、しきい値は現在のインスタンス数あたりの使用可能な平均メッセージ数です。 このメトリックのしきい値は慎重に選択します。

動作を理解しやすいように、例を挙げて説明します。

  • Storage のキューのメッセージ数が 50 以上のときにインスタンスを 1 つ増やす
  • Storage のキューのメッセージ数が 10 以下のときにインスタンスを 1 つ減らす

次の例について考えてみます。

  1. 2 つのストレージ キュー インスタンスがあります。
  2. メッセージが次々にキューに入り、ストレージ キューを確認したところ、メッセージの総数が 50 になっていました。 この場合、自動スケールによってスケールアウト操作が開始されると思われるかもしれませんが、 インスタンスあたりのメッセージ数はまだ 50/2 = 25 です。 そのため、スケールアウトは実行されません。 最初のスケールアウトを実行するには、ストレージ キューのメッセージの総数が 100 である必要があります。
  3. 次に、メッセージの総数が 100 に達したとします。
  4. スケールアウト操作により、3 つ目のストレージ キュー インスタンスが追加されます。 150/3 = 50 であるため、キューのメッセージの総数が 150 に達するまで、次のスケールアウト操作は実行されません。
  5. これで、キューあたりのメッセージの数が減少します。 インスタンスが 3 つの場合、すべてのキューのメッセージの総数が 30 に達すると、インスタンスあたりのメッセージ数がスケールインのしきい値である 30/3 = 10 になるため、最初のスケールイン操作が実行されます。

自動スケール設定で複数のプロファイルが構成されている場合のスケーリングに関する考慮事項

自動スケール設定では、スケジュールや時間に依存せずに常に適用される既定のプロファイルを選択できます。また、定期的プロファイル (日時の範囲が指定された一定期間のプロファイル) を選択することもできます。

自動スケール サービスがこれらのプロファイルを処理するときには、常に次の順序でチェックされます。

  1. 指定日プロファイル
  2. 定期的プロファイル
  3. 既定の ("常時") プロファイル

自動スケールでは、プロファイルの条件が満たされると、それより下位のプロファイルの条件はチェックされません。 自動スケールで処理されるプロファイルは一度に 1 つに限られます。 つまり、下位層のプロファイルの処理条件も含める場合は、現在のプロファイルにそれらのルールも含める必要があります。

例を使用して確認しましょう。

次の図は、インスタンスの最小数が 2、最大数が 10 の既定のプロファイルを使用する自動スケール設定を示しています。 この例では、キューのメッセージ数が 10 を超えたときにスケールアウトし、キューのメッセージ数が 3 未満のときにスケールインするようにルールが構成されています。 したがって、リソースは 2 から 10 の間でインスタンスをスケーリングできます。

さらに、月曜日に設定された定期的プロファイルがあります。 このプロファイルでは、インスタンスの最小数が 3、最大数が 10 に設定されています。 これは、月曜日に自動スケーリングでこの条件が初めてチェックされたときに、インスタンス数が 2 の場合、新たな最小数の 3 にスケーリングされることを意味します。 自動スケールによってこのプロファイルの条件 (月曜日) に一致することが確認されている限り、このプロファイルに構成されている CPU ベースのスケールアウト/イン ルールだけが処理されます。 この時点では、キューの長さはチェックされません。 ただし、キューの長さの条件もチェックする場合は、月曜日プロファイルに既定のプロファイルのこれらのルールも含める必要があります。

同様に、自動スケールが既定のプロファイルに切り替えたときに、最小数と最大数の条件が満たされているかどうかが最初にチェックされます。 その時点でインスタンス数が 12 の場合、既定のプロファイルで許可されている最大数の 10 にスケールインされます。

自動スケール設定

プロファイルに複数のルールが構成されている場合のスケーリングに関する考慮事項

プロファイルに複数のルールを設定することが必要な場合があります。 複数のルールが設定されている場合、自動スケール エンジンで次の自動スケール ルールが使用されます。

"スケールアウト" の場合、いずれかのルールが満たされていれば、自動スケールが実行されます。 "スケールイン" の場合、すべてのルールが満たされている必要があります。

わかりやすく説明するために、次の 4 つの自動スケーリング ルールがあると仮定します。

  • CPU 使用率が 30% 未満の場合は 1 つスケールインする
  • メモリ使用率が 50% 未満の場合は 1 つスケールインする
  • CPU 使用率が 75% を超えた場合は 1 つスケールアウトする
  • メモリ使用率が 75% を超えた場合は 1 つスケールアウトする

この場合、結果は次のようになります。

  • CPU が 76% でメモリが 50% の場合、スケールアウトします。
  • CPU が 50% でメモリが 76% の場合、スケールアウトします。

一方、CPU が 25% でメモリが 51% の場合、スケールインは "実行されません"。 スケールインを実行するためには、CPU が 29%、メモリが 49% である必要があります。

常に、安全な既定のインスタンス数を選択する

既定のインスタンス数は重要です。自動スケールでは、メトリックを使用できないときにサービスをその数にスケールするからです。 そのため、ワークロードにとって安全な既定のインスタンス数を選択する必要があります。

自動スケールの通知を構成する

自動スケールでは、次のいずれかの状況が発生した場合に、アクティビティ ログに記録されます。

  • 自動スケールでスケール操作が発行された。
  • 自動スケール サービスでスケール操作が正常に完了した。
  • 自動スケール サービスがスケール操作を実行できない場合。
  • 自動スケール サービスがスケールを決定する際にメトリックを使用できない場合。
  • スケールを決定する際にメトリックを再び使用できるようになった (回復した) 場合。
  • 自動スケーリングによってフラッピングが検出され、スケーリングの試行が中止されます。 この状況では、Flapping のログの種類が表示されます。 これが表示された場合は、しきい値が狭すぎるかどうかを検討してください。
  • 自動スケーリングによってフラッピングが検出されますが、スケーリングは正常に実行できます。 この状況では、FlappingOccurred のログの種類が表示されます。 これが表示された場合は、自動スケーリング エンジンによって (たとえば、4 インスタンスから 2 への) スケーリングが試行されたものの、これによりフラッピングが発生する可能性があると判断されました。 代わりに、自動スケーリング エンジンによって異なる数のインスタンスにスケーリングされると (たとえば、2 つではなく 3 つのインスタンスを使用)、フラッピングが発生しなくなるため、このインスタンス数にスケーリングされました。

また、アクティビティ ログ アラートを使用して、自動スケール エンジンの正常性を監視することもできます。 ここに、アクティビティ ログ アラートを作成して、サブスクリプションで自動スケールのエンジン操作をすべて監視する場合、またはアクティビティ ログ アラートを作成して、サブスクリプションで失敗した自動スケールのスケールイン/スケールアウト操作をすべて監視する場合の例を示します。

アクティビティ ログ アラートを使用する以外に、正常なスケール操作が行われたときに通知されるように、自動スケール設定の通知タブで、電子メールまたは webhook の通知を構成することもできます。

次の手順