App Service Environment v1 の構成

  • [アーティクル]

重要

この記事は、App Service Environment v1 に関するものです。 App Service Environment v1 は 2024 年 8 月 31 日に廃止される予定です。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 1 月 29 日の時点で、ARM/Bicep テンプレート、Azure Portal、Azure CLI、REST API などの使用可能な方法を使用して、新しい App Service Environment v1 リソースを作成することはできなくなります。 リソースの削除とデータの損失を防ぐために、2024 年 8 月 31 日より前に App Service Environment v3 に移行する必要があります。

概要

大まかに言えば、Azure App Service Environment は次に挙げるいくつかの主要なコンポーネントで構成されます。

  • App Service Environment ホステッド サービスで実行されるコンピューティング リソース
  • ストレージ
  • データベース
  • V1 (クラシック) または V2 (Resource Manager) Azure Virtual Network (VNet)
  • App Service Environment ホステッド サービスが実行されるサブネット

コンピューティング リソース

コンピューティング リソースは、4 つのリソース プールに使用します。 1 つの App Service Environment (ASE) には、フロント エンドと最大 3 つのワーカー プールが存在します。 3 つのワーカー プールすべてを使用する必要はありません。1 つか 2 つだけ使用することもできます。

リソース プール (フロント エンドおよびワーカー) 内のホストが直接テナントにアクセスすることはできません。 リモート デスクトップ プロトコル (RDP) でテナントに接続してそのプロビジョニングを変更したり、管理者として作業を行ったりすることはできません。

リソース プールの数とサイズは、自分で設定することができます。 ASE には、P1 ～ P4 の 4 つのサイズ オプションがあります。 これらのサイズとその価格設定の詳細については、「App Service の価格」を参照してください。 この数やサイズを変更することを "スケール操作" といいます。 一度に実行できるスケール操作は 1 つだけです。

フロントエンド: フロント エンドは、ASE に保持されているアプリの HTTP/HTTPS エンドポイントです。 皆さんがフロント エンドでワークロードを実行することはありません。

  • ASE の初期構成は 2 つの P2 です。これは、開発/テストのワークロードや負荷の水準が低い運用ワークロードを想定したものです。 負荷の水準が中から高となる運用ワークロードでは、P3 の採用を強くお勧めします。
  • 負荷の水準が中から高となる運用ワークロードでは、P3 を少なくとも 4 つにして、スケジュールされたメンテナンスの時間帯に実行されるフロント エンドを十分に確保することをお勧めします。 スケジュールされたメンテナンス作業によってフロント エンドが一度に 1 つ停止されます。 そのためメンテナンス作業中は、全体として使用できるフロントエンドの処理能力が低下します。
  • フロントエンドのプロビジョニングには最大 1 時間かかる可能性があります。
  • スケールの微調整の際には、各種メトリック (フロント エンド プールの CPU 使用率、メモリ使用率、アクティブな要求数) を監視する必要があります。 P3 での運用時に CPU 使用率またはメモリ使用率が 70% を超えている場合は、フロント エンドを追加してください。 アクティブな要求数が平均で 15,000 ～ 20,000 に達している場合も、フロント エンドを追加する必要があります。 全体的な目標は、P3 で運用中のフロント エンドごとに、CPU とメモリの使用率を 70% 未満に抑え、アクティブな要求数が平均で 15,000 未満になるようにすることです。

ワーカー:皆さんのアプリが実質的に実行される場所です。 App Service プランをスケールアップすると、関連付けられているワーカー プール内からワーカーが消費されます。

  • ワーカーを瞬時に追加することはできません。 プロビジョニングには最大 1 時間かかる可能性があります。
  • プールのコンピューティング リソースのサイズをスケールする場合、更新ドメインごとにかかる時間は 1 時間未満です。 ASE には 20 の更新ドメインがあります。 10 インスタンスの worker プールのコンピューティング サイズをスケールした場合、完了するまでに最大 10 時間かかる可能性があります。
  • ワーカー プールで使用されるコンピューティング リソースのサイズを変更すると、そのワーカー プールで実行中のアプリのコールド スタートが実行されます。

アプリが実行されていないワーカー プールのコンピューティング リソースのサイズを最も短時間で変更する方法は、以下のとおりです。

  • worker の数を 2 にスケールダウンします。 ポータルの最小スケールダウン サイズは 2 です。 インスタンスの割り当てが解除されるまでに数分かかります。
  • 新しいコンピューティング サイズとインスタンスの数を選択します。 この処理を始めてから完了するまでに最大 2 時間かかります。

アプリにより大きなコンピューティング リソース サイズが必要な場合は、前のガイダンスは使えません。 そのアプリをホストするワーカー プールのサイズを変更する代わりに、目的のサイズのワーカーが含まれる別のワーカー プールを設定し、アプリをそのプールに移動してください。

  • 必要なコンピューティング サイズのインスタンスを別のワーカー プールに別途作成します。 完了するまでに最大 1 時間かかります。
  • より大きなサイズを必要とするアプリをホストする App Service プランを、新たに構成したワーカー プールに割り当て直します。 これは 1 分未満で完了する高速の処理です。
  • 最初のワーカー プールをスケールダウンします (使用されないこれらのインスタンスが必要なくなった場合)。 この操作は、完了するまでに数分かかります。

自動スケール:コンピューティング リソースの使用を管理するのに役立つ手段の 1 つが自動スケールです。 自動スケールは、フロント エンド プールに対して実行することも、ワーカー プールに対して実行することもできます。 いずれかのプール タイプのインスタンス数を午前中は増やし、夜間は減らすといったことが可能です。 また、ワーカー プールから利用できるワーカー数が特定のしきい値を下回ったときにインスタンスを追加することもできます。

コンピューティング リソース プールのメトリックに基づいて自動スケール規則を設定する場合は、プロビジョニングの所要時間に注意してください。 App Service Environment の自動スケーリングの詳細については、App Service Environment で自動スケーリングを構成する方法に関するページを参照してください。

ストレージ

各 ASE には、500 GB の記憶域が構成されています。 この領域は、ASE 内のすべてのアプリケーションに使用されます。 この記憶域は ASE の一部であり、ユーザーの記憶域を使用するように切り替えることはできません。 仮想ネットワーク ルーティングまたはセキュリティを調整する場合も、Azure Storage へのアクセスを許可する必要があります。そうしないと、ASE が機能しません。

データベース

データベースには、環境を定義する情報だけでなく、環境内で実行されているアプリに関する詳細情報が格納されています。 これは、Azure が保持しているサブスクリプションの一部です。 ユーザーが直接操作することはできません。 仮想ネットワーク ルーティングまたはセキュリティを調整する場合も、SQL Azure へのアクセスを許可する必要があります。そうしないと、ASE が機能しません。

ネットワーク

ASE で使用される VNet には、ASE の作成時または事前に作成したネットワークを使用できます。 ASE の作成時にサブネットを作成すると、強制的にその仮想ネットワークと同じリソース グループ内に ASE が作成されます。 ASE で使用するリソース グループを VNet とは異なるものにする必要がある場合は、Azure Resource Manager テンプレートを使用して ASE を作成する必要があります。

ASE に使用される仮想ネットワークにはいくつかの制限があります。

  • リージョン仮想ネットワークを使用する必要があります。
  • ASE のデプロイ先となる 8 個以上のアドレスを持つサブネットが必要です。
  • いったんサブネットを ASE のホストとして使用したら、そのサブネットのアドレス範囲は変更できません。 このため、将来の ASE の拡大に対応できるように、サブネットに 64 個以上のアドレスが含まれるようにすることをお勧めします。
  • サブネットに配置できるのは ASE だけです。

ASE が含まれているホストされるサービスとは異なり、仮想ネットワークとサブネットは、ユーザーの管理下にあります。 仮想ネットワークの管理は、Virtual Network UI または PowerShell を使用して行うことができます。 ASE は、クラシック VNet または Resource Manager VNet にデプロイすることができます。 クラシック VNet と Resource Manager VNet とでは、ポータルと API の操作性が若干異なりますが、ASE の操作性は同じです。

ASE のホストとして使用する VNet は、RFC1918 のプライベート IP アドレスを使用することも、パブリック IP アドレスを使用することもできます。 RFC1918 でカバーされていない IP 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) を使用する場合は、ASE の作成前に、ASE に使用する独自の VNet とサブネットを作成する必要があります。

この機能では、Azure App Service が、指定した仮想ネットワークに配置されます。つまり、ASE でホストされているアプリは、ExpressRoute またはサイト間仮想プライベート ネットワーク (VPN) を通じて公開されているリソースに直接アクセスすることができます。 App Service Environment をホストしている仮想ネットワークから利用できるリソースにアクセスするために、App Service Environment 内のアプリにネットワーク機能を追加する必要はありません。 つまり、仮想ネットワーク内のリソースにアクセスしたり、仮想ネットワークに接続したりするために、VNET 統合やハイブリッド接続を使用する必要はありません。 ただし、仮想ネットワークに接続されていないネットワーク内のリソースにアクセスするために、その両方の機能を使用することはできます。

たとえば、サブスクリプションには含まれているものの、ASE のホストとなる仮想ネットワークには接続されていない仮想ネットワークがある場合、VNET 統合を使用することで、そのネットワークと統合することができます。 また、ハイブリッド接続を使用して、通常と同様の方法で他のネットワーク内のリソースにアクセスすることもできます。

ExpressRoute VPN を使用して仮想ネットワークを構成している場合、ASE に関するいくつかのルーティング ニーズに気を付ける必要があります。 ASE とは互換性がないユーザー定義ルート (UDR) 構成がいくつかあります。 ExpressRoute を使用した仮想ネットワークにおける ASE の実行の詳細については、ExpressRoute を使用した仮想ネットワーク内での App Service Environment の実行に関するページを参照してください。

受信トラフィックのセキュリティ保護

ASE に入ってくる受信トラフィックは、主に 2 つの方法で制御することができます。 ASE へのアクセスを許可する IP アドレスは、ネットワーク セキュリティ グループ (NSG) を使用して制御できます (「App Service Environment への受信トラフィックを制御する方法」を参照)。また、内部ロード バランサー (ILB) を使って ASE を構成することもできます。 さらに、これらの機能を組み合わせれば、NSG を使って、ILB ASE へのアクセスに制限を加えることも可能です。

ASE を作成すると、VNet に VIP が作成されます。 VIP には、外部と内部の 2 種類が存在します。 外部 VIP で ASE を作成した場合、その ASE 内のアプリには、インターネットでルーティングできる IP アドレスを介してアクセスすることができます。 内部 VIP を選択した場合、ASE は ILB を使って構成され、インターネットから直接アクセスすることはできません。 外部 VIP は ILB ASE でも必要ですが、この場合は、Azure の管理と保守を目的としたアクセスに限定されます。

ILB ASE の作成時には、ILB ASE で使用するサブドメインを指定することになります。また、指定したサブドメインに対しては、独自の DNS を管理する必要があります。 サブドメイン名は自分で設定するため、HTTPS アクセスに使用する証明書も自分で管理する必要があります。 ASE の作成後、その証明書を指定するように求められます。 ILB ASE の作成と使用の詳細については、テンプレートから ASEv1 を作成する方法に関するページを参照してください。

ポータル

App Service Environment の管理と監視は、Azure ポータルの UI を使って実行できます。 ASE があれば、ほとんどの場合、サイド バーに App Service 記号が表示されます。 この記号は、Azure ポータルに App Service Environment があることを示すために使用されます。

App Service Environment symbol

すべての App Service Environment を一覧表示する UI を開くには、該当するアイコンを使用するか、サイドバーの一番下にあるシェブロン (">" 記号) を選択し、App Service Environment を選択します。 表示されている ASE のいずれかを選択すると、監視および管理に使用される UI が開きます。

UI for monitoring and managing your App Service Environment

この最初のブレードには、ASE の一部のプロパティと、リソース プールごとのメトリック グラフが表示されます。 Essentials ブロックに表示されるプロパティの一部は、関連付けられているブレードを開くハイパーリンクです。 たとえば、仮想ネットワーク名 ( [仮想ネットワーク] ) を選択して、ASE が実行されている仮想ネットワークと関連付けられた UI を開くことができます。 App Service プランとアプリでそれぞれブレードが開き、ASE 内にある項目が一覧表示されます。

監視

グラフから、各リソース プールの多様なパフォーマンス メトリックを確認できます。 フロント エンド プールについては、CPU とメモリの平均値を監視できます。 ワーカー プールについては、使用されているプール数と使用できるプール数を監視できます。

ワーカー プール内のワーカーは、複数の App Service プランによって利用される場合があります。 ワークロードはフロント エンド サーバーと同様の方法では分散されないため、CPU とメモリの使用率からは有用な情報はそれほど得られません。 それまでに使用したワーカー数と、特に、このシステムを管理する場合に、他のシステムが使用できるワーカー数を追跡することは重要です。

グラフで追跡できるすべてのメトリックは、アラートの設定にも使用できます。 ここでのアラートの設定は、App Service の他の設定と同様に行います。 アラートを設定するには、アラートの UI 部分を使用するか、メトリック UI から [アラートの追加] を選択します。

Metrics UI

これまでに説明したメトリックは、App Service Environment メトリックです。 App Service プラン レベルで使用できるメトリックもあります。 これは、CPU とメモリの監視が重要な場合のメトリックです。

ASE では、App Service プランはすべて、App Service 専用のプランです。 つまり、その App Service プランに割り当てられているホストで実行されているアプリのみが、その App Service プラン内のアプリです。 App Service プランの詳細を確認するには、ASE の UI に表示される一覧から目的の App Service プランを選択するか、またはすべての App Service プランが表示される [Browse App Service plans (App Service プランの参照)] から目的の App Service プランを選択します。

設定

ASE ブレードには [設定] セクションがあり、そこにいくつかの重要な機能が用意されています。

[設定]>[プロパティ] :ASE ブレードを選択すると、 [設定] ブレードが自動的に開きます。 その一番上に [プロパティ] が表示されます。 プロパティには多数の項目があり、 [要点] に表示される項目と重複していますが、非常に役に立つのは [仮想 IP アドレス] と [送信 IP アドレス] です。

Settings blade and Properties

[設定]>[IP アドレス] :ASE に IP SSL (Secure Sockets Layer) アプリを作成する場合は、IP SSL アドレスが必要です。 このアドレスを取得するためには、割り当てが可能な独自の IP SSL アドレスが ASE に必要となります。 ASE の作成時に、この目的で使用できる IP SSL アドレスが 1 つ用意されますが、追加することもできます。 「App Service の価格」の「SSL 接続」セクションに記載されているとおり、追加の IP SSL アドレスは課金対象です。 追加の価格は、IP SSL の価格です。

[設定]>[フロントエンド プール] / [ワーカー プール] :各リソース プール ブレードでは、そのリソース プールに関する情報のみを確認できます。また、そのリソース プールのスケールを完全に制御できます。

各リソース プールの基本ブレードには、そのリソース プールのメトリックを使用したグラフが表示されます。 ASE ブレードのグラフと同様に、グラフにアクセスし、必要に応じてアラートを設定することができます。 特定のリソース プールに関する ASE ブレードからアラートを設定する操作は、リソース プールからアラートを設定する操作と同じです。 ワーカー プールの [設定] ブレードから、そのワーカー プールで実行されているアプリまたは App Service プランすべての一覧にアクセスできます。

Worker pool settings UI

ポータルのスケール機能

スケール処理には、次の 3 つがあります。

  • IP SSL に使用できる ASE 内の IP アドレス数を変更する。
  • リソース プールに使用されるコンピューティング リソースのサイズを変更する。
  • 手動または自動スケールで、リソース プールに使用されるコンピューティング リソース数を変更する。

ポータルでは、次の 3 とおりの方法でリソース プール内のサーバーの数を制御できます。

  • 上部にあるメイン ASE ブレードからのスケール操作。 フロント エンド プールとワーカー プールに対し、スケール構成の変更を複数加えることができます。 この変更は、すべて 1 回の操作で適用されます。
  • 個々のリソース プールの [設定] にある [スケール] ブレードからの手動スケール操作。
  • 最後に、個々のリソース プールの [スケール] ブレードから設定する自動スケールです。

ASE ブレードでスケール操作を使用するには、目的の数までスライダーをドラッグし、保存します。 この UI は、サイズの変更もサポートしています。

Scale UI

特定のリソース プールで手動または自動スケール機能を使用するには、 [設定] に移動し、必要に応じて >[フロントエンド プール] / または [ワーカー プール] に移動して、変更するプールを開きます。 次に、変更するプールを開きます。 [設定]>、 [スケールアウト] の順に移動するか、 [設定] 、>[スケールアップ] の順に移動します。 [スケールアウト] ブレードでは、インスタンスの数を制御できます。 [スケールアップ] では、リソース サイズを制御できます。

Scale settings UI

フォールト トレランスに関する考慮事項

App Service Environment は合計 55 個までのコンピューティング リソースを使用するように構成できます。 この 55 個のコンピューティング リソースのうち、ワークロードのホストに使用できるのは 50 個のみです。 その理由は 2 つあります。 フロントエンドのコンピューティング リソースは最小で 2 つです。 これにより、ワーカー プールの割り当てのサポートには最大で 53 個残ります。 フォールト トレランスを提供するには、次のルールに従い、追加のコンピューティング リソースを割り当てる必要があります。

  • 各ワーカー プールには、ワークロードに割り当てることができない追加のコンピューティング リソースを 1 つ以上用意する必要があります。
  • ワーカー プール内のコンピューティング リソースの数量が特定の値を超えた場合、フォールト トレランスのために別のコンピューティング リソースが必要になります。 この対応は、フロント エンド プールの場合には該当しません。

1 つのワーカー プール内でのフォールト トレランスの要件は、ワーカー プールに割り当てられたリソースの任意の値 X について、

  • X が 2 ～ 20 の場合、ワークロードに使用できるコンピューティング リソースの数は X-1 です。
  • X が 21 ～ 40 の場合、ワークロードに使用できるコンピューティング リソースの数は X-2 です。
  • X が 41 ～ 53 の場合、ワークロードに使用できるコンピューティング リソースの数は X-3 です。

最低限のフットプリントは 2 つのフロント エンド サーバーと 2 つのワーカーです。 上記の文は、わかりやすくするための例です。

  • 1 つのプール内に 30 個のワーカーがある場合、そのうち 28 個をワークロードのホストに使用できます。
  • 1 つのプール内に 2 つのワーカーがある場合、1 つをワークロードのホストに使用できます。
  • 1 つのプール内に 20 個のワーカーがある場合、19 個をワークロードのホストに使用できます。
  • 1 つのプール内に 21 個のワーカーがある場合でも、ワークロードのホストに使用できるのは 19 個のみです。

フォールト トレランスの側面は重要ですが、スケールが特定のしきい値を超える場合に注意する必要があります。 20 個のインスタンスから容量を追加するには、22 個以上に増やします。これは、21 個では容量が追加されないためです。 同様に、40 個を超える数に増やす場合、容量が追加される次の数は 42 です。

App Service Environment の削除

App Service Environment を削除する必要がある場合は、単に [App Service Environment] ブレード上部の [削除] アクションを使用します。 この操作を実行すると、App Service Environment の名前を入力し、操作の実行を確定するように求められます。 App Service Environment を削除すると、その内部のすべてのコンテンツも削除されるので注意してください。

Delete an App Service Environment UI

作業の開始

App Service Environment の使用を開始するには、テンプレートから ASEv1 を作成する方法に関するページを参照してください。

Note

Azure アカウントにサインアップする前に Azure App Service の使用を開始したい場合は、「Azure App Service アプリケーションの作成」を参照してください。そこでは、App Service で有効期間の短いスターター Web アプリをすぐに作成できます。 このサービスの利用にあたり、クレジット カードは必要ありません。契約も必要ありません。