Azure App Service での自動スケーリング
Note
アプリケーションのすべての種類で自動スケーリングが可能: Windows および Linux (コードとコンテナーとしてデプロイします)。 デプロイ スロット トラフィックでは、自動スケーリングはサポートされていません。
自動スケーリングは、Web アプリと App Service プランのスケーリングに関する決定を自動的に処理する新しいスケールアウト オプションです。 これは、スケジュールとリソースに基づいてスケーリング ルールを定義できる、既存の Azure 自動スケーリングとは異なるものです。 自動スケーリングでは、スケーリング設定を調整して、アプリのパフォーマンスを向上させ、コールド スタートの問題を回避することができます。 プラットフォーム上にあるスケールアウト時にバッファーとして機能するインスタンスが事前にウォームアップすることで、パフォーマンスのスムーズな移行を実現します。 課金は、事前にウォームアップされたインスタンスを含め、すべてのインスタンスに対して 1 秒単位で行われます。
以下は App Service で使用できるスケールアウト オプションとスケールイン オプションの比較です。
| [手動] | Autoscale | 自動スケーリング | |
|---|---|---|---|
| 利用可能な価格レベル | Basic および Up | Standard および Up | 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 アプリがバックエンドをあふれさせないようにするのに役立ちます。
自動スケーリングを有効にする
最大バーストは、受信 HTTP 要求に基づいて、App Service プランで増やすことができるインスタンスの最大数です。 Premium v2 と v3 プランの場合には、最大 30 インスタンスのバーストを設定できます。 最大バーストは、App Service プランに指定されたワーカーの数以上である必要があります。
自動スケーリングを有効にするには、Web アプリの左側のメニューで [スケールアウト (App Service プラン)] を選択します。 [自動] を選択し、[最大バースト] の値を更新して、[保存] ボタンを選択します。
Web アプリ インスタンスの最小数を設定する
Always Ready インスタンスは、インスタンスの最小数を指定するアプリ レベルの設定です。 読み込みが常に使用可能なインスタンスで処理できる量を超える場合は、追加のインスタンスが追加されます (App Service プラン向けに指定された最大バーストまで)。
Web アプリ インスタンス数を最小に設定するには、Web アプリの左側のメニューで [スケールアウト (App Service プラン)] を選択します。 [常時使用可能なインスタンス] の値を更新し、[保存] ボタンを選択します。
Web アプリ インスタンスの最大数を設定する
最大スケール制限は、Web アプリがスケーリングできるインスタンスの最大数を設定します。 最大スケール制限は、データベースなどのダウンストリーム コンポーネントのスループットが制限されている場合に役立ちます。 アプリごとの最大値は、1 から 最大バーストまでの間で指定できます。
Web アプリ インスタンス数を最大に設定するには、Web アプリの左側のメニューで [スケールアウト (App Service プラン)] を選択します。 [スケールアウト制限を適用する] を選択し、[最大スケール制限] を更新して、[保存] ボタンを選択します。
事前ウォーミングされたインスタンスを更新する
事前ウォーミングされたインスタンス数の設定により、HTTP スケールおよびアクティブ化イベント中に、ウォーミングされたインスタンスがバッファーとして提供されます。 事前ウォーミングされたインスタンスは、スケールアウトの上限に達するまでバッファーに格納され続けます。 事前ウォーミングされたインスタンスの既定の数は 1 であり、ほとんどのシナリオではこの値を 1 のままにしておく必要があります。
事前ウォーミングされたインスタンス数の設定は、ポータルでは変更できません。代わりに、Azure CLI か Azure PowerShell を使用する必要があります。
自動スケーリングを無効にする
自動スケーリングを無効にするには、Web アプリの左側のメニューで [スケールアウト (App Service プラン)] を選択します。 [手動] を選択し、[保存] ボタンを選択します。
自動スケーリングは Azure Function アプリをサポートしていますか?
注意事項
App Service Web Apps と Azure 関数アプリが同じ App Service プランにある場合、自動スケーリングは無効になります。
いいえ。自動スケーリングを有効にする App Service プランでは、Azure App Service Web アプリのみを使用できます。 Azure Functions の場合は、代わりに Azure Functions Premium プランを使用することをお勧めします。
自動スケーリングはバックグラウンドでどのように機能していますか?
自動的にスケーリングするように設定されたアプリケーションは継続的に監視され、少なくとも数秒に 1 回は作業者の正常性を評価します。 システムがアプリケーションの負荷増加を検出すると、正常性チェックの頻度が高くなります。 作業者の正常性状態が悪化し、ペースダウンが要求された場合は、追加のインスタンスが要求されます。 インスタンスが追加される速度は、個々のアプリケーションの負荷パターンと起動時間によって異なります。 起動時間が短く、断続的に負荷が発生するアプリケーションでは、数秒から 1 分ごとに 1 台の仮想マシンが追加されるのを確認できます。
負荷が落ち着くと、プラットフォームでスケーリングの可能性を確認し始めます。 このプロセスは通常、負荷の増加が止まってから約 5 - 10 分後に開始します。 スケールイン中、インスタンスは最大で数秒から 1 分に 1 つの割合で削除されます。
さらに、複数の Web アプリケーションが同じ App Service プラン内にデプロイされている場合、プラットフォームは個々の 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 アプリを選択し、[設定] の下にある [構成] を選択します。 次に、[全般設定] タブを選択します。[ARR アフィニティ] で [オフ] を選択し、[保存] ボタンを選択します。
その他のリソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示