Azure での自動スケールを始める

自動スケーリングでは、需要に基づいてアプリケーションまたはリソースが自動的にスケーリングされます。 自動スケールを使用して、過剰プロビジョニングや不要なコストを発生させることなく、アプリケーションの需要をサポートするのに十分なリソースをプロビジョニングします。

この記事では、Azure ポータルで自動スケール設定を構成する方法について説明します。 このチュートリアルでは App Service プランを使用しますが、Azure Monitor自動スケールでは多くのリソースの種類がサポートされています。 詳細については、 サポートされているリソースの自動スケーリングに関する情報を参照してください。

このチュートリアルでは、自動スケーリングをサポートするリソースの検出、メトリックベースのスケールアウトとスケールインのルールの作成、スケジュールされたスケール条件の追加、実行履歴と JSON 構成の確認を行います。

前提条件

  • アクティブなサブスクリプションを持つ Azure アカウント。 無料でアカウントを作成できます。
  • Standard レベル以上の App Service プラン。
  • App Service プラン内の少なくとも 1 つのアプリ。
  • App Service プランの 所有者 ロールまたは 共同作成者 ロール、または Microsoft.Insights/autoscaleSettings/* アクセス許可を持つカスタム ロール。

Azure Monitor の自動スケールでは、メトリック ルールとスケジュール ルールが App Service プラン全体に適用されるため、スケーリングはそのプラン内のすべてのアプリに影響します。

注意

App Service の自動スケーリング は、メトリック ルールやスケジュールなしで HTTP トラフィックに基づいて個々のアプリをスケーリングする別のオプションです。

サブスクリプションの自動スケーリング設定を検出する

自動スケールで使用できるリソースを検出するには、次の手順に従います。

  1. Azure Portalを開きます。

  2. [モニター] を検索して選択します。

  3. [ 設定] で、[ 自動スケーリング ] を選択して、自動スケールとその現在の状態をサポートするリソースを表示します。

  4. フィルターを使用して、サブスクリプション、リソース グループ、リソースの種類、またはリソースを選択します。

    自動スケーリングを使用できるリソースとその状態を示すスクリーンショット。

    このページには、各リソースのインスタンス数と自動スケーリングの状態が表示されます。 自動スケーリングの状態は次のとおりです。

    • Not configured (未構成): このリソースの自動スケーリングはまだ設定されていません。
    • Enabled (有効): このリソースの自動スケーリングが有効になっています。
    • Disabled (無効): このリソースの自動スケーリングが無効になっています。

    App Service プランの場合は、プランを開き、[ 設定] で [ スケールアウト (App Service プラン)] を選択することもできます。

    [設定] で [スケールアウト] が選択されている App Service プランのスクリーンショット。

最初の自動スケーリング設定を作成する

このセクションの手順に従って、最初の自動スケール設定を作成します。

  1. Azure Monitorで [自動スケール] ウィンドウを開き、スケーリングする App Service プランを選択します。

  2. 現在のインスタンス数は 1 です。 [カスタム自動スケーリング] を選択します。

  3. 生成された 自動スケール設定の名前 と リソース グループを確認します。 必要に応じて変更します。

    App Service プランに対して選択されたカスタム自動スケールのスクリーンショット。

  4. [メトリックに基づいてスケーリングする] を選択します。

  5. [ ルールの追加] を 選択して、[ スケール ルール ] ウィンドウを開きます。

  6. 新しいルールでは、App Service プランの CPU 使用率 メトリックが 10 分間で 70% を超えると、既定でインスタンス数が 1 ずつ増加します。

    既定値をそのまま使用し、[追加] を選択 します。

  7. これで最初のスケールアウト ルールが作成されました。 ベスト プラクティスとして、少なくとも 1 つのスケールイン ルールを設定します。 別のルールを追加するには、[規則の追加] を選択します。

  8. 演算子 を より小さい に設定します。

  9. [スケール操作をトリガーするメトリックのしきい値] を 20 に設定します。

  10. [操作] を カウント数を減少させる に設定します。

    CPU しきい値が 20% の App Service スケールイン ルールのスクリーンショット。

  11. [追加] を選択します。

    これで、CPU 使用率に基づいてスケールアウトおよびスケールインするスケール設定を作成しましたが、インスタンスの最大数は 1 つに制限されたままです。 インスタンスの制限を変更して、より多くのインスタンスを許可しましょう。

  12. [ インスタンスの制限] で、[ 最大] を 3 に設定 します。

    インスタンスの制限が 1 から 3 の App Service スケールアウトルールとスケールイン ルールのスクリーンショット。

  13. [保存] を選択します。

CPU 使用率に基づいて App Service プランをスケーリングする自動スケール設定を作成しました。 CPU 使用率が 70% を超えると、自動スケールによってインスタンスが最大 3 つ追加されます。 CPU 使用率が 20% を下回ると、インスタンスが少なくとも 1 つまで自動的に削除されます。 既定のインスタンス数は 1 です。

スケジュールされたスケール条件を追加する

既定のスケール条件では、他に有効なスケール条件がない場合のアクティブなスケール ルールを定義します。 特定の日時にアクティブなスケール条件、または週単位で繰り返されるスケール条件を追加します。

繰り返しのスケジュールに基づいたスケール

日曜日に 1 つのインスタンスにスケーリングするようにリソースを設定します。

  1. [スケーリング条件を追加する] を選択します。

  2. [特定のインスタンス数にスケーリングする] を選択します。 また、このスケール条件に固有のメトリックとしきい値に基づいてスケーリングすることもできます。

  3. [インスタンス カウント] フィールドに「1」と入力します。

  4. [特定の日数を繰り返す] を選択します。

  5. [日曜日] を選択します。

  6. スケール条件を適用する期間の開始時刻と終了時刻を設定します。 この時間の範囲以外は、既定のスケール条件が適用されます。

    毎週日曜日に繰り返される App Service プランのスケール条件のスクリーンショット。

  7. [保存] を選択します。

指定した時間範囲で、App Service プランを毎週日曜日に 1 つのインスタンスに減らすスケール条件を定義しました。

特定の日に異なる方法でスケールする

サービスに対して通常とは異なるレベルの需要が予想される場合は、自動スケールを特定の日付に対して異なる方法でスケーリングするように設定します。

  1. [スケーリング条件を追加する] を選択します。

  2. [メトリックに基づいてスケーリングする] を選択します。

  3. [規則の追加] を選択して、スケールアウト ルールとスケールイン ルールを定義します。 ルールを既定の条件と同じに設定します。

  4. 最大インスタンス制限を 10 に設定します。

  5. 既定のインスタンス制限を 3 に設定します。

  6. [ 開始日/終了日の指定] を選択します。

  7. スケール条件を適用する期間の開始日と終了日を入力します。

    特定の開始日と終了日を含む App Service プランのメトリック条件のスクリーンショット。

  8. [保存] を選択します。

特定の日付範囲のスケール条件を定義しました。 CPU 使用率が 70% を超えると、自動スケールによってインスタンスが最大 10 個まで追加されます。 CPU 使用率が 20% を下回ると、インスタンスが少なくとも 1 つまで自動的に削除されます。 このスケール条件がアクティブになると、既定のインスタンス数は 3 になります。

追加設定

自動スケール設定タブとリソース固有のオプションを使用して、アクティビティの確認、JSON の編集、通知の構成、高度なスケーリング機能へのアクセスを行います。

リソースのスケール イベントの履歴を表示する

リソースにスケーリング イベントがある場合は常に、アクティビティ ログによって記録されます。 スケール イベントの履歴は、[Run history] (実行履歴) タブで確認できます。

[実行履歴] タブの観察された App Service プラン インスタンス数のスクリーンショット。

リソースのスケール設定を表示する

自動スケールは、Azure Resource Manager のリソースです。 他のリソースと同様に、JSON 形式でリソース定義を表示できます。 JSON で自動スケーリング設定を表示するには、[JSON] タブを選択します。

[JSON] タブの App Service プランの自動スケーリング ルールのスクリーンショット。

必要に応じて、JSON で直接変更します。 これらの変更は、保存後に有効になります。

Virtual Machine Scale Setsの予測自動スケーリング

予測自動スケーリングは、機械学習を使用して、周期的なワークロード パターンに基づく Azure Virtual Machine Scale Sets の管理とスケーリングを促すものです。 これは、過去の CPU 使用率パターンに基づいて、仮想マシン スケール セットへの全体的な CPU 負荷を予測します。 過去の使用状況を観察して学習することで、全体的な CPU 負荷を予測します。 このプロセスにより、需要を満たすためにスケールアウトが遅れずに実行されるようになります。 詳細については、「 予測自動スケーリングを使用して、読み込み需要の前にスケールアウトする」を参照してください。

Virtual Machine Scale Setsのスケールイン ポリシー

仮想マシン スケール セットをスケーリングする場合、スケールイン ポリシーによって、スケールイン イベントが発生したときに削除対象として選択される仮想マシンが決定されます。 スケールイン ポリシーを Default、 NewestVM、または OldestVM に設定します。 詳細については、「Azure Virtual Machine Scale Sets でカスタム スケールイン ポリシーを使用する」を参照してください。

スケールイン ポリシー設定を示すスクリーンショット。

通知

スケール イベントが発生したときに送信する通知を構成します。 電子メール アドレスまたは Webhook に通知を送信します。 詳細については、 自動スケール通知を参照してください。

クールダウン期間の効果

自動スケールでは、各候補ルールで構成されたクールダウン期間が評価されます。 スケール操作の後、ルールは、独自のクールダウン期間が経過するまで、別のスケール アクションを開始する資格がありません。 クールダウン期間が短い別のルールは、より早く対象になる可能性があります。 クールダウン期間を設けると、メトリックが安定し、同じ条件に対して複数回スケーリングされることを防ぐことができます。 既定のクールダウン期間は 5 分です。 詳細については、 自動スケールによるクールダウンの評価方法に関する説明を参照してください。

フラッピング

フラッピングとは、対立するスケール イベントが連続して発生するループ条件を指します。 フラッピングは、あるスケール イベントが反対のスケール イベントをトリガーしたときに発生します。 たとえば、スケールインが行われるとインスタンス数が減少し、それが原因で残りのインスタンスで CPU 使用率が上昇します。 この条件によりスケールアウト イベントがトリガーされ、CPU 使用率が低下し、プロセスが繰り返されます。 詳細については、「自動スケールでのフラッピング」および「自動スケールのトラブルシューティング」を参照してください。

自動スケール設定をクリーンアップする

リソースの自動スケールを停止するには、リソースの [自動スケール ] ウィンドウを開き、[ 手動スケール] を選択し、インスタンス数を設定して、[ 保存] を選択します。 手動スケールでは、自動スケール ルールが削除され、リソースが固定インスタンス数に返されます。

自動スケーリングを別のリージョンに移動する

このセクションでは、Azure の自動スケーリングを同じサブスクリプションおよびリソース グループの別のリージョンに移動する方法について説明します。 REST API を使用して自動スケール設定を移動します。

前提条件

  • サブスクリプションとリソース グループが使用可能であり、移動元と移動先のリージョンの両方の詳細が同じであることを確認します。
  • 移動先の Azure リージョンで Azure の自動スケーリングが使用可能であることを確認します。

移動する

新しい環境で自動スケーリング設定を作成するには、REST API を使います。 移動先のリージョンで作成される自動スケーリング設定は、移動元リージョンの自動スケーリング設定のコピーになります。

ソース リージョンの自動スケール 設定 と関連付けて作成した診断設定を移動することはできません。 自動スケール設定を作成した後、ターゲット リージョンで診断設定を再作成する必要があります。

Azure リージョン間でのリソースの移動に関する詳細情報

リージョン間でのリソースの移動と Azure でのディザスター リカバリーの詳細については、「リソースを新しいリソース グループまたはサブスクリプションに移動する」を参照してください。

関連するコンテンツ

  • 最終更新: