注
アプリケーションのすべての種類で自動スケーリングが可能: Windows および Linux (コードとコンテナーとしてデプロイします)。 デプロイ スロット トラフィックでは、自動スケーリングはサポートされていません。
自動スケーリングは、Web アプリと App Service プランのスケーリング決定を自動的に処理するスケールアウト オプションです。 これは、スケジュールとリソースに基づいてスケーリング ルールを定義できる Azure 自動スケーリングとは異なります。
自動スケーリングでは、スケーリング設定を調整して、アプリのパフォーマンスを向上させ、コールド スタートの問題を回避することができます。 プラットフォーム上にあるスケールアウト時にバッファーとして機能するインスタンスが事前にウォームアップすることで、パフォーマンスのスムーズな移行を実現します。 課金は、事前にウォームアップされたインスタンスを含め、すべてのインスタンスに対して 1 秒単位で行われます。
次の表は、App Service で使用できるスケールアウト オプションとスケールイン オプションを比較しています。
| [手動] | 自動スケーリング | 自動スケーリング | |
|---|---|---|---|
| 利用可能な価格レベル | Basic 以上 | Standard 以上 | Premium V2 (P1V2、P2V2、および P3V2) の価格レベル。 Premium V3 (P0V3、P1V3、P2V3、P3V3、P1MV3、P2MV3、P3MV3、P4MV3、および P5MV3) の価格レベル。 |
| ルールベースのスケーリング | いいえ | はい | いいえ。プラットフォームは、HTTP トラフィックに基づいてスケールアウトとスケールインを管理します。 |
| スケジュールベースのスケーリング | いいえ | はい | いいえ |
| 常時使用可能なインスタンス | いいえ。Web アプリは、手動でスケーリングされたインスタンスの数で実行されます。 | いいえ。Web アプリは、自動スケール ルールに定義されているしきい値に基づいて、スケールアウト操作中に使用可能な他のインスタンスで実行されます。 | 可 (最小 1) |
| 事前ウォーミングされたインスタンス | いいえ | いいえ | 可 (既定 1) |
| アプリごとの最大値 | いいえ | いいえ | はい |
自動スケーリングの仕組み
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 アフィニティは自動スケーリングにどのように影響しますか?
Azure App Service は、ARR アフィニティとして知られるアプリケーション要求ルーティング処理 Cookie を使用します。 ARR アフィニティ Cookie は、利用可能なインスタンスではなく、Cookie に関連付けられたサーバーにのみ要求を送信するため、スケーリングを制限します。 状態を保存するアプリの場合は、スケールアップ (単一インスタンスのリソースを増やすこと) をお勧めします。 ステートレス アプリの場合、スケールアウト (インスタンスの追加) はより柔軟でスケーラビリティがあります。 ARR アフィニティ Cookie は、App Service では既定で有効になっています。 アプリケーションのニーズに応じて、自動スケーリングを使用するときに ARR アフィニティ Cookie を無効にすることを選択できます。
ARR アフィニティ Cookie を無効にするには、App Service アプリを選択し、[設定] の下にある [構成] を選択します。 次に、[ 全般設定 ] タブを選択します。[ セッション アフィニティ] で [ オフ ] を選択し、[ 保存 ] ボタンを選択します。