次の方法で共有

自動スケール

  • [アーティクル]

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

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

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

  • 垂直方向のスケーリングスケール アップまたはスケール ダウンとも呼ばれ、リソースの容量を変更することを指します。 たとえば、アプリケーションをより大きい VM に移動する場合です。 垂直方向のスケーリングでは、一般的に再デプロイのためにシステムの使用を一時的に中断する必要があります。 したがって、垂直方向スケーリングの自動化はあまり一般的ではありません。

  • 水平方向のスケーリング、スケール アウトまたはスケール インとも呼ばれ、リソースからインスタンスを追加または削除することを指します。 新しいリソースのプロビジョニング中も、アプリケーションの実行は中断されることなく継続されます。 プロビジョニング プロセスが完了すると、ソリューションはこれらの追加リソース上に展開されます。 需要が減った場合は、追加のリソースを正常にシャット ダウンし、割り当てを取り消せます。

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

注意

自動スケールは、ほとんどの場合、コンピューティング リソースに適用されます。 データベースまたはメッセージ キューは水平方向に拡張できますが、これには、一般的に自動化されていない データのパーティション分割が必要になります。

自動スケールのコンポーネント

通常、自動スケール戦略を実装するには、次のコンポーネントやプロセスが必要になります。

  • アプリケーション、サービス、およびインフラストラクチャのレベルで運用する、インストルメンテーションおよび監視システム。 これらのシステムは、応答時間、キューの長さ、CPU 使用率、メモリ使用量などの主要メトリックをキャプチャします。
  • 定義済みのしきい値またはスケジュールを基準にこれらのメトリックを評価し、拡張するかどうかを決定する意思決定ロジック。
  • システムを拡張するコンポーネントです。
  • 自動スケール戦略を期待どおりに機能させるための、戦略のテスト、監視、および調整。

Azure には、一般的なシナリオに対応するための自動スケール メカニズムが組み込まれています。 特定のサービスやテクノロジに自動スケール機能が組み込まれていない場合、またはその機能以上の特定の自動スケールの要件がある場合は、カスタム実装を検討できます。 カスタム実装では、運用およびシステム メトリックを収集し、メトリックを解析して、それに従ってリソースを拡張します。

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

Azure には、ほぼすべてのコンピューティング オプションに対応する自動スケール機能が組み込まれています。

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

  • Azure Functions は、自動スケール規則を構成する必要がない点で、以前のコンピューティング オプションとは異なります。 Azure Functions では、コードの実行中に、負荷を処理するために必要なコンピューティング能力が自動的に割り当てられます。 詳細については、Azure Functions の適切なホスティング プランの選択に関する記事をご覧ください。

最後に、カスタムの自動スケール ソリューションが役に立つ場合があります。 たとえば、Azure Diagnostics およびアプリケーションベースのメトリックやカスタム コードを使用して、アプリケーション メトリックを監視およびエクスポートできます。 その後、これらのメトリックに基づいてカスタムの規則を定義し、Resource Manager REST API を使用して、自動スケールを開始できます。 ただし、カスタム ソリューションの実装は容易ではないため、前述の手法では要件を完全に満たすことができない場合にのみ検討してください。

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

Azure Monitor 自動スケールの使用

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

例 :

  • 平日は 10 個のインスタンスにスケール アウトとし、土曜日と日曜日は 4 つのインスタンスにスケール インします。
  • 平均 CPU 使用率が 70% を上回る場合はインスタンス 1 つ分スケール アウトし、CPU 使用率が 50% を下回る場合はインスタンス 1 つ分スケール インします。
  • キュー内のメッセージの数が特定のしきい値を超える場合は、インスタンス 1 つ分スケール アウトします。

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

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

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

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

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

  • スケジュールされた自動スケーリングを使用し、予測される需要ピーク時に対応するためにインスタンスを追加および削除することにより、適切にアプリケーションの負荷を予測できるかどうかを検討します。 これが不可能な場合は、実行時に収集されたメトリックに基づくリアクティブ自動スケールを使用して、予測不可能な需要の変化にアプリケーションが対応できるようにします。 通常は、これらの手法を組み合わせることができます。 たとえば、アプリケーションが最もビジー状態になることがわかっている時間のスケジュールに基づいてリソースを追加する戦略を作成します。 これにより、新しいインスタンスの開始時に遅延することなく、必要なときに容量を確保できます。 また、スケジュールされたルールごとに、その期間のリアクティブ自動スケールを有効にし、持続的だが予測不可能な需要ピークをアプリケーションが処理できるメトリックを定義します。

  • 特にアプリケーションが初めてデプロイされたときは、メトリックと容量要件の関係を理解しにくいことがよくあります。 最初は容量を少し余分に追加し、その後自動スケール ルールを監視および調整して、実際の負荷に容量を近づけることをお勧めします。

  • 自動スケール ルールを構成し、一定期間、アプリケーションのパフォーマンスを監視します。 この監視結果を使用して、必要に応じてシステムをスケールする方法を調整します。 ただし、自動スケールは即時に結果を得られるプロセスではありません。 指定したしきい値を超過する (または下回る) 平均 CPU 使用率など、何らかのメトリックに反応するには一定の時間を要します。

  • 測定されたトリガー属性 (CPU 使用率やキューの長さなど) に基づく検出メカニズムを使用する自動スケール ルールでは、瞬間的な値ではなく、長期にわたって集計された値を使用して自動スケール アクションがトリガーされます。 既定では、集計は値の平均になります。 これにより、システムの反応が早すぎたり、急激な変動が生じたりすることが回避されます。 また、自動的に開始された新しいインスタンスが実行モードになるまでの時間を確保し、新しいインスタンスの開始中に追加の自動スケール アクションが実行されないようにすることもできます。 Azure Cloud Services や Azure Virtual Machines については、既定の集計期間は 45 分であるため、需要の急増に反応して自動スケールをトリガーするメトリックに、この長さまでの時間を設定できます。 SDK を使って集計期間を変更できますが、期間を 25 分未満にすると、予期しない結果が生じる場合があります。 Web Apps では、平均の期間はかなり短く、平均のトリガー測定への変更後、約 5 分間で新しいインスタンスを使用できるようになります。

  • スケールイン アクションとスケールアウト アクションが絶えず交互に実行される "フラッピング" を回避します。 2 つのインスタンスがあり、CPU の上限が 80%、下限が 60% であるとします。 負荷が 85% になると、別のインスタンスが追加されます。 しばらくして、負荷が 60% に減少したとします。 自動スケール サービスは、スケールインする前に、インスタンスが削除されたときの (3 つのインスタンスの) 合計負荷の分散を計算します。この例では 90% になります。 つまり、すぐに再度スケールアウトしなければなりません。 そのため、スケールインがスキップされ、予想されるスケーリング結果が得られない可能性があります。

    フラッピングの状況は、スケールアウトとスケールインのしきい値の間に十分な差を付けることで制御できます。

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

  • 自動スケール エンジンによって処理されるプロファイルは一度に 1 つに限られます。 条件が満たされていない場合は、次のプロファイルがチェックされます。 既定のプロファイルは最後にチェックされるため、主要なメトリックはこのプロファイルに含めないようにします。 1 つのプロファイルに複数のルールを設定できます。 スケールアウトでは、いずれかのルールが満たされていれば、自動スケールが実行されます。 スケールインでは、すべてのルールが満たされている必要があります。

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

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

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

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

  • 複数のポリシーとルールを構成するときは、それらが互いに競合する可能性があります。 自動スケールでは次の競合の解決ルールに従って、常に十分な数のインスタンスが実行されます。

    • スケールアウト操作は、スケールイン操作よりも常に優先されます。
    • スケールアウト操作が競合した場合は、インスタンス数を最も増加させるルールが優先されます。
    • スケールイン操作が競合した場合は、インスタンス数を最も減少させるルールが優先されます。

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

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

自動スケールは単純なソリューションではありません。 単にリソースをシステムに追加したり、実行するプロセスのインスタンスを増やしたりするだけで、システムのパフォーマンスが確実に向上するわけではありません。 自動スケール戦略を作成するときには、次の点を考慮してください。

  • システムは、水平方向にスケールできるように設計されている必要があります。 インスタンスのアフィニティに関して仮説を立てることは避けます。あるコードが常にプロセスの特定のインスタンスで実行されている必要があるようなソリューションを作成しないでください。 クラウド サービスまたは Web サイトを水平方向にスケールする場合、同じソースからの一連の要求が常に同じインスタンスにルーティングされると想定しないでください。 同様の理由で、アプリケーションからの一連の要求が常にサービスの同じインスタンスにルーティングされなくても済むように、サービスはステートレスになるように設計します。 キューからメッセージを読み取り、それらを処理するサービスを設計する場合、サービスのどのインスタンスが特定のメッセージを処理するかを事前に想定しないでください。 キューの長さが長くなると、自動スケールによってサービスの追加インスタンスが開始される可能性があるためです。 「競合コンシューマー パターン」には、この状況に対処する方法が記載されています。

  • ソリューションで長期タスクを実装する場合、このタスクを作成して、スケールアウトとスケールインの両方がサポートされるようにします。 しかるべき注意を払わなければ、そのようなタスクにより、システムをスケールインするときにプロセスのインスタンスが正常にシャットダウンされなかったり、プロセスが強制的に終了された場合にデータが失われたりする可能性があります。 可能であれば、長期タスクをリファクタリングし、プロセスを分割して、より小さい、個別のまとまりで実行されるようにします。 「パイプとフィルターのパターン」には、これを行う方法の例が記載されています。

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

  • クラウド サービスでホストされているアプリケーションの worker ロールなど、別個のコンピューティング インスタンスでバックグラウンド タスクが実行されている場合、別のスケーリング ポリシーを使用してアプリケーションのさまざまな部分をスケールする必要が生じることがあります。 たとえば、バックグラウンド コンピューティング インスタンスの数を増やさずに、ユーザーインターフェイス (UI) コンピューティング インスタンスをさらにデプロイしたり、その反対の処理を行ったりしなくてはならない場合があります。 異なるレベルのサービス (Basic、および Premium サービス パッケージなど) を提供する場合、SLA に準拠するために、Basic サービス パッケージのコンピューティング リソースよりも、Premium サービス パッケージのコンピューティング リソースの方をより積極的にスケールアウトする必要が生じる可能性があります。

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

    • たとえば、キューに 50,000 件のメッセージがある可能性があるが、最も古いメッセージのクリティカル時間が 500 ミリ秒であり、そのエンドポイントで、電子メールを送信するためのサードパーティ Web サービスとの統合が処理されるとします。 ビジネス利害関係者は、それをスケーリングのために余分なコストを使うことを正当化しない期間であるとみなす可能性があります。
    • 一方、キューに 500 個のメッセージがある可能性があり、クリティカル時間は同じ 500 ミリ秒だが、エンドポイントは、ビジネス利害関係者が 100 ミリ秒以下の応答時間を定義した何らかのリアルタイム オンライン ゲームのクリティカル パスの一部であるとします。 その場合は、スケールアウトが有効であると言えます。
    • 自動スケーリングの決定にクリティカル時間を利用するには、メッセージの送信および処理中に、それらのヘッダーに関連情報を自動的に追加するライブラリを用意すると便利です。 この機能を提供するそのようなライブラリの 1 つは NServiceBus です。

  • 1 時間当たりに行われた命令数や複雑なトランザクションの平均実行時間など、ビジネス プロセスを測定するカウンターに基づいて自動スケール戦略を作成する場合は、そのようなタイプのカウンターから得られる結果と実際のコンピューティング能力の要件の関係を完全に理解してください。 ビジネス プロセス カウンターの変更に応じて、複数のコンポーネントまたはコンピューティング ユニットをスケールする必要が生じる場合があります。

  • システムによって過度なスケールアウトが試行されたり、多数のインスタンス実行に関連するコストが生じたりしないようにするために、自動的に追加できるインスタンスの最大数を制限することを検討してください。 大部分の自動スケール メカニズムでは、任意のルールに基づいてインスタンスの最小数と最大数を指定できます。 また、インスタンスの最大数を設定しても、システムが依然としてオーバーロードの状態である場合には、システムによって提供される機能を適度に低下させることを検討してください。

  • 自動スケールは、ワークロードの急激な増加を処理する最も適切なメカニズムではない場合もあることに留意してください。 サービスの新しいインスタンスをプロビジョニングして開始したり、リソースをシステムに追加したりする作業は時間を要します。また、追加したそれらのリソースが使用できるようになるまでに、ピーク需要が過ぎてしまう可能性もあります。 このようなときは、サービスを調整したほうがよい場合があります。 詳細については、「調整パターン」を参照してください。

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

  • 自動スケール メカニズムでは、自動スケール プロセスを監視し、各自動スケール イベントの詳細 (イベントがトリガーされた理由、追加または削除されたリソース、それらの日時) を記録する必要があります。 カスタムの自動スケール メカニズムを作成する場合は、この機能が組み込まれていることを確認してください。 情報を分析して、自動スケール戦略の効果を測定し、必要に応じて調整します。 使用パターンがより明確な場合は短期間の調整を行い、ビジネスが拡大したり、アプリケーションの要件が増加したりする場合は長期間の調整を行うことができます。 アプリケーションが自動スケールの定義された上限に到達すると、このメカニズムにより、必要に応じて追加リソースを手動で開始できる操作者にアラートが出される可能性もあります。 このような状況下では、ワークロードが軽減された後、操作者はこれらのリソースを手動で削除する責任を負う場合もあることに留意してください。

自動スケールを実装する場合、次のパターンとガイダンスも関連する可能性があります。

  • スロットル パターン。 このパターンは、需要の増加によってリソースに極端な負荷がかけられた場合に、アプリケーションがどのようにして継続的に機能し、SLA に準拠できるかを示します。 自動スケールとともに調整を使用して、システムがスケールアウトしている間にシステムに過剰な負荷が掛からないようにすることができます。

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

  • 監視と診断。 インストルメンテーションと製品利用統計情報は、自動スケール プロセスを促進できる情報を収集するために不可欠です。