App Service 環境の使用

  • [アーティクル]

App Service Environment は、Azure App Service のシングルテナント デプロイです。 Azure 仮想ネットワークで使用し、このシステムの唯一のユーザーになります。 デプロイされたアプリは、サブネットに適用されているネットワーク機能を必要とします。 これらのネットワーク機能の管理下とするために、アプリで有効にする必要がある追加の機能はありません。

Note

この記事では、Isolated v2 App Service プランで使用される App Service Environment v3 について説明します。

アプリを作成する

App Service Environment でアプリを作成する方法は通常のアプリの作成方法とほとんど同じですが、いくつか違いがあります。 新しい App Service プランを作成する場合は、次の点が異なります。

  • アプリのデプロイ先の場所として地理的な場所ではなく App Service Environment を選択します。
  • App Service Environment で作成する App Service プランはすべて、Isolated v2 の価格レベルでのみ使用できます。

まだない場合は、App Service Environment を作成します。

App Service Environment でアプリを作成するには

  1. [リソースの作成]>[Web + モバイル]>[Web アプリ] を選択します。
  2. サブスクリプションを選択します。
  3. 新しいリソース グループの名前を指定するか、[既存のものを使用] を選択して、ボックスの一覧からいずれかを選択します。
  4. アプリの名前を入力します。 App Service Environment 内で既に App Service プランが選択されている場合、アプリのドメイン名に App Service Environment のドメイン名が反映されます。
  5. [発行]、[ランタイム スタック]、[オペレーティング システム] で、必要に応じて選択します。
  6. [リージョン] では、既存の App Service Environment v3 を選択します。 新しい App Service Environment を作成する場合は、リージョンを選択します。 Screenshot that shows how to create an app in an App Service Environment.
  7. 既存の App Service プランを選択するか、新しいプランを作成します。 新しいプランを作成する場合は、App Service プラン用のサイズを選択します。 アプリ用に選択できる SKU は、Isolated v2 価格 SKU のみです。 通常、新しい App Service プランの作成に要する時間は 20 分未満です。 Screenshot that shows pricing tiers and their features and hardware.
  8. 新しい App Service プランを作成することの一環として新しい App Service Environment を作成することを選択した場合は、名前と仮想 IP の種類を入力します。
  9. [Next:監視] を選択します。 お使いのアプリで Application Insights を有効にする場合は、作成フロー中のここで、それを行うことができます。
  10. [次へ: タグ] を選択しま、アプリに必要なすべのタグを追加します
  11. [Review + create](レビュー + 作成) を選択します。 情報が正しいことを確認し、[作成] を選択します。

Windows アプリと Linux アプリを同じ App Service Environment に追加することはできますが、同じ App Service プランに追加することはできません。

スケールのしくみ

すべての App Service アプリは、App Service プランで実行されます。 App Service Environment に App Service プランが存在し、App Service プランにアプリが存在します。 アプリをスケールするときは、App Service プラン、および同じプラン内のすべてのアプリをスケールすることになります。

App Service プランをスケールすると、必要なインフラストラクチャが自動的に追加されます。 インフラストラクチャが追加されるまでの間、スケール操作に時間差が生じることに注意してください。 たとえば、App Service プランをスケーリングするときに、同じオペレーティング システムとサイズの別のスケール操作が実行されている場合、要求されたスケールが開始されるまで数分の遅延が発生することがあります。

あるサイズとオペレーティング システムに対するスケール操作は、サイズとオペレーティング システムの他の組み合わせのスケーリングには影響しません。 たとえば、Windows I2v2 App Service プランをスケーリングする場合、Windows I3v2 App Service プランのスケーリング操作がすぐに開始されます。 通常、スケーリングにかかる時間は 15 分未満です。

マルチテナントの App Service では、共有リソースのプールですぐに対応できるため、スケーリングが即座に実行されます。 App Service Environment はシングルテナント サービスであるため、共有バッファーはありません。リソースは必要に応じて割り当てられます。

アプリのアクセス

内部仮想 IP (VIP) を使用する App Service Environment では、アプリの作成に使用されるドメイン サフィックスは、.<asename>.appserviceenvironment.net です。 実際の App Service Environment の名前が my-ase で、contoso という名前のアプリをホストする場合、以下の URL でそこにアクセスします。

  • contoso.my-ase.appserviceenvironment.net
  • contoso.scm.my-ase.appserviceenvironment.net

内部 VIP を使用する App Service Environmentでホストされているアプリにアクセスできるのは、同じ仮想ネットワーク内にいるか、その仮想ネットワークに接続されている場合のみです。 同様に、発行は、同じ仮想ネットワーク内にいるか、その仮想ネットワークに接続されている場合にのみ可能です。

外部 VIP を使用する App Service Environment では、アプリの作成に使用されるサフィックスは、.<asename>.p.azurewebsites.net です。 実際の App Service Environment の名前が my-ase で、contoso という名前のアプリをホストする場合、以下の URL でそこにアクセスします。

  • contoso.my-ase.p.azurewebsites.net
  • contoso.scm.my-ase.p.azurewebsites.net

scm URL は、Kudu コンソールにアクセスしたり、Web デプロイを使用してアプリを発行したりするために使用します。 詳しくは、Azure App Service の Kudu コンソールに関するビデオをご覧ください。 Kudu コンソールを使用すると、デバッグやファイルのアップロード、ファイルの編集の作業を Web UI で行うことができます。

DNS の構成

App Service Environment が外部 VIP を使用して作成されている場合、アプリは自動的にパブリック DNS に入れられます。 App Service Environment が内部 VIP を使用して作成されている場合、その DNS 構成が必要になる場合があります。

Azure DNS プライベート ゾーンが自動的に構成されるようにすることを選択した場合は、App Service Environment の仮想ネットワーク内に DNS が構成されます。 DNS を手動で構成するように選択した場合、独自の DNS サーバーを使用するか、Azure DNS プライベート ゾーンを構成する必要があります。

受信アドレスを見つけるには、App Service Environment ポータルで、[IP アドレス] を選択します。

Screenshot that shows how to find the inbound address.

独自の DNS サーバーを使用する場合は、以下のレコードを追加します。

  1. <App Service Environment-name>.appserviceenvironment.net のゾーンを作成します。
  2. そのゾーン内で、* に App Service Environment で使用される受信 IP アドレスを指し示す A レコードを作成します。
  3. そのゾーン内で、@ に App Service Environment で使用される受信 IP アドレスを指し示す A レコードを作成します。
  4. scm という名前のゾーンを <App Service Environment-name>.appserviceenvironment.net に作成します。
  5. scm ゾーン内で、* に App Service Environment で使用される受信アドレスを指し示す A レコードを作成します。

Azure DNS プライベート ゾーンで DNS を構成するには、次の操作を行ってください。

  1. <App Service Environment-name>.appserviceenvironment.net という名前の Azure DNS プライベート ゾーンを作成します。
  2. そのゾーン内で、* に受信 IP アドレスを指し示す A レコードを作成します。
  3. そのゾーン内で、@ に受信 IP アドレスを指し示す A レコードを作成します。
  4. そのゾーン内で、*.scm に受信 IP アドレスを指し示す A レコードを作成します。

App Service Environment の既定のドメイン サフィックスの DNS 設定では、それらの名前によってのみアクセスできるようにアプリが制限されることはありません。 App Service Environment では、アプリの検証なしでカスタム ドメイン名を設定できます。 その後、contoso.net という名前のゾーンを作成する場合は、作成してから、受信 IP アドレスを指すように設定することができます。 カスタム ドメイン名はアプリ要求に対して機能し、カスタム ドメイン サフィックス証明書に scm 用のワイルドカード SAN が含まれている場合、カスタム ドメイン名は scm サイトでも機能し、*.scm レコードを作成して受信 IP アドレスをポイントできます。

発行

次のいずれかの方法で発行できます。

  • Web デプロイ
  • 継続的インテグレーション (CI)
  • Kudu コンソールでのドラッグ アンド ドロップ。
  • 統合された開発環境 (IDE) (Visual Studio、Eclipse、IntelliJ IDEA など)

内部 VIP App Service Environment の使用時に、発行エンドポイントは受信アドレスを介してのみ使用できます。 受信アドレスへのネットワーク アクセスがない場合、その App Service Environment ではアプリの発行は行えません。 IDE に直接発行する場合、IDE にも App Service Environment 上の受信アドレスに対するネットワーク アクセスが必要です。

追加の変更がない場合、GitHub や Azure DevOpsのようなインターネット ベースの CI システムは、内部 VIP App Service Environment では使用できません。 発行エンドポイントはインターネットにアクセスできません。 仮想ネットワークでセルフホステッド リリース エージェントをインストールすることで、Azure DevOps から内部 VIP App Service Environment への発行を有効にすることができます。

ストレージ

App Service Environment 内のすべてのアプリに対して 1 TB のストレージを使用できます。 Isolated 価格 SKU の App Service プランには、250 GB の制限があります。 App Service Environment では、App Service プランごとに 250 GB のストレージが追加されます。上限は 1 TB です。 App Service プランは 4 つ以上持つことができますが、ストレージは 1 TB の上限を超えて追加されることはありません。

監視

App Service Environment v3 のプラットフォーム インフラストラクチャは、Microsoft によって監視および管理されており、必要に応じてスケーリングされます。 お客様は、App Service プランと個々のアプリの実行を監視し、適切なアクションを実行するだけで済みます。 App Service Environment にはいくつかのメトリックが表示されますが、これらは古いバージョンでのみ使用されるものであり、このバージョン用に値が省略されることはありません。 App Service Environment の v1 または v2 を使用している場合は、監視とスケーリングに関するガイダンスについて、 このセクションを参照してください。

ログの記録

Azure Monitor と統合して、ログを Azure Storage、Azure Event Hubs、または Azure Monitor に送信できます。 次の表に、ログに記録できる状況とメッセージを示します。

状況 Message
App Service Environment の領域がほとんどなくなっています。 The specified App Service Environment is in a subnet that is almost out of space. (指定した App Service Environment が、領域がほとんどなくなったサブネット内にあります)。 There are {0} remaining addresses. (残りのアドレスは {0} 個です。) Once these addresses are exhausted, the App Service Environment will not be able to scale. (これらのアドレスを使い果たすと、App Service Environment はスケーリングできません。)
App Service Environment が合計インスタンスの上限に近づいています。 The specified App Service Environment is approaching the total instance limit of the App Service Environment. (指定した App Service Environment が、App Service Environment の合計インスタンスの上限に近づいています。) 現在、最大インスタンス数 200 のうち、{0} 個の App Service プラン インスタンスが含まれています。
App Service Environment は停止されています。 The specified App Service Environment is suspended. (指定した App Service Environment は停止されています。) The App Service Environment suspension may be due to an account shortfall or an invalid virtual network configuration. (App Service Environment の中断は、アカウントの不足または無効な仮想ネットワーク構成が原因である可能性があります。) Resolve the root cause and resume the App Service Environment to continue serving traffic (根本原因を解決し、App Service Environment を再開してトラフィックの処理を続行してください)
App Service Environment のアップグレードが開始されました。 A platform upgrade to the specified App Service Environment has begun. (指定された App Service Environment へのプラットフォームのアップグレードが開始されました) Expect delays in scaling operations (スケーリング操作で遅延が発生することが予想されます)
App Service Environment のアップグレードが完了しました。 A platform upgrade to the specified App Service Environment has finished. (指定された App Service Environment へのプラットフォームのアップグレードが完了しました)
App Service プランの作成が開始されました App Service プラン ({0}) の作成が開始されました。 望ましい状態: {1} I{2}v2 ワーカー。
Scale operations have completed (スケール操作が完了しました) App Service プラン ({0}) の作成が完了しました。 現在の状態: {1} I{2}v2 ワーカー。
Scale operations have failed (スケール操作が失敗しました) App Service プラン ({0}) の作成が失敗しました。 これは、App Service Environment がインスタンスのピーク数で動作しているか、サブネットアドレスが不足していることが原因である可能性があります。
Scale operations have started (スケール操作が開始されました) An App Service plan ({0}) has begun scaling. (App Service プラン ({0}) でスケーリングが開始されました。) 現在の状態: {1} I(2)v2。 望ましい状態: {3} I{4}v2 ワーカー。
Scale operations have completed (スケール操作が完了しました) An App Service plan ({0}) has finished scaling. (App Service プラン ({0}) でスケーリングが完了しました。) 現在の状態: {1} I{2}v2 ワーカー。
スケール操作が中断されました スケーリング中に App Service プラン ({0}) が中断されました。 以前の望ましい状態: {1} I{2}v2 ワーカー。 新しい望ましい状態: {3} I{4}v2 ワーカー。
Scale operations have failed (スケール操作が失敗しました) An App Service plan ({0}) has failed to scale. (App Service プラン ({0}) でスケーリングに失敗しました。) 現在の状態: {1} I{2}v2 ワーカー。

ログを有効にするには、次の手順に従います。

  1. ポータルで [診断設定] に移動します。
  2. [診断設定の追加] を選択します。
  3. ログ統合の名前を指定します。
  4. 目的のログの保存先を選択して構成します。
  5. [AppServiceEnvironmentPlatformLogs] を選択します。 Screenshot that shows how to enable logging.

Azure Monitor Logs と統合している場合は、App Service Environment ポータルから [ログ] を選択し、AppServiceEnvironmentPlatformLogs に対するクエリを作成することでログを表示できます。 ログは、ログをトリガーするイベントが App Service Environment にある場合にのみ出力されます。 App Service Environment にそのようなイベントがない場合は、ログ記録はありません。 ログの例をすばやく確認するには、App Service プランを使用してスケーリングを実行します。 その後、AppServiceEnvironmentPlatformLogs に対してクエリを実行し、これらのログを確認できます。

アラートを作成する

ログに対してアラートを作成するには、「Azure Monitor を使用したログ アラートの作成、表示、管理」の手順に従います。 概要:

  1. App Service Environment ポータルで [アラート] ページを開きます。
  2. [新しいアラート ルール] を選択します。
  3. [リソース]で、Azure Monitor ログ ワークスペースを選択します。
  4. クエリを使用するカスタム ログ検索で条件を設定します。 たとえば、次のように設定できます。 AppServiceEnvironmentPlatformLogs | where ResultDescription contains has begun scaling. 適切なしきい値を設定します。
  5. 適宜、アクション グループを追加するか作成します。 アクション グループでは、電子メールや SMS メッセージの送信など、アラートへの応答を定義します
  6. アラートに名前を付けて保存します。

内部の暗号化

App Service Environment システムの内部コンポーネントまたは通信は表示できません。 より高いスループットを実現するために、内部コンポーネント間の暗号化は既定では有効になっていません。 監視またはアクセスの対象としてトラフィックにアクセスすることはできないため、システムの安全性は確保されています。 データ パスを完全に暗号化するコンプライアンス要件がある場合は、これを有効にできます。 次のスクリーンショットのように [構成] を選択します。

Screenshot that shows how to enable internal encryption.

このオプションは、内部ネットワーク トラフィックを暗号化し、ページファイルとワーカー ディスクも暗号化します。 このオプションは、システムのパフォーマンスに影響を与える可能性があります。 変更が完全に反映されるまで、App Service Environment は不安定な状態になります。 存在するインスタンスの数によっては、変更の反映が完了するまで数時間かかる可能性があります。

App Service Environment を使用している間は、このオプションを有効にしないでください。 これを行う必要がある場合は、操作が完了するまでトラフィックをバックアップに転送してください。

アップグレードの優先順位

複数の App Service Environment がある場合は、その一部を他の環境より前にアップグレードする必要があります。 この動作は、App Service Environment ポータルで有効にすることができます。 構成の下に、アップグレードの優先順位を設定するオプションがあります。 指定できる値は、

  • なし: Azure は、特定のバッチなしでアップグレードします。 この値は既定値です。
  • Early (早期): App Service アップグレードの前半でアップグレードされます。
  • Late (遅延): App Service アップグレードの後半でアップグレードされます。
  • 手動: アップグレードを手動でデプロイするための 15 日間の期間 を取得します。

目的の値を選択し、[保存] を選択します。

Screenshot that shows the App Service Environment configuration portal.

この機能は、複数の App Service Environment がある場合に最も役に立ちます。アップグレードをシーケンス処理することでメリットがある場合があります。 たとえば、開発とテストの App Service Environment を早期に設定し、実稼働の App Service Environment を遅延にする場合があります。

App Service Environment を削除します。

次の操作を実行します。

  1. [App Service Environment] ウィンドウの上部にある [削除] を選択します。
  2. 削除することを確認するために App Service Environment の名前を入力します。 App Service Environment を削除すると、その内部のすべてのコンテンツも削除されます。 Screenshot that shows how to delete.
  3. [OK] を選択します。