自動スケールと App Service Environment v1

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 プランは、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 は、この情報を使用して次の自動スケール プロファイルとルールを定義することができます。

プロファイルで定義される対象範囲は、App Service プランのプロファイルで定義された最小インスタンス + バッファーによって算出されます。

最大範囲は、ワーカー プールでホストされているすべての App Service プランのすべての最大範囲の合計になります。

スケールアップ ルールの増加数は、少なくとも 1X スケールアップの App Service プランの増加率に設定する必要があります。

減少数は、1/2X スケールダウンの App Service プラン増加率と 1X スケールダウンの App Service プラン増加率との間のいずれかの値に調整することができます。

フロントエンド プールの自動スケール

フロントエンドの自動スケール ルールはワーカー プールの場合よりも簡単です。 主に
確認しておくべき点は、測定およびクールダウン タイマーの期間を設定する際には App Service プランに対するスケール操作が瞬間的なものではないということを必ず考慮に入れる必要があるということです。

このシナリオで、フランクはフロントエンドが 80% の CPU 使用率に到達すると、エラー率が増大することを認識し、自動スケール ルールを設定して以下のようにインスタンス数を増やしています。