次の方法で共有

自動スケーリング

自動スケールは、パフォーマンス要件に合わせてリソースを動的に割り当てるプロセスです。 作業量が増加すると、アプリケーションで、サービス レベル アグリーメント (SLA) に準拠し、必要なパフォーマンス レベルを維持するために追加のリソースが必要になる場合があります。 需要の余裕と余分なリソースが不要になったため、コストを最小限に抑えるために割り当てを解除できます。

自動スケールは、クラウドでホストされている環境の弾力性を活用しながら、管理オーバーヘッドを削減します。 これにより、オペレーターがシステムのパフォーマンスを常時監視したり、リソースの追加や削除を判断したりする必要がなくなります。

アプリケーションを拡張する方法は、主に 2 つあります。

  • 垂直方向のスケーリング (スケールアップとスケールダウンとも呼ばれます) は、リソースの容量を変更することを意味します。 たとえば、アプリケーションをより大きな仮想マシン サイズに移動できます。 垂直方向のスケーリングでは、多くの場合、再デプロイ中にシステムを一時的に使用できないようにする必要があります。 そのため、垂直方向のスケーリングを自動化することはあまり一般的ではありません。

  • 水平スケーリング (スケールアウトとスケールインとも呼ばれます) は、リソースのインスタンスの追加または削除を意味します。 新しいリソースのプロビジョニング中も、アプリケーションの実行は中断されることなく継続されます。 プロビジョニング プロセスが完了すると、これらの追加リソースにソリューションがデプロイされます。 需要が減少したら、余分なリソースをクリーンにシャットダウンし、割り当てを解除できます。

Microsoft Azure を含む多くのクラウドベースのシステムでは、自動水平スケーリングがサポートされています。 この記事の残りの部分では、水平スケーリングに重点を置いています。

注

自動スケールは、主にコンピューティング リソースに適用されます。 データベースまたはメッセージ キューを水平方向にスケーリングすることは可能ですが、通常、このプロセスには データのパーティション分割が含まれますが、通常は自動化されません。

自動スケーリングのコンポーネント

自動スケール戦略には、通常、次のコンポーネントが含まれます。

  • アプリケーション、サービス、およびインフラストラクチャ レベルでのインストルメンテーションおよび監視システム。 これらのシステムは、応答時間、キューの長さ、CPU 使用率、メモリ使用量などの主要なメトリックをキャプチャします。

  • 意思決定ロジックは、定義済みのしきい値またはスケジュールに対してこれらのライブ使用状況メトリックを評価し、スケーリングするかどうかを決定します。

  • コンポーネントとメカニズムによってスケーリング アクションが実行されます。 理想的には、これらのコンポーネントとメカニズムをワークロード コード自体から切り離し、外部プロセスとして管理する必要があります。 アイドル状態のコードや負荷がかかっているコードは、自らスケーリングを担当すべきではありません。

  • 自動スケール戦略のテスト、監視、チューニング機能を使用して、想定どおりに機能することを確認します。

Azure には、一般的なシナリオに対応する組み込みの自動スケール メカニズムが用意されています。 特定のサービスまたはテクノロジに自動スケール機能が組み込まれていない場合、または機能を超える特定の自動スケール要件がある場合は、カスタム実装を検討してください。 カスタム実装では、運用メトリックとシステム メトリックを収集し、メトリックを分析し、それに応じてリソースをスケーリングします。

Azure ソリューションの自動スケールを構成する

Azure には、ほとんどのコンピューティング オプションに対して組み込みの自動スケーリングが用意されています。

これらのコンピューティング オプションはすべて 、Azure Monitor 自動スケール機能 を使用して、一般的な自動スケール機能のセットを提供します。

  • Azure Functions は 、自動スケール ルールを構成する必要がないため、以前のコンピューティング オプションとは異なります。 代わりに、コードの実行時に Azure Functions によってコンピューティング能力が自動的に割り当てられます。 Azure Functions は、負荷を処理するために必要に応じてスケールアウトします。 詳細については、「 Azure Functions の適切なホスティング プランを選択する」を参照してください。

カスタム自動スケール ソリューションが役立つことがあります。 たとえば、Azure Diagnostics とアプリケーション ベースのメトリックをカスタム コードと共に使用して、アプリケーション メトリックを監視およびエクスポートできます。 その後、これらのメトリックに基づいてカスタム 規則を定義し、Azure Resource Manager REST API を使用して自動スケーリングをトリガーできます。 ただし、カスタム ソリューションは実装が簡単ではなく、前の方法で要件を満たすことができるものがない場合にのみ考慮する必要があります。

要件を満たしている場合は、プラットフォームの組み込みの自動スケール機能を使用します。 そうでない場合は、より複雑なスケーリング機能が必要かどうかを慎重に検討してください。 その他の要件の例としては、細分性の高い制御、スケーリングのトリガー イベントを検出するさまざまな方法、サブスクリプション間でのスケーリング、その他の種類のリソースのスケーリングなどがあります。

Azure Monitor 自動スケール機能を使用する

Azure Monitor 自動スケール機能は、仮想マシン スケール セット、App Service、Azure Cloud Services に共通の自動スケール機能セットを提供します。 スケーリングは、スケジュールに基づいて実行することも、CPU やメモリ使用量などのランタイム メトリックに基づいて実行することもできます。

次の例を考えてみましょう。

  • 平日は 10 インスタンスにスケールアウトし、土曜日と日曜日には 4 つのインスタンスにスケール インします。

  • 平均 CPU 使用率が 70%を超えていれば 1 つのインスタンスでスケールアウトし、CPU 使用率が 50%を下回る場合は 1 つのインスタンスでスケール インします。

  • キュー内のメッセージの数が特定のしきい値を超えた場合は、1 つのインスタンスでスケールアウトします。

負荷が増加したときにリソースをスケールアップして、可用性を確保します。 使用量が少ない場合は、コストを最適化できるようにスケールダウンします。 スケールアウトとスケールインのルールの組み合わせを常に使用します。 それ以外の場合、自動スケールは、プロファイルで設定されたしきい値 (最大または最小インスタンス数) に達するまで、一方向にのみ行われます。

ワークロードに安全な既定のインスタンス数を選択します。 インスタンスの最大数または最小数が設定されていない場合、リソースはその値に基づいてスケーリングされます。

組み込みのメトリックの一覧については、 Azure Monitor の自動スケールの一般的なメトリックに関するページを参照してください。 Application Insights を使用してカスタム メトリックを実装することもできます。

自動スケールは、PowerShell、Azure CLI、Azure Resource Manager テンプレート、または Azure portal を使用して構成できます。 詳細な制御を行うには、 Resource Manager REST API を使用します。 Azure Monitoring Management ライブラリと Microsoft Insights ライブラリ (プレビュー段階) は、さまざまなリソースからメトリックを収集し、REST API を使用して自動スケールを実行できる SDK です。 Resource Manager のサポートが利用できないリソース、または Azure Cloud Services を使用している場合は、Service Management REST API を自動スケールに使用できます。 それ以外の場合は、Resource Manager を使用します。

自動スケールを使用する場合は、次の点を考慮してください。

  • スケジュールされた自動スケーリングを使用し、需要の予想ピークを満たすためにインスタンスを追加および削除するのに十分な精度でアプリケーションの負荷を予測できるかどうかを検討します。 できない場合は、ランタイム メトリックに基づくリアクティブ自動スケーリングを使用して、予測できない需要の変化に対処します。 通常、これらのアプローチを組み合わせることができます。

    たとえば、アプリケーションが最も多いことがわかっている時間のスケジュールに基づいてリソースを追加する戦略を作成します。 追加のリソースを使用すると、必要に応じて、新しいインスタンスの開始を遅らせることなく、容量を確実に使用できるようになります。 スケジュールされたルールごとに、その期間中のリアクティブ自動スケーリングを可能にするメトリックを定義して、アプリケーションが需要の持続的かつ予測不可能なピークを処理できるようにします。

  • 多くの場合、メトリックと容量要件の関係を理解するのは困難です。特に、アプリケーションが最初にデプロイされる場合です。 最初に少し余分な容量を構成し、自動スケールルールを監視して調整して、容量を実際の負荷に近づけます。

  • 自動スケールルールを構成し、時間の経過と共にアプリケーションのパフォーマンスを監視します。 この監視の結果を使用して、必要に応じてシステムのスケーリング方法を調整します。 ただし、自動スケールは瞬間的なプロセスではないことに注意してください。 平均 CPU 使用率が指定したしきい値を超えたり下回ったりするなどのメトリックに対応するには時間がかかります。

  • 測定されたトリガー属性に基づく検出メカニズムを使用する自動スケールルールでは、瞬時の値ではなく時間の経過に伴う集計値を使用して、自動スケール アクションをトリガーします。 トリガー属性には、CPU 使用率またはキューの長さが含まれます。 既定では、集計は値の平均です。 この方法により、システムの反応が速すぎたり、急激な振動が発生したりするのを防ぐことができます。 また、自動的に開始される新しいインスタンスが実行モードに移行する時間も確保されます。 新しいインスタンスの起動中に、他の自動スケール アクションを実行することはできません。 Azure Cloud Services と Azure Virtual Machines の場合、集計の既定の期間は 45 分です。 そのため、需要の急増に応じてメトリックが自動スケールをトリガーするには、この期間までかかる場合があります。 SDK を使用して集計期間を変更できますが、25 分未満の期間では予期しない結果が発生する可能性があります。 App Service の Web Apps 機能の場合、平均期間が短くなり、平均トリガー メジャーに変更した後、約 5 分で新しいインスタンスを使用できるようになります。

  • スケールインとスケールアウトのアクションが絶えず切り替わる場合は、フラッピングを避けてください。 2 つのインスタンスがあるとします。 上限は CPU% 80、下限は 60%です。 負荷が 85%の場合は、別のインスタンスが追加されます。 しばらくすると、負荷は60%に減少します。 自動スケール サービスがスケールインする前に、インスタンスが削除されたときに合計負荷 (3 つのインスタンス) の分布が計算され、90%になります。 すぐに再びスケールアウトする必要があります。 そのため、スケールインはスキップされ、予想されるスケーリング結果が表示されない場合があります。

    フラッピング状況は、スケールアウトしきい値とスケールインしきい値の間で適切なマージンを選択することで制御できます。

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

  • 自動スケール エンジンは、一度に 1 つのプロファイルのみを処理します。 条件が満たされていない場合は、次のプロファイルがチェックされます。 そのプロファイルは最後にチェックされるため、キー メトリックを既定のプロファイルから除外します。 プロファイル内では、複数のルールを使用できます。 スケールアウト時に、いずれかのルールが満たされた場合に自動スケールが実行されます。 スケールインする際、オートスケールのすべてのルールを満たす必要があります。

    Azure Monitor のスケーリング方法の詳細については、「 自動スケーリングのベスト プラクティス」を参照してください。

  • ポータルではなく SDK を使用して自動スケールを構成する場合は、ルールをアクティブにするより詳細なスケジュールを指定できます。 また、独自のメトリックを作成し、自動スケール ルール内の既存のメトリックの有無に関係なく使用することもできます。 たとえば、1 秒あたりの要求数や平均メモリの可用性など、代替カウンターを使用できます。 または、カスタム カウンターを使用して特定のビジネス プロセスを測定することもできます。

  • Service Fabric を自動スケールする場合、クラスター内のノードの種類はバックエンドの仮想マシン スケール セットで構成されるため、ノードの種類ごとに自動スケール ルールを設定する必要があります。 自動スケールを設定する前に必要なノードの数を考慮してください。 信頼性レベルは、プライマリ ノード タイプに必要なノードの最小数を駆動します。 詳細については、「 自動スケール ルールを使用して Service Fabric クラスターをスケールインまたはスケールアウトする」を参照してください。

  • ポータルを使用して、Azure SQL Database インスタンスやキューなどのリソースをクラウド サービス インスタンスにリンクできます。 この方法を使用すると、リンクされた各リソースの個別の手動および自動スケーリング構成オプションに簡単にアクセスできます。 詳細については、「 Azure Cloud Services の管理」を参照してください。

  • 複数のポリシーとルールを構成すると、相互に競合する可能性があります。 自動スケールでは、次の競合解決規則を使用して、常に十分な数のインスタンスが実行されていることを確認します。

    • スケールアウト操作は、常にスケールイン操作よりも優先されます。

    • スケールアウト操作が競合する場合、インスタンス数の最大の増加を開始するルールが優先されます。

    • スケールイン操作が競合する場合、インスタンス数の最小減少を開始するルールが優先されます。

  • App Service 環境では、任意のワーカー プールまたはフロントエンド メトリックを使用して自動スケール ルールを定義できます。 詳細については、「 App Service Environment の概要」を参照してください。

アプリケーションの設計に関する考慮事項

自動スケールは即時解決策ではありません。 システムにリソースを追加したり、プロセスのインスタンスを増やしたりするだけでは、システムのパフォーマンスが向上することは保証されません。 自動スケール戦略を作成するときには、次の点を考慮してください。

  • システムは水平方向にスケーラブルに設計されている必要があります。 インスタンス アフィニティに関する想定は避けてください。 コードがプロセスの特定のインスタンスで常に実行されていることを必要とするソリューションを設計しないでください。 クラウド サービスまたは Web サイトを水平方向にスケーリングする場合、同じソースからの一連の要求が常に同じインスタンスにルーティングされると想定しないでください。 同じ理由から、アプリケーションからの一連の要求を常にサービスの同じインスタンスにルーティングする必要がないように、サービスをステートレスに設計します。 キューからメッセージを読み取って処理するサービスを設計するときは、サービスのどのインスタンスが特定のメッセージを処理するかを想定しないでください。 自動スケールでは、キューの長さが長くなるにつれて、サービスのインスタンスが増える可能性があります。 競合コンシューマー パターンでは、このシナリオを処理する方法について説明します。

  • ソリューションで実行時間の長いタスクが実装されている場合は、スケールアウトとスケールインの両方をサポートするようにこのタスクを設計します。 適切な設計がないと、システムのスケールイン時にプロセスのインスタンスが正常にシャットダウンされるのを防ぐことができます。 または、プロセスが強制的に終了されると、データが失われる可能性があります。 理想的には、実行時間の長いタスクをリファクタリングし、実行される処理をより小さな個別のチャンクに分割します。 例については、「 パイプとフィルターパターン」を参照してください。

  • または、タスクに関する状態情報を一定の間隔で記録するチェックポイント メカニズムを実装することもできます。 タスクを実行するプロセスの任意のインスタンスがアクセスできる永続的ストレージに、この状態情報を保存します。 そのため、プロセスがシャットダウンされた場合、実行していた作業は、別のインスタンスを使用して最後のチェックポイントから再開できます。 NServiceBus や MassTransit など、この機能を提供するライブラリがあります。 これにより、間隔が Azure Service Bus 内のキューからのメッセージの処理と一致する状態が透過的に保持されます。

  • クラウド サービスでホストされるアプリケーションの worker ロールなど、個別のコンピューティング インスタンスでバックグラウンド タスクを実行する場合は、異なるスケーリング ポリシーを使用して、アプリケーションのさまざまな部分をスケーリングすることが必要になる場合があります。 たとえば、バックグラウンド コンピューティング インスタンスの数を増やしたり、逆にしたりせずに、より多くのユーザー インターフェイス (UI) コンピューティング インスタンスをデプロイする必要がある場合があります。 Basic サービス パッケージや Premium サービス パッケージなど、さまざまなレベルのサービスを提供できます。 Premium サービス パッケージのコンピューティング リソースを、基本的なサービス パッケージのリソースよりも積極的にスケールアウトすることが必要になる場合があります。 このアプローチは、SLA を満たすのに役立ちます。

その他のスケーリング条件

  • UI とバックグラウンド コンピューティング インスタンスが通信するキューの長さを考慮してください。 自動スケール戦略の基準として使用します。 この条件は、現在の負荷とバックグラウンド タスクの処理能力の不均衡または差を示すことができます。 スケーリングの決定を行う際に基準とするのに少し複雑ですが、より優れた属性があります。 メッセージが送信されてから処理が完了するまでの時間を使用します ( クリティカル時間と呼ばれます)。 この重要な時間値が意味のあるビジネスしきい値を下回っている場合、キューの長さが長い場合でも、スケーリングは不要です。

    • たとえば、キューには 50,000 個のメッセージが含まれる可能性があります。 ただし、最も古いメッセージの重要な時間は 500 ミリ秒であり、そのエンドポイントは、電子メールを送信するためのパートナー Web サービスとの統合を処理しています。 ビジネス関係者は、このシナリオを、スケールアウトのコストを正当化するのに十分な緊急性を考慮しない可能性があります。

    • 一方、キューには 500 個のメッセージがあり、クリティカル時間は 500 ミリ秒です。 しかし、エンドポイントは、ビジネス関係者が 100 ミリ秒以下の応答時間を定義したリアルタイムオンライン ゲームの重要なパスの一部です。 その場合、スケールアウトは理にかなっています。

    • 自動スケールの決定に重要な時間を利用するために、ライブラリで送信および処理中に関連する情報をメッセージのヘッダーに自動的に追加すると便利です。 この機能を提供するそのようなライブラリの 1 つが NServiceBus です。

  • 自動スケール戦略をビジネス プロセスを測定するカウンターに基づく場合は、これらの種類のカウンターの結果と実際のコンピューティング容量の要件との関係を十分に理解してください。 カウンターの例としては、1 時間ごとに行われた注文の数や、複雑なトランザクションの平均実行時間などがあります。 ビジネス プロセス カウンターの変更に応じて、複数のコンポーネントまたはコンピューティング ユニットをスケーリングすることが必要になる場合があります。

  • システムが過度にスケールアウトを試みないようにするには、自動的に追加できるインスタンスの最大数を制限することを検討してください。 この方法では、何千ものインスタンスの実行に関連するコストも回避されます。 ほとんどの自動スケール メカニズムでは、ルールのインスタンスの最小数と最大数を指定できます。 さらに、インスタンスの最大数をデプロイしてもシステムがまだオーバーロードされている場合は、システムが提供する機能を適切に低下することを検討してください。

  • 自動スケールは、ワークロードの突然のバーストを処理するための最も適切なメカニズムではない可能性があることに注意してください。 サービスの新しいインスタンスの設定と開始、またはシステムへのリソースの追加には時間がかかります。 また、需要のピークは、これらの追加リソースが利用可能になるまでに経過する可能性があります。 このシナリオでは、サービスを制限した方が良いかもしれません。 詳細については、「 調整パターン」を参照してください。

  • 逆に、ボリュームが急速に変動したときにすべての要求を処理する容量が必要な場合は、追加のインスタンスをより迅速に開始する積極的な自動スケーリング戦略の使用を検討してください。 コストが大きな要因ではないことを確認します。 また、その負荷が予想される前に最大負荷を満たすのに十分な数のインスタンスを開始するスケジュールされたポリシーを使用することもできます。

  • 自動スケール メカニズムでは、自動スケール プロセスを監視し、各自動スケール イベントの詳細をログに記録する必要があります。 これらの詳細には、イベントをトリガーした内容、追加または削除されたリソース、およびイベントが発生したタイミングが含まれます。 カスタム自動スケーリングメカニズムを作成する場合は、この機能を組み込むことを確認してください。 情報を分析して自動スケール戦略の有効性を測定し、必要に応じて調整します。 ビジネスの拡大やアプリケーションの要件の進化に合わせて、使用パターンがより明確になると同時に、短期的にも長期的にも調整できます。 アプリケーションが自動スケール用に定義された上限に達した場合、必要に応じて追加のリソースを手動で開始できるオペレーターに警告する可能性もあります。 このような状況では、オペレーターは、ワークロードの緩和後にこれらのリソースを手動で削除する責任を負う場合もあります。

自動スケールを実装する場合、次のパターンとガイダンスもシナリオに関連する場合があります。

  • 調整パターンでは、需要の増加によってリソースに極端な負荷が発生した場合に、アプリケーションが引き続き機能し、SLA を満たす方法について説明します。 スロットリングは自動スケーリングと共に使用することにより、システムがスケールアウトする際に過負荷にならないようにすることができます。

  • 競合コンシューマー パターンでは、任意のアプリケーション インスタンスからのメッセージを処理できるサービス インスタンスのプールを実装する方法について説明します。 自動スケールを使用して、予想されるワークロードに合わせてサービス インスタンスを開始および停止できます。 この方法により、システムは複数のメッセージを同時に処理してスループットを最適化し、スケーラビリティと可用性を向上させ、ワークロードのバランスを取ることができます。

  • 自動スケール プロセスを推進できる情報を収集するには、インストルメンテーションやメトリックを含む監視と診断が不可欠です。