注
自動スケーリングは、Windows と Linux (コードまたはコンテナーとしてデプロイ) のすべてのアプリの種類で使用できます。
デプロイ スロット トラフィックでは、自動スケーリングはサポートされていません。
自動スケーリングは、Web アプリと App Service プランのスケーリング決定を自動的に処理するスケールアウト オプションです。 これは、メトリックとスケジュールに基づいてスケーリング ルールを定義できる Azure 自動スケーリングとは異なります。
自動スケーリングを使用すると、スケーリング設定を調整してパフォーマンスを向上させ、コールドスタートの遅延を減らすことができます。 プラットフォームは、バッファーとして機能するプリウォーミング インスタンスを備え、スムーズなスケーリング遷移を保証します。 事前に予約されたインスタンスを含め、すべてのインスタンスに対して 1 秒あたりに課金されます。
開始する前に
App Service での自動スケーリングは、自動スケーリングとは異なります。
ルールやスケジュールを作成せずに、App Service で HTTP トラフィックに基づいて自動的にスケーリングを処理する場合は、自動スケーリングを使用します。
自動スケーリング (この記事):
- 受信 HTTP トラフィックに基づいて自動的にスケーリングする
- アプリごとに構成
- 常時対応、アプリごとの制限、最大バースト、および事前起動インスタンスをサポート
自動スケーリング:
- メトリック (CPU、メモリ、キューの長さ、カスタム メトリック) を使用します
- スケジュールベースのスケーリングをサポート
- App Service プラン全体に適用されます
CPU、メモリ、または時間ベースのスケーリングが必要な場合は、代わりに自動スケーリングを使用します。
App Service プランに対してアクティブにする必要があるスケーリング方法は 1 つだけです。
App Service で使用できるスケールアウト オプション
| [手動] | 自動スケーリング | 自動スケーリング | |
|---|---|---|---|
| 使用可能な階層 | Basic 以上 | Standard 以上 | Premium v2 と Premium v3 |
| ルールベースのスケーリング | いいえ | はい | いいえ (トラフィック ベース) |
| スケジュールベースのスケーリング | いいえ | はい | いいえ |
| 常時使用可能なインスタンス | いいえ | いいえ | あり (最小 1) |
| 事前ウォーミングされたインスタンス | いいえ | いいえ | あり (既定 1) |
| アプリごとの最大値 | いいえ | いいえ | はい |
| ARR アフィニティの動作 | 既定で有効 | 手動で無効にしない限りオン | 手動で無効にする必要がある |
自動スケーリングの仕組み
App Service プランの自動スケーリングを有効にし、各 Web アプリのインスタンスの範囲を構成します。 Web アプリが HTTP トラフィックの受信を開始すると、App Service は負荷を監視し、インスタンスを追加します。 App Service プラン内の複数の Web アプリを同時にスケールアウトする必要がある場合、リソースが共有される場合があります。
自動的にスケールアウトする必要があるシナリオをいくつか次に示します。
- リソース メトリックに基づいて自動スケーリング ルールを設定する必要はありません。
- 同じ App Service プラン内の Web アプリを、互いに異なる方法で個別にスケーリングする必要があります。
- Web アプリはデータベースまたはレガシ システムに接続されており、Web アプリほど高速にスケーリングできない可能性があります。 スケーリングを自動的に行うと、App Service プランでスケーリングできるインスタンスの最大数を設定できます。 この設定は、Web アプリがバックエンドを圧倒しないようにするのに役立ちます。
自動スケーリングを有効にする
最大バースト設定は、App Service プランが受信 HTTP 要求に基づいて増やすことができるインスタンスの最大数を表します。 Premium v2 および v3 プランでは、最大 30 個のインスタンスを指定できます。 最大バースト数は、App Service プランに指定されたワーカーの数以上である必要があります。
自動スケーリングを有効にするには、Web アプリの左側のメニューに移動します。 [ 設定] で、[ スケールアウト (App Service プラン)]を選択します。 [自動] を選択し、[最大バースト] の値を更新して、[保存] ボタンを選択します。
Web アプリ インスタンスの最小数を設定する
アプリ レベルの設定 [Always ready instances] では、インスタンス の最小数を指定します。 読み込みが Always Ready インスタンスで設定されている最小数を超えた場合は、App Service プランの指定された 最大バースト 値まで、追加のインスタンスが追加されます。
Web アプリ インスタンスの最小数を設定するには、Web アプリの左側のメニューに移動し、[ スケールアウト (App Service プラン)]を選択します。 [常時使用可能なインスタンス] の値を更新し、[保存] ボタンを選択します。
Web アプリ インスタンスの最大数を設定する
[最大スケール制限] の値は、Web アプリがスケーリングできるインスタンスの最大数を設定します。 最大スケール制限は、データベースなどのダウンストリーム コンポーネントのスループットが制限されている場合に役立ちます。 アプリごとの最大値は、1 から最大バースト値までの間で指定できます。
Web アプリ インスタンスの最大数を設定するには、Web アプリの左側のメニューに移動し、[ スケールアウト (App Service プラン)]を選択します。 [スケールアウト制限を適用する] を選択し、[最大スケール制限] を更新して、[保存] ボタンを選択します。
事前ウォーミングされたインスタンスを更新する
事前ウォーミングされたインスタンス設定は、HTTP スケールおよびアクティブ化イベント中にウォームされたインスタンスをバッファーとして提供します。 事前ウォーミングされたインスタンスは、スケールアウトの上限に達するまでバッファーに格納され続けます。 既定の事前ウォーミングされたインスタンス数は 1 であり、ほとんどのシナリオでは、この値は 1 のままである必要があります。
ポータルで事前ウォーミングされたインスタンスの設定を変更することはできません。 代わりに Azure CLI を使用する必要があります。
自動スケーリングを無効にする
自動スケーリングを無効にするには、Web アプリの左側のメニューに移動し、 スケールアウト (App Service プラン) を選択します。 [ 手動 ] を選択し、[ 保存 ] ボタンを選択します。
よく寄せられる質問
自動スケーリングは Azure Functions アプリをサポートしていますか?
いいえ。自動スケーリングを有効にする App Service プランには、Azure App Service Web アプリのみを含めることができます。 Azure Functions アプリの場合は、代わりに Azure Functions Premium プラン を使用することをお勧めします。
注意事項
App Service Web アプリと Azure Functions アプリが同じ App Service プランにある場合、自動スケーリングは無効になります。
自動スケーリングはバックグラウンドでどのように機能していますか?
自動的にスケーリングするように設定されたアプリケーションは継続的に監視され、少なくとも数秒に 1 回は作業者の正常性を評価します。 システムがアプリケーションの負荷増加を検出すると、正常性チェックの頻度が高くなります。 ワーカーの健康状態が悪化し、要求の処理速度が低下した場合は、他のインスタンスが要求されます。 インスタンスが追加される速度は、個々のアプリケーションの負荷パターンと起動時間によって異なります。 起動時間が短く、負荷が断続的に急増するアプリケーションでは、数秒から 1 分ごとに 1 つの仮想マシンが追加される場合があります。
負荷が落ち着くと、プラットフォームでスケーリングの可能性を確認し始めます。 このプロセスは、通常、負荷の増加が停止してから約 5 ~ 10 分後に開始されます。 スケールイン中、インスタンスは最大で数秒から 1 分に 1 つの割合で削除されます。
同じ App Service プラン内に複数の Web アプリケーションがデプロイされている場合、プラットフォームは使用可能なインスタンス間でリソースの割り当てを試みます。 この割り当ては、個々の Web アプリケーションの負荷に基づいています。
事前ウォーミングされたインスタンスの請求はどのように行われますか?
事前ウォーミングされたインスタンスに対する請求方法を理解するために、次のシナリオを考えてみましょう。たとえば、Web アプリに 5 つのインスタンスが常時準備されており、1 つの事前ウォーミングされたインスタンスが既定値として設定されているとします。
Web アプリがアイドル状態で HTTP 要求を受信していない場合は、5 つの常時使用可能なインスタンスで実行されます。 この時点では、常時使用可能なインスタンスが使用されておらず、事前ウォーミングされたインスタンスが割り当てられていないため、事前ウォーミングされたインスタンスに対して課金されることはありません。
ただし、Web アプリが HTTP 要求の受信を開始し、常時対応の 5 つのインスタンスがアクティブになるとすぐに、事前に予約されたインスタンスが割り当てられます。 この時点で課金が開始されます。
HTTP 要求のレートが増加し続け、App Service が最初の 5 つのインスタンスを超えてスケーリングすることを決定した場合は、事前に予約されたインスタンスの使用が開始されます。 つまり、アクティブなインスタンスが 6 個ある場合、7 個目のインスタンスが即座にプロビジョニングされ、事前ウォーミングされたバッファを満たします。
このスケーリング プロセスと事前ウォーミングは、アプリの最大インスタンス数に達するまで続行されます。 注意が必要な点は、インスタンスが事前ウォーミングされたり、最大インスタンス数を超えてアクティブ化されたりしないことです。
AppServiceHTTPLogsのログ エントリが 404 状態の/admin/host/pingと似ているのはなぜですか。
App Service の自動スケーリングでは、 /admin/host/ping エンドポイントと、プラットフォームに固有のその他の正常性チェック メカニズムが定期的にチェックされます。 場合によっては、既存のプラットフォーム構成により、これらの ping によって 404 エラーが返されることがあります。 ただし、これらの 404 エラーは、アプリの可用性やスケーリング パフォーマンスに影響を与えないようにすることが重要です。
Web アプリから 5xx 状態が返された場合、これらのエンドポイント ping を実行すると断続的な再起動が発生する可能性がありますが、このシナリオは一般的ではありません。 Web アプリがこのエンドポイントで 5xx 状態を返していないことを確認します。 これらの ping エンドポイントはカスタマイズできません。
自動スケーリング イベント中にスケールアウトされたインスタンスの数を追跡するにはどうすればよいですか?
AutomaticScalingInstanceCount メトリックは、アプリが実行されている仮想マシンの数を報告します。デプロイされている場合は、事前ウォーミングされたインスタンスも含まれます。 このメトリックは、自動スケーリング イベント中に Web アプリがスケールアウトしたインスタンスの最大数を追跡するためにも使用できます。 このメトリックは、 自動スケーリング が有効になっているアプリでのみ使用できます。
ARR アフィニティは自動スケーリングにどのように影響しますか?
注
App Service プランで自動スケーリングを有効にすると、プラン内のすべての既存のアプリで ARR アフィニティが自動的に無効になります。
Azure App Service は、ARR アフィニティとして知られるアプリケーション要求ルーティング処理 Cookie を使用します。 ARR アフィニティ Cookie は、利用可能なインスタンスではなく、Cookie に関連付けられたサーバーにのみ要求を送信するため、スケーリングを制限します。 状態を保存するアプリの場合は、スケールアップ (単一インスタンスのリソースを増やすこと) をお勧めします。 ステートレス アプリの場合、スケールアウト (インスタンスの追加) はより柔軟でスケーラビリティがあります。 ARR アフィニティ Cookie は、App Service では既定で有効になっています。 ただし、自動スケーリングを使用する場合は、適切なスケーリングを確保するために ARR アフィニティ Cookie を無効にする必要があります。
ARR アフィニティ Cookie を無効にするには、App Service アプリを選択し、[設定] の下にある [構成] を選択します。 次に、[ 全般設定 ] タブを選択します。[ セッション アフィニティ] で [ オフ ] を選択し、[ 保存 ] ボタンを選択します。
App Service プランでは、アプリで常に準備が整う設定よりも割り当て済みのインスタンスが多く表示されるのはなぜですか?
プランに割り当てられたインスタンスが、そのプラン内のどのアプリでも使用される常に利用可能なインスタンス数を上回っている場合に、これが発生する可能性があります。 割り当てられたインスタンスは、プランを実行する必要があるインスタンスの最小数を表します。 この値が常に使用可能な値より大きい場合、プランはその最小値を引き続き使用します。
この構成を修正するには、プラン内の任意のアプリの常時対応インスタンス数を更新します。 値を変更する必要があります。 同じ値を保存しても再計算はトリガーされません。 更新後、プランは、割り当てられたインスタンス数を、プラン内のすべてのアプリで常に使用可能な最大値に設定します。
この更新プログラムは、 CLI または Azure Resource Manager API を使用して完了する必要があります。 現時点では、Azure portal によって再計算が正しく適用されません。
例： プランには、7 つのインスタンスが割り当てられている場合があります。 プランに含まれるアプリには、常に2、3、5の値が設定されている可能性があります。 課金は、インスタンスの最小数である 7 を基準にしています。 アプリの常時対応の値 (たとえば 3 から 4) を変更すると、プランが再計算されます。 次に、割り当てられたインスタンス数を 5 に設定します。これは、常に使用可能な最大値です。