Azure での自動スケールの使用

自動スケーリングを使用すると、要求量に基づいてアプリケーションまたはリソースを自動的にスケーリングできます。 自動スケーリングを使用して、過剰なプロビジョニングや不要なコストを発生させずに、アプリケーションの要求に十分に対応できるリソースをプロビジョニングします。

この記事では、Azure portal でリソースの自動スケーリング設定を構成する方法について説明します。

Azure 自動スケーリングでは、多くのリソースの種類がサポートされています。 サポートされているリソースの詳細については、サポートされているリソースの自動スケーリングに関するセクションを参照してください。

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

自動スケーリングできるリソースを確認するには、次の手順に従います。

1. Azure portal を開きます。

2. ページの上部にある検索バーを使用して Azure Monitor を検索し、選択します。

3. [自動スケーリング] を選択して、自動スケーリングが適用できるすべてのリソースを、現在の自動スケールの状態とともに表示します。

4. 上部のフィルター ウィンドウを使用して、特定のリソース グループやリソースの種類のリソース、または特定のリソースを選択します。

   

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

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

   また、各リソースの [設定] メニューから [Scaling] (スケーリング) を選択して、スケーリング ページにアクセスすることもできます。

   

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

注意

この記事の自動スケーリングの手順に加えて、Azure App Service には新しい自動スケーリングがあります。 この機能の詳細については、「自動スケーリング」 に関する記事を参照してください。

最初の自動スケーリング設定を作成する場合は、次の手順に従います。

1. Azure Monitor で [自動スケーリング] ペインを開き、スケーリングするリソースを選択します。 次の手順では、Web アプリに関連付けられている App Service プランを使用します。 Azure で、初めての ASP.NET Web アプリを 5 分で作成できます。

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

3. 名前とリソース グループを入力するか、既定値を使用します。

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

5. [ルールの追加] を選択します。 右側にコンテキスト ウィンドウが開きます。

   

6. Percentage CPU メトリックが 70% を超えると、既定のルールによってリソースが 1 インスタンス分だけスケーリングされます。

   既定値のままにして [追加] を選択します。

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

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

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

10. [操作] の [Decrease count by](カウント数減少幅) を設定します。

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

    

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

12. [Instance limits] (インスタンスの制限) で、[最大数] を 3 に設定します

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

    

CPU 使用率に基づいて Web アプリの自動スケーリングを行う、最初のスケール設定が正常に作成されました。 CPU 使用率が 70% を超えると、追加のインスタンスが最大 3 つまで追加されます。 CPU 使用率が 20% を下回ると、インスタンスは最小数である 1 つまで削除されます。 既定では、インスタンスは 1 つになります。

スケジュール化されたスケール条件

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

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

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

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

2. スケール条件の説明を入力します。

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

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

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

6. [日曜日] を選択します

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

8. [保存] を選びます。

これで、リソースのインスタンス数を毎週日曜日に 1 に減らすスケール条件を定義しました。

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

サービスの要求量が通常とは異なるレベルになることがわかっている場合は、特定の日付に異なるスケールを適用するよう自動スケーリングを設定します。

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

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

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

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

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

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

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

8. [保存] を選びます。

これで、特定の日のスケール条件を定義しました。 CPU 使用率が 70% を超えると、予想される負荷を処理できるように追加のインスタンスが最大 10 まで追加されます。 CPU 使用率が 20% を下回ると、インスタンスは最小数である 1 つまで削除されます。 既定では、このスケール条件がアクティブになると、自動スケーリングが適用され、3 つのインスタンスにスケーリングされます。

追加設定

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

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

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

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

必要な場合は、JSON に直接変更を加えることができます。 これらの変更は保存後反映されます。

予測自動スケーリング

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

スケールイン ポリシー

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

Notify

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

クールダウン期間の効果

自動スケーリングには、クールダウン期間が設けられています。 この期間は、スケーリング操作の後、再度スケーリングするまでの待機時間です。 クールダウン期間を設けると、メトリックが安定し、同じ条件に対して複数回スケーリングされることを防ぐことができます。 クールダウンは、スケールイン イベントとスケールアウト イベントの両方に適用されます。 たとえば、クールダウンが 10 分に設定されている場合、自動スケーリングがスケールインしたばかりであれば、自動スケーリングはどちらの方向にも、10 分間は再スケーリングを試みません。 詳細については、自動スケーリングの評価手順に関するページを参照してください。

フラッピング

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

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

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

前提条件

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

詳細ビュー

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

移動元リージョンの自動スケーリング設定と関連付けて作成された診断設定は移動できません。 自動スケーリング設定の作成の完了後に、移動先リージョンで診断設定を再作成する必要があります。

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

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

次のステップ

• アクティビティ ログ アラートを作成して、サブスクリプションのすべての自動スケーリング エンジン操作を監視する
• アクティビティ ログ アラートを作成して、サブスクリプションのすべての失敗した自動スケーリングのスケールイン/スケールアウト操作を監視する
• Azure Monitor で自動スケーリング操作を使用して電子メールと webhook アラート通知を送信する