自動スケールと App Service Environment v1
重要
この記事は、App Service Environment v1 に関するものです。 App Service Environment v1 と v2 は、2024 年 8 月 31 日の時点で廃止されます。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。
2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 は廃止された製品になるため、これらのワークロードに対してはサービス レベル アグリーメント (SLA) とサービス クレジットが適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止が開始されており、これが使用中のアプリやデータの可用性とパフォーマンスに影響を及ぼす場合があります。
お客様は、App Service Environment v3 への移行を迅速に完了する必要があります。これを行わないと、アプリとリソースが削除される場合があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、使用中のリソースと関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。
時間的猶予が必要な場合は、移行を完了するために 1 回限りの 30 日間の猶予期間を設定することができます。 この猶予期間の詳細と要求方法については、「猶予期間の概要」を確認した後、Azure portal に移動し、各 App Service Environment の [移行] ブレードにアクセスしてください。
App Service Environment v1/v2 の提供終了に関する最新情報については、App Service Environment v1 と v2 の提供終了に関する更新情報の記事を参照してください。
Azure App Service Environment は " 自動スケール" をサポートしています。 メトリックまたはスケジュールに基づいて個々のワーカー プールの規模を自動調整することができます。
自動スケールでは、予算または負荷プロファイルに適合するように App Service Environment を自動的に拡大または縮小することにより、リソースの使用率が最適化されます。
ワーカー プールの自動スケールの構成
自動スケール機能には、ワーカー プールの [設定] タブからアクセスできます。
そこからは、App Service プランのスケールを行う場合と同じ操作となるので、非常になじみの深いインターフェイスとなります。
また、自動スケール プロファイルを構成することもできます。
自動スケール プロファイルは、スケールに対して制限を設定するのに便利です。 このように、スケールの下限値 (1) を設定してパフォーマンスの状態を安定させると共に、スケールの上限値 (2) を設定して使用上限を予測可能とすることができます。
プロファイルを定義したら、自動スケール ルールを追加して、ワーカー プール内のインスタンスの数をプロファイルで定義されている範囲内で増減することができます。 自動スケール ルールには、メトリックが使用されます。
ワーカー プールまたはフロントエンドの任意のメトリックを使用して、自動スケール ルールを定義することができます。 これらのメトリックは、リソース ブレード グラフで監視したり、アラートを設定したりできるメトリックと同じものです。
自動スケールの例
App Service Environment の自動スケールの説明は、シナリオを通して行うのが最も効果的です。
この記事では、自動スケールを設定するときに必要なすべての考慮事項を説明します。 この記事では、App Service Environment でホストされている App Service Environment の自動スケールを考慮に入れる場合に必要なあらゆるやり取りについて説明します。
シナリオの概要
Frank 氏は企業の sysadmin です。彼は管理するワークロードの一部をApp Service Environment に移行しました。
App Service Environment は、次のように手動で拡張するように構成されています。
- フロントエンド: 3
- ワーカー プール 1:10
- ワーカー プール 2:5
- ワーカー プール 3:5
ワーカー プール 1 は運用環境のワークロードとして使用されます。一方、ワーカー プール 2 とワーカー プール 3 は品質保証 (QA) および開発用のワークロードとして使用されます。
QA および開発用の App Service プランは、手動スケールに構成されます。 この運用環境の App Service プランは、負荷とトラフィックの変動に対処するために自動スケールに設定されます。
Frank は、アプリケーションに関する知識がきわめて豊富です。 このアプリケーションは従業員がオフィスにいる間に使用する基幹業務 (LOB) アプリケーションであることから、負荷がピークとなる時間帯は 9:00 AM から 6:00 PM であることがわかっています。 その後、ユーザーがその日の業務を終了すると、使用率は低下します。 アプリにはユーザーがリモートからモバイル デバイスまたは自宅の PC を使ってアクセスできるので、ピーク時間外にも負荷は発生します。 運用環境の App Service プランは、次のルールを使用して CPU 使用率に基づき自動スケールを行うように構成済みです。
| 自動スケール プロファイル – 平日 – App Service プラン | 自動スケール プロファイル – 週末 – App Service プラン |
|---|---|
| [名前]: 平日のプロファイル | [名前]: 週末のプロファイル |
| スケール: スケジュールおよびパフォーマンスのルール | スケール: スケジュールおよびパフォーマンスのルール |
| プロファイル: 平日 | プロファイル: 週末 |
| 種類: 繰り返し | 種類: 繰り返し |
| 対象範囲: 5 ～ 20 のインスタンス | 対象範囲: 3 ～ 10 のインスタンス |
| 日: 月曜日、火曜日、水曜日、木曜日、金曜日 | 日: 土曜日、日曜日 |
| 開始時刻: 9:00 AM | 開始時刻: 9:00 AM |
| タイム ゾーン: UTC-08 | タイム ゾーン: UTC-08 |
| 自動スケール ルール (スケールアップ) | 自動スケール ルール (スケールアップ) |
| リソース: 運用環境 (App Service 環境) | リソース: 運用環境 (App Service 環境) |
| メトリック: CPU % | メトリック: CPU % |
| 操作: 60% 超過 | 操作: 80% 超過 |
| 期間: 5 分 | 期間: 10 分 |
| 時間の集計: Average | 時間の集計: Average |
| アクション: カウント数を 2 ずつ増加 | アクション: カウント数を 1 ずつ増加 |
| クールダウン (分): 15 | クールダウン (分): 20 |
| 自動スケール ルール (スケールダウン) | 自動スケール ルール (スケールダウン) |
| リソース: 運用環境 (App Service 環境) | リソース: 運用環境 (App Service 環境) |
| メトリック: CPU % | メトリック: CPU % |
| 操作: 30% 未満 | 操作: 20% 未満 |
| 期間: 10 分 | 期間: 約 15 分 |
| 時間の集計: Average | 時間の集計: Average |
| アクション: カウント数を 1 ずつ減少 | アクション: カウント数を 1 ずつ減少 |
| クールダウン (分): 20 | クールダウン (分): 10 |
App Service プランの増加率
自動スケールを行うように構成された App Service プランは、1 時間あたりの最大レートで処理を行います。 このレートは、自動スケール ルールで指定された値に基づいて算出できます。
ワーカー プールに対するスケールの変更は瞬時に適用されるわけではないので、App Service Environment の自動スケールでは " App Service プランの増加率 " を理解し計算することが重要となります。
App Service プランの増加率は次のように計算します。
運用環境の App Service プランの平日プロファイルに対する自動スケール - スケールアップ ルールに基づくと、計算式は次のようになります。
運用環境の App Service プランの週末プロファイルに対する自動スケール - スケールアップ ルールに基づく場合、計算式は次のようになります。
この値は、スケールダウン操作についても計算できます。
運用環境の App Service プランの平日プロファイルに対する自動スケール - スケールダウン ルールに基づくと、計算式は次のようになります。
運用環境の App Service プランの週末プロファイルに対する自動スケール - スケールダウン ルールに基づく場合、計算式は次のようになります。
運用環境の App Service プランは、平日は 1 時間あたり 8 個のインスタンスという最大レートで成長することができ、週末は 1 時間あたり 4 個のインスタンスという最大レートで成長することができます。 平日は 1 時間あたり 4 個のインスタンスという最大レートでインスタンスをリリースし、週末は 1 時間あたり、6 個のインスタンスという最大レートでインスタンスをリリースできます。
複数の App Service プランを 1 つのワーカー プールでホストする場合は、そのワーカー プールでホストされるすべての App Service プランの増加率の合計として " 合計増加率 " を計算する必要があります。
App Service プランの増加率を使用してワーカー プールの自動スケール ルールを定義する
自動スケールを行うように構成された App Service プランのホストとなるワーカー プールには、容量のバッファーを割り当てる必要があります。 自動スケール操作で App Service プランを必要に応じて拡大したり縮小したりするために別途必要となる容量が、このバッファーによって確保されます。 最小バッファーは、計算した App Service プラン増加率合計となります。
App Service Environment のスケール操作は適用されるのに多少時間がかかるため、何らかの変更を行う場合は、スケール操作の進行中は起こりうる需要の変化を考慮する必要があります。 この時間差に対応するため、計算した App Service プラン増加率合計を、自動スケール操作ごとに追加される最小インスタンス数として使用することをお勧めします。
Frank は、この情報を使用して次の自動スケール プロファイルとルールを定義することができます。
| 自動スケール プロファイル – 平日 | 自動スケール プロファイル – 週末 |
|---|---|
| [名前]: 平日のプロファイル | [名前]: 週末のプロファイル |
| スケール: スケジュールおよびパフォーマンスのルール | スケール: スケジュールおよびパフォーマンスのルール |
| プロファイル: 平日 | プロファイル: 週末 |
| 種類: 繰り返し | 種類: 繰り返し |
| 対象範囲: 13 ～ 25 のインスタンス | 対象範囲: 6 ～ 15 のインスタンス |
| 日: 月曜日、火曜日、水曜日、木曜日、金曜日 | 日: 土曜日、日曜日 |
| 開始時刻: 7:00 AM | 開始時刻: 9:00 AM |
| タイム ゾーン: UTC-08 | タイム ゾーン: UTC-08 |
| 自動スケール ルール (スケールアップ) | 自動スケール ルール (スケールアップ) |
| リソース: ワーカー プール 1 | リソース: ワーカー プール 1 |
| メトリック: WorkersAvailable | メトリック: WorkersAvailable |
| 操作: 8 未満 | 操作: 3 未満 |
| 期間: 20 分 | 期間: 30 分 |
| 時間の集計: Average | 時間の集計: Average |
| アクション: カウント数を 8 ずつ増加 | アクション: カウント数を 3 ずつ増加 |
| クールダウン (分): 180 | クールダウン (分): 180 |
| 自動スケール ルール (スケールダウン) | 自動スケール ルール (スケールダウン) |
| リソース: ワーカー プール 1 | リソース: ワーカー プール 1 |
| メトリック: WorkersAvailable | メトリック: WorkersAvailable |
| 操作: 8 超過 | 操作: 3 超過 |
| 期間: 20 分 | 期間: 約 15 分 |
| 時間の集計: Average | 時間の集計: Average |
| アクション: カウント数を 2 ずつ減少 | アクション: カウント数を 3 ずつ減少 |
| クールダウン (分): 120 | クールダウン (分): 120 |
プロファイルで定義される対象範囲は、App Service プランのプロファイルで定義された最小インスタンス + バッファーによって算出されます。
最大範囲は、ワーカー プールでホストされているすべての App Service プランのすべての最大範囲の合計になります。
スケールアップ ルールの増加数は、少なくとも 1X スケールアップの App Service プランの増加率に設定する必要があります。
減少数は、1/2X スケールダウンの App Service プラン増加率と 1X スケールダウンの App Service プラン増加率との間のいずれかの値に調整することができます。
フロントエンド プールの自動スケール
フロントエンドの自動スケール ルールはワーカー プールの場合よりも簡単です。 主に
確認しておくべき点は、測定およびクールダウン タイマーの期間を設定する際には App Service プランに対するスケール操作が瞬間的なものではないということを必ず考慮に入れる必要があるということです。
このシナリオで、フランクはフロントエンドが 80% の CPU 使用率に到達すると、エラー率が増大することを認識し、自動スケール ルールを設定して以下のようにインスタンス数を増やしています。
| 自動スケール プロファイル – フロントエンド |
|---|
| [名前]: 自動スケーリング – フロントエンド |
| スケール: スケジュールおよびパフォーマンスのルール |
| プロファイル: 毎日 |
| 種類: 繰り返し |
| 対象範囲: 3 ～ 10 のインスタンス |
| 日: 毎日 |
| 開始時刻: 9:00 AM |
| タイム ゾーン: UTC-08 |
| 自動スケール ルール (スケールアップ) |
| リソース: フロントエンド プール |
| メトリック: CPU % |
| 操作: 60% 超過 |
| 期間: 20 分 |
| 時間の集計: Average |
| アクション: カウント数を 3 ずつ増加 |
| クールダウン (分): 120 |
| 自動スケール ルール (スケールダウン) |
| リソース: ワーカー プール 1 |
| メトリック: CPU % |
| 操作: 30% 未満 |
| 期間: 20 分 |
| 時間の集計: Average |
| アクション: カウント数を 3 ずつ減少 |
| クールダウン (分): 120 |