App Service Environment を使用するエンタープライズ展開

Microsoft Entra ID

Azure Application Gateway

Azure App Service

Azure Firewall

Azure Virtual Network

Azure Private Link

この参照アーキテクチャは、Azure App Service Environment バージョン 3 を使用する一般的なエンタープライズワークロードを示しています。また、ワークロードのセキュリティを強化するためのベストプラクティスについても説明します。

注

App Service Environment バージョン 3 は、このアーキテクチャの主要なコンポーネントです。バージョン 1 と 2 は、 2024 年 8 月 31 日に廃止されました。

Architecture

このアーキテクチャの Visio ファイルをダウンロードします。

このアーキテクチャの参照実装は、GitHub で入手できます。

Workflow

App Service Environment は、次の 2 つの方法でデプロイできます。

パブリック IP アドレスを持つ外部 App Service Environment として
内部ロードバランサー (ILB) に属する内部 IP アドレスを持つ内部 App Service Environment として

この参照アーキテクチャでは、 ILB App Service Environment とも呼ばれる内部 App Service Environment にエンタープライズ Web アプリケーションをデプロイします。次の機能を必要とするシナリオでは、ILB App Service Environment を使用します。

セキュリティが強化されたイントラネットアプリケーションをクラウドでホストし、サイト間 VPN または Azure ExpressRoute を使用してアクセスします。
Web アプリケーションファイアウォール (WAF) を使用して、アプリの保護レイヤーを提供します。
パブリックドメインネームシステム (DNS) サーバーに一覧にないアプリをクラウドでホストします。
フロントエンドアプリを高度にセキュリティで保護された方法で統合できる、インターネットから分離されたバックエンドアプリを作成します。

App Service Environment は、エンタープライズ仮想ネットワーク内の独自のサブネットに常にデプロイします。この方法では、着信トラフィックと送信トラフィックを厳密に制御できます。このサブネット内では、Azure App Service アプリケーションは、アプリを実行するために必要な物理リソースのコレクションである 1 つ以上の App Service プランで実行されます。複雑さとリソースの要件に応じて、複数のアプリで App Service プランを共有できます。 App Service Environment インフラストラクチャは、ストレージ、コンピューティング、スケーリングなど、これらのホストされているアプリに必要なすべてのリソースを管理します。

このリファレンス実装では、プライベート API および関数と相互に作用する Voting App という名前の Web アプリをデプロイします。また、テスト アプリという名前 のモック Web アプリをデプロイして、複数アプリのデプロイを示します。参照実装では、各 App Service アプリは独自の App Service プランで実行されます。これにより、必要に応じて独立したスケーリングが可能になります。

この実装の単純な投票アプリを使用すると、ユーザーは既存のエントリを表示したり、新しいエントリを作成したり、既存のエントリに投票したりできます。 Web API は、エントリと投票を作成して取得します。データは Azure SQL データベースに格納されます。非同期データ更新を実施するために、Web アプリは、Service Bus インスタンス内に新たに追加された票を待ち行列に入れます。この関数は、待ち行列に入った票を選び、SQL データベースを更新します。 Azure Cosmos DB には、Web アプリがブラウザーに表示するために取得するモックアップ広告が格納されます。アプリケーションは、キャッシュ管理に Azure Managed Redis を使用します。 Azure Managed Redis の分散最適化レベルは、App Service Environment と同じ仮想ネットワークに構成され、独自のサブネットで実行されます。このセットアップにより、キャッシュのセキュリティと分離が強化されます。

Web アプリは、インターネットから到達できる唯一のコンポーネントです。インターネットトラフィックは、WAF によって保護されている Azure Application Gateway を通過する必要があります。インターネットクライアントは、API または関数アプリにアクセスできません。

Components

Azure Virtual Network は、企業が所有するプライベート Azure クラウドネットワークです。強化されたネットワークベースのセキュリティと分離を提供します。このアーキテクチャでは、App Service Environment をエンタープライズ所有の仮想ネットワークのサブネットにデプロイします。 App Service Environment を使用すると、企業はネットワークセキュリティグループ (NSG) とプライベートエンドポイントを使用して、そのネットワーク領域とアクセスするリソースを厳密に制御できます。
Application Gateway は、トランスポート層セキュリティ (TLS) または Secure Sockets Layer (SSL) オフロードと WAF を備えるアプリケーションレベルの Web トラフィックロードバランサーです。このアーキテクチャでは、Application Gateway はパブリック IP アドレスで受信トラフィックを受け入れ、ILB App Service Environment のアプリケーションエンドポイントにルーティングします。このアプリケーションレベルのルーティングでは、同じ ILB App Service 環境内の複数のアプリにトラフィックをルーティングできます。詳細については、「 Application Gateway マルチサイトホスティング」を参照してください。
Azure Firewall は、Azure に組み込まれているクラウドネイティブのステートフルファイアウォールサービスです。高可用性と無制限のクラウドスケーラビリティを提供し、受信と送信の両方のフィルター規則をサポートします。このアーキテクチャでは、Azure Firewall によって Web アプリケーションからの送信トラフィックが制限されます。ルートテーブルは、プライベートエンドポイントチャネルを通過しない送信トラフィックをファイアウォールにルーティングするように構成されています。わかりやすくするために、このアーキテクチャでは、サービスサブネット上のすべてのプライベートエンドポイントを構成します。
Microsoft Entra ID は、Azure のリソースとサービスに対するアクセス権とアクセス許可の管理を提供する ID およびネットワークアクセス製品です。マネージド ID は、サービスとアプリに ID を割り当てます。 Microsoft Entra 認証をサポートする任意のサービスに対して認証を行うことができます。この方法では、これらのアプリの資格情報を明示的に構成する必要がなくなります。このアーキテクチャでは、Web アプリにマネージド ID を割り当てます。
Azure Key Vault は、シークレット、暗号化キー、証明書などの機密情報を安全に格納および管理するクラウドサービスです。このアーキテクチャでは、Key Vault を使用して、アプリに必要なシークレットと資格情報を格納します。アプリケーションにシークレットを直接格納する代わりに、このオプションを使用します。
GitHub Actions は、継続的インテグレーションと継続的デリバリー (CI/CD) を可能にする GitHub に組み込まれているワークフロー自動化機能です。このアーキテクチャでは、App Service Environment は仮想ネットワーク内にあります。そのため、VM は、App Service プランにアプリをデプロイするための仮想ネットワーク内のジャンプボックスとして機能します。このアクションにより、仮想ネットワークの外部にアプリがビルドされます。強化されたセキュリティとシームレスなリモートデスクトッププロトコル (RDP) と Secure Shell (SSH) 接続については、ジャンプボックスに Azure Bastion を使用することを検討してください。

マルチサイト構成

内部 App Service Environment では、HTTP エンドポイントを持つ複数の Web アプリと API をホストできます。 ILB IP アドレスには仮想ネットワーク内からのみアクセスできるため、これらのアプリケーションはパブリックインターネットに公開されません。 Application Gateway は、これらのアプリケーションをインターネットに選択的に公開します。 App Service Environment は、各 App Service アプリケーションに既定の URL を <default-appName>.<app-service-environment-domain>.appserviceenvironment.netとして割り当てます。 App Service Environment ドメイン名を App Service Environment ILB IP アドレスにマップするプライベート DNS ゾーンが作成されます。この方法では、仮想ネットワーク内のアプリアクセス用のカスタム DNS が回避されます。

Application Gateway は、ゲートウェイの IP アドレスで HTTP 要求を受け入れるリスナーを含むように構成されています。わかりやすくするために、この実装ではパブリック DNS 名の登録は使用されません。任意に選択した URL を Application Gateway の IP アドレスにポイントするように、コンピューター上の localhost ファイルを変更する必要があります。リスナーは自己署名証明書を使用してこれらの要求を処理します。

Application Gateway には、App Service アプリケーションの既定の URL ごとにバックエンドプールがあります。ルーティング規則は、リスナーをバックエンドプールに接続するように構成されます。

HTTP 設定は、ゲートウェイと App Service Environment の間の接続で暗号化を使用するかどうかを決定します。これらの設定により、受信 HTTP ホストヘッダーがバックエンドプールのホスト名でオーバーライドされます。この実装では、既定の App Service Environment アプリ URL 用に作成された既定の証明書が使用され、ゲートウェイはこれらの証明書を信頼します。要求は、対応するアプリの既定の URL にリダイレクトされます。

仮想ネットワークにリンクされているプライベート DNS は、この要求を ILB IP アドレスに転送します。その後、App Service Environment によって、要求されたアプリサービスに要求が転送されます。 App Service Environment アプリ内のすべての HTTP 通信は、プライベート DNS を経由します。 App Service Environment アプリごとに、アプリケーションゲートウェイでリスナー、バックエンドプール、ルーティング規則、および HTTP 設定を構成する必要があります。

appgw.bicep ファイルと dns.bicep ファイルを確認して、これらの構成で複数のサイトを許可する方法を確認します。 testapp という名前の Web アプリは、この構成を実施するために作成された空のアプリケーションです。

シナリオの詳細

App Service は、Web アプリ、API アプリ、関数、モバイルアプリなど、Azure 上のさまざまなアプリをホストするサービスとしてのプラットフォーム (PaaS) ソリューションです。 App Service Environment を使用して、独自の Azure 仮想ネットワーク内のサブネットに App Service アプリをデプロイできます。このアプローチでは、クラウドワークロード用に分離され、高度にスケーラブルで専用の環境が提供されます。

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。詳細については、「 Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。詳細については、「セキュリティの設計レビューチェックリスト」を参照してください。

App Service Environment

内部 App Service Environment はエンタープライズ仮想ネットワークに存在し、パブリックインターネットには表示されません。これにより、Web API や機能などのバックエンドサービスをネットワークレベルでセキュリティで保護できます。 HTTP エンドポイントを持つ App Service Environment アプリには、仮想ネットワーク内から ILB 経由でアクセスできます。 Application Gateway は、ILB を介して Web アプリに要求を転送します。 Web アプリケーション自体は、ILB を通じて API にアクセスします。 API や関数などの重要なバックエンドコンポーネントには、パブリックインターネットからアクセスできません。

App Service Environment は、各アプリサービスに既定のドメイン名を割り当て、各ドメイン名の既定の証明書を自動的に作成します。この証明書は、ゲートウェイとアプリの間のトラフィックをセキュリティで保護するのに役立ち、一部のシナリオで必要になる場合があります。既定の証明書はクライアントブラウザーには表示されません。Application Gateway で構成された証明書にのみ応答します。

Application Gateway

Application Gateway では、 TLS または SSL を使用して、Web ブラウザーからすべてのトラフィックを暗号化および保護できます。暗号化は、次の 2 つの方法で構成できます。

ゲートウェイで終了した暗号化: この方法では、バックエンドプールが HTTP 用に構成されます。暗号化はゲートウェイで停止し、ゲートウェイと App Service の間のトラフィックは暗号化されません。暗号化は CPU を集中的に使用するため、バックエンドの暗号化されていないトラフィックによってパフォーマンスが向上し、証明書の管理が簡単になります。この方法では、ネットワーク構成によってバックエンドが保護されるため、中程度のセキュリティが提供されます。
エンドツーエンドの暗号化: 特定のセキュリティまたはコンプライアンス要件があるシナリオによっては、ゲートウェイとアプリの間でトラフィックを暗号化する必要がある場合があります。この構成では HTTPS 接続が使用され、バックエンドプールの証明書が必要です。

このリファレンス実装では、Application Gateway に自己署名入り証明書を使用します。運用コードの場合は、証明機関 (CA) によって発行された証明書を使用します。

サポートされている証明書の種類の一覧の場合、「TLS 終了でサポートされる証明書」を参照してください。
ゲートウェイで終了する暗号化を作成する方法については、「 Azure portal を使用して TLS 終了を使用してアプリケーションゲートウェイを構成する」を参照してください。

appgw.bicepの次の例では、プログラムによって HTTP リスナーを構成します。

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

参照実装では、Application Gateway と App Service Environment 内の Web アプリの間のトラフィックに対するエンドツーエンドの暗号化を示します。既定の SSL 証明書を使用します。この実装のバックエンドプールは、HTTPS トラフィックをリダイレクトするように構成されています。また、ホスト名は、Web アプリに関連付けられている既定のドメイン名でオーバーライドされます。 Application Gateway は既定の SSL 証明書を信頼します。これは、Microsoft が SSL 証明書を発行するためです。詳細については、「 Application Gateway を使用して App Service を構成する」を参照してください。 appgw.bicepの次の例は、参照実装でこのアプローチがどのように構成されるかを示しています。

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Web Application Firewall

Application Gateway 上の Web アプリケーションファイアウォールは、SQL インジェクションなどの悪意のある攻撃から Web アプリを保護します。また、Azure Monitor と統合して、リアルタイムログを使用して攻撃を監視します。 Web アプリケーションファイアウォールを有効にするには、その要件を満たすようにゲートウェイを構成する必要があります。参照実装では、次のコードを使用して、 appgw.bicep ファイル内の WAF をプログラムで有効にします。

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

Virtual Network

NSG は、仮想ネットワーク内の 1 つ以上のサブネットに関連付けることができます。これらのグループは、さまざまな Azure リソース間のトラフィックフローを許可または拒否するセキュリティ規則を定義します。このアーキテクチャでは、サブネットごとに個別の NSG が関連付けられます。これにより、そのサブネット内のサービスに基づいて規則を微調整できます。

App Service Environment サブネットの NSG の構成は、 ase.bicep ファイルにあります。
Application Gateway サブネットの NSG の構成は、 appgw.bicep ファイルにあります。

どちらの構成でも、リソース "type": "Microsoft.Network/networkSecurityGroups"が使用されます。

プライベートエンドポイントを使用することで、プライベートネットワーク経由でクライアントと Azure サービスの間でセキュリティが強化された接続が可能になります。 Azure サービスのプライベートアクセス IP アドレスが提供されます。これにより、Azure Private Link リソースへのセキュリティが強化されたトラフィックが可能になります。プラットフォームはネットワーク接続を検証し、指定された Private Link リソースを対象とする接続のみを許可します。

プライベートエンドポイントは、NSG、ユーザー定義ルート (UDR)、アプリケーションセキュリティグループなどのネットワークポリシーをサポートします。セキュリティを強化するには、それらをサポートするすべての Azure サービスのプライベートエンドポイントを有効にします。仮想ネットワーク内のサービスをセキュリティで保護するには、パブリックアクセスを無効にして、パブリックインターネットからのアクセスをブロックします。このアーキテクチャでは、Service Bus、SQL Database、Key Vault、Azure Cosmos DB など、それをサポートするサービスのプライベートエンドポイントを構成します。構成は、privatendpoints.bicep で確認できます。

プライベートエンドポイントを有効にするには、プライベート DNS ゾーンも構成する必要があります。詳細については、 Azure プライベートエンドポイントの DNS 構成に関するページを参照してください。

Azure Firewall

Azure Firewall とプライベートエンドポイントは相互に補完します。プライベートエンドポイントは、仮想ネットワークから送信されたトラフィックのみを許可することで、リソースを保護するのに役立ちます。 Azure Firewall を使用すると、アプリケーションからの送信トラフィックを制限できます。プライベートエンドポイントのトラフィックを含め、すべての送信トラフィックが、ファイアウォールサブネットを通過するようにすることをお勧めします。この方法により、送信トラフィックをより適切に監視できます。わかりやすくするために、この参照アーキテクチャでは、ファイアウォールサブネットではなく、サービスサブネット上のすべてのプライベートエンドポイントが構成されます。

詳細については、「 App Service Environment ネットワークを使用してファイアウォールを構成する」を参照してください。ファイアウォールは、プライベートエンドポイントと仮想ネットワークルートテーブルを通過しないトラフィックを監視および制御します。

Microsoft Entra ID

Microsoft Entra ID には、アプリケーションを認証し、リソースへのアクセスを承認するためのセキュリティ機能が用意されています。この参照アーキテクチャでは、Microsoft Entra ID、マネージド ID、Azure ロールベースのアクセス制御 (Azure RBAC) の 2 つの主要な機能を使用します。

クラウドアプリケーションでは、クラウドサービスに対する認証に必要な資格情報をセキュリティで保護する必要があります。理想的には、資格情報が開発者ワークステーションやソース管理に表示されないようにする必要があります。 Key Vault は資格情報とシークレットを安全に格納しますが、取得するにはアプリで Key Vault に対して認証を行う必要があります。 Azure リソースのマネージド ID は、 Microsoft Entra ID で自動的に管理される ID を Azure サービスに提供します。この ID を使用すると、アプリケーション内の資格情報なしで、Key Vault を含む Microsoft Entra 認証をサポートするすべてのサービスに対して認証を行うことができます。

Azure RBAC では、次の条件を定義することで、Azure リソースへのアクセスを管理します。

ユーザー、マネージド ID、セキュリティプリンシパルなどのアクセス権を持つエンティティ
所有者、共同作成者、閲覧者、管理者など、アクセス権の種類
リソース、リソースグループ、サブスクリプション、管理グループなどのアクセスのスコープ

App Service Environment アプリケーションへのアクセスをセキュリティで保護するには、必要なロールと各アプリのアクセスの種類を厳密に制御します。この方法では、複数のアプリを異なる開発チームから同じ App Service Environment にデプロイできます。たとえば、1 つのチームがフロントエンドを処理し、1 つのチームがバックエンドを処理する場合があります。 Azure RBAC では、各チームが作業するアプリへのアクセスを制限できます。組織に適したロールを作成するには、 Azure カスタムロールに関するページを参照してください。

Key Vault

一部のサービスはマネージド ID をサポートし、Azure RBAC を使用してアプリのアクセス許可を設定します。たとえば、Azure Cosmos DB の組み込みの Service Bus ロールと Azure RBAC を参照してください。これらのアクセス許可を付与するには、サブスクリプションへの ユーザーアクセス管理者 アクセス権が必要です。 共同作成者ロールは、これらのサービスをデプロイできます。より広範な開発者チームがデプロイスクリプトを実行できるようにするには、各サービスが提供するネイティブアクセス制御を使用できます。

Service Bus の場合は、 Shared Access Signature を使用します。
Azure Cosmos DB の場合は、キーを使用します。

ワークロードにサービスベースのアクセスが必要な場合は、事前共有シークレットを Key Vault に格納します。 Web アプリケーションのマネージド ID を使用してコンテナーにアクセスします。

アプリは、Key Vault に格納されているシークレットにアクセスします。 Key Vault のキーと値のペアを参照します。 sites.bicep ファイルによって構成が定義されます。投票アプリでは、次のコードを使用します。

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。詳細については、「コスト最適化の設計レビューチェックリスト」を参照してください。

Azure 料金計算ツールを使用してコストを見積もります。詳細については、 Well-Architected フレームワークのコスト最適化の柱を参照してください。コストを節約するために、 Azure の予約では、多くの Azure リソースに対して 1 年間または 3 年間のプランが提供されます。

このアーキテクチャの一部の主要なサービスについては、次のコスト要因を考慮してください。

App Service Environment v3

App Service には、さまざまな価格オプションがあります。 App Service Environment は、Isolated v2 サービスプランを使用してデプロイされます。このプランには、I1v2 から I6v2 までの CPU サイズに関する複数のオプションが含まれています。この参照実装では、3 つの I1v2 インスタンスを使用します。

Application Gateway

Application Gateway には、さまざまな価格オプションがあります。この実装では、自動スケーリングとゾーン冗長性をサポートする Application Gateway Standard v2 と Web Application Firewall v2 SKU を使用します。詳細については、「 Application Gateway v2 と Web Application Firewall v2 のスケーリング」を参照してください。

Azure マネージド再配布

Azure Managed Redis には、さまざまな価格オプションがあります。

その他の依存関係

App Service Environment のセキュリティ保護に役立つその他のサービスには、いくつかの価格オプションもあります。

オペレーショナルエクセレンス

オペレーショナルエクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。詳細については、「オペレーショナルエクセレンスのデザインレビューチェック一覧」を参照してください。

この参照アーキテクチャのデプロイスクリプトは、App Service Environment、他のサービス、および App Service Environment 内のアプリケーションをデプロイします。これらのアプリケーションをデプロイした後、企業はアプリのメンテナンスとアップグレードのために CI/CD を計画する場合があります。このセクションでは、開発者が App Service Environment アプリケーションの CI/CD に使用する一般的な方法について説明します。

アプリは、仮想ネットワーク内からのみ内部 App Service Environment にデプロイできます。 App Service Environment アプリをデプロイするには、次のいずれかの方法を使用します。

仮想ネットワーク内の VM を使用します。 デプロイに必要なツールを使用して、App Service Environment 仮想ネットワーク内に VM を作成します。 VM への RDP 接続を開くには、NSG 構成を使用します。コード成果物を VM にコピーしてビルドし、App Service Environment サブネットにデプロイします。この方法は、初期ビルドとテスト開発環境を設定するのに適切に機能します。運用環境では、必要なデプロイスループットに合わせてスケーリングできないため、この方法を使用しないでください。
ローカルワークステーションからポイント対サイト VPN 接続を使用します。 App Service Environment 仮想ネットワークを開発マシンに拡張します。ローカルワークステーションからデプロイします。この方法は、初期開発環境にも適していますが、運用環境には適していません。
Azure Pipelines を使用します。 仮想ネットワーク内にあるエージェントで終わる完全な CI/CD パイプラインを実装します。この方法は、高スループットのデプロイを必要とする運用環境に適しています。ビルドパイプラインは完全に仮想ネットワークの外部に留まります。デプロイパイプラインは、構築されたオブジェクトを仮想ネットワーク内のビルドエージェントにコピーし、App Service Environment サブネットにデプロイします。詳細については、「セルフホステッド Windows エージェント」を参照してください。

運用環境には、Azure Pipelines または別の CI/CD ツールを使用することをお勧めします。 voting-data-app.yml ファイルは、この参照実装で Web アプリの CI/CD パイプラインを実装します。同様の CI/CD スクリプトでは、 Web API がサポートされています。

一部の企業では、仮想ネットワーク内で永続的なビルドエージェントを維持したくない場合があります。その場合は、次のいずれかのオプションを検討してください。

ビルドエージェントを動的に作成します。 開発操作 (DevOps) パイプライン内にビルドエージェントを作成し、デプロイの完了後に破棄します。この方法では、DevOps にもう 1 つの手順が追加されますが、VM のメンテナンスは簡略化されます。
コンテナーを使用します。 VM の代わりにビルドエージェントとしてコンテナーを使用します。
エージェントなしでデプロイします。 仮想ネットワークの外部 (通常はストレージアカウント内) に配置された zip 形式のファイルからデプロイすることで、ビルドエージェントを完全に回避します。 App Service Environment とパイプラインには、ストレージアカウントへのアクセス権が必要です。リリースパイプラインの末尾で、zip 形式のファイルを BLOB ストレージにドロップできます。その後、Azure App Service Environment で選択してデプロイできます。

この方法には、次の制限事項が含まれます。
- この方法では、実際のデプロイプロセスから DevOps が切断されるため、デプロイの問題の監視とトレースが困難になります。
- セキュリティで保護されたトラフィックを使用するロックダウンされた環境では、ストレージ内の zip 形式のファイルのアクセス規則を更新することが必要になる場合があります。
- ZIP ファイルからデプロイするには、App Service Environment に特定の拡張機能とツールをインストールする必要があります。
アプリのデプロイ方法の詳細については、「 App Service でアプリを実行する」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。詳細については、「パフォーマンス効率の設計レビューチェックリスト」を参照してください。

スケーラブルなアプリケーションを設計する

この参照アーキテクチャは、使用状況に基づいて個々のコンポーネントをスケーリングできるように、アプリケーションを構成します。各 Web アプリ、API、関数は、独自の App Service プランでデプロイされます。各アプリでパフォーマンスのボトルネックを監視し、必要に応じてスケールアップすることができます。

Application Gateway を自動的にスケーリングする

Application Gateway では、自動スケールがサポートされています。この機能により、Application Gateway はトラフィックの負荷パターンに基づいてスケールアップまたはスケールダウンできます。参照アーキテクチャでは、autoscaleConfiguration ファイル内のを、0 から 10 個の追加インスタンスの間でスケーリングするように構成します。詳細については、「 Application Gateway と Web アプリケーションファイアウォールのスケーリング」を参照してください。

このシナリオのデプロイ

このアーキテクチャのリファレンス実装をデプロイするには、GitHub の readme を参照し、標準的なデプロイのためのスクリプトに従ってください。

貢献者達

Microsoft では、この記事を保持しています。次の共同作成者がこの記事を書きました。

主要著者:

Dhanashri Kshirsagar | シニアコンテンツ PM

その他の共同作成者:

Deep Bhattacharya | クラウドソリューションアーキテクト
Suhas Rao | クラウドソリューションアーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

App Service Environment を使用する高可用性エンタープライズ展開

フィードバック

このページはお役に立ちましたか?

次の方法で共有

App Service Environment を使用するエンタープライズ 展開

Architecture

Workflow

Components

マルチサイト構成

シナリオの詳細

考慮事項

セキュリティ

App Service Environment

Application Gateway

Web Application Firewall

Virtual Network

Azure Firewall

Microsoft Entra ID

Key Vault

コストの最適化

App Service Environment v3

Application Gateway

Azure マネージド再配布

その他の依存関係

オペレーショナル エクセレンス

パフォーマンス効率

スケーラブルなアプリケーションを設計する

Application Gateway を自動的にスケーリングする

このシナリオのデプロイ

貢献者達

次のステップ

関連リソース

フィードバック

App Service Environment を使用するエンタープライズ展開

オペレーショナルエクセレンス