編集

次の方法で共有

ベースライン高可用性ゾーン冗長 Web アプリケーション

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL データベース
Azure Private Link
Azure Virtual Network
Azure Monitor

このベースライン アーキテクチャは、基本的な Web アプリケーション アーキテクチャに基づいており、その基本的な Web アプリケーション アーキテクチャを拡張して、Azure で安全でゾーン冗長の高可用性 Web アプリケーションを設計するためのガイダンスについて詳しく説明します。 このアーキテクチャでは、Web Application Firewall を使用する Azure Application Gateway 経由でパブリック エンドポイントを公開します。 要求は、Private Link 経由で Azure App Service にルーティングされます。 App Service アプリケーションは、仮想ネットワーク統合と Private Link を使用して、Azure Key Vault や Azure SQL Database などの Azure PaaS サービスと安全に通信します。

重要

GitHub ロゴ このガイダンスは Azure でのベースライン アプリ サービスの実装を紹介する実装例によって裏付けられています。 この実装は、実稼働に向けた最初のステップにおけるさらなるソリューション開発の基礎として使用できます。

アーキテクチャ

ゾーン冗長と高可用性を備えたベースライン App Service アーキテクチャを示す図。

"図 1: ベースライン Azure App Service アーキテクチャ"

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

コンポーネント

このアーキテクチャの多くのコンポーネントは、基本的な Web アプリケーション アーキテクチャと同じです。 次のリストでは、基本的なアーキテクチャに対する変更のみを強調しています。

  • Application Gateway は、レイヤー 7 (HTTP/S) のロード バランサーおよび Web トラフィック マネージャーです。 URL パスベースのルーティングを使用して、受信トラフィックを可用性ゾーン間で分散し、暗号化をオフロードしてアプリケーションのパフォーマンスを向上させます。
  • Web Application Firewall (WAF) は、SQL インジェクションやクロスサイト スクリプティングなどの一般的な悪用から Web アプリを保護するクラウドネイティブ サービスです。 WAF を使用すると、Web アプリケーションとの間のトラフィックを可視化できるため、アプリケーションを監視してセキュリティで保護できます。
  • Azure Key Vault は、シークレット、暗号化キー、証明書を安全に格納および管理するサービスです。 機密情報の管理を一元化します。
  • Azure 仮想ネットワークは、Azure で分離された安全なプライベート仮想ネットワークを作成できるサービスです。 App Service 上の Web アプリケーションの場合は、リソース間のネットワーク セキュア通信にプライベート エンドポイントを使用するための仮想ネットワーク サブネットが必要です。
  • Private Link を使用すると、クライアントはパブリック IP アドレス指定を使用せずに、プライベート仮想ネットワークから直接 Azure サービスとしてのプラットフォーム (PaaS) サービスにアクセスできます。
  • Azure DNS は、DNS ドメインのホスティング サービスであり、Microsoft Azure インフラストラクチャを使用した名前解決を提供します。 プライベート DNS ゾーンは、サービスの完全修飾ドメイン名 (FQDN) をプライベート エンドポイントの IP アドレスにマップする方法を提供します。

ネットワーク

ネットワーク セキュリティは、App Services ベースライン アーキテクチャの中核です ("図 2 を参照")。 ネットワーク アーキテクチャでは、大まかに次のことが実現されます。

  1. クライアント トラフィックの単一の安全なエントリ ポイント
  2. ネットワーク トラフィックがフィルター処理される
  3. 転送中のデータは TLS を使用してエンドツーエンドで暗号化される
  4. Private Link を使用してトラフィックを Azure 内に維持することで、データ流出を最小限に抑えられる
  5. ネットワーク リソースは論理的にグループ化され、ネットワークのセグメント化によって相互に分離される

ネットワーク フロー

ベースライン App Service ネットワーク アーキテクチャを示す図。

"図 2: ベースライン Azure App Service アプリケーションのネットワーク アーキテクチャ"

以下では、App Service インスタンスへのインターネット トラフィックの受信フローと、App Service から Azure サービスへのフローについて説明します。

受信フロー

  1. ユーザーは、Application Gateway パブリック IP に要求を発行します。
  2. WAF ルールが評価されます。 WAF 規則は、クロスサイト スクリプティング (XSS) や SQL インジェクションなど、さまざまな攻撃への防御となるのでシステムの信頼性にプラスに作用します。 WAF 規則への違反があり、処理が停止した場合は、Azure Application Gateway から要求者にエラーが返されます。 WAF 規則への違反がない場合、Application Gateway はバックエンド プールに要求をルーティングします。この場合は、App Service の既定のドメインです。
  3. プライベート DNS ゾーン privatelink.azurewebsites.net は仮想ネットワークにリンクされます。 DNS ゾーンには、App Service の既定のドメインを App Service プライベート エンドポイントのプライベート IP アドレスにマップする A レコードがあります。 このリンクされたプライベート DNS ゾーンを使用すると、Azure DNS は既定のドメインをプライベート エンドポイントの IP アドレスに解決できます。
  4. 要求は、プライベート エンドポイントを介して App Service インスタンスにルーティングされます。

App Service から Azure PaaS サービスへのフロー

  1. App Service は、必要な Azure サービスの DNS 名に対して要求を行います。 要求の対象は、シークレットを取得する Azure Key Vault、発行 zip ファイルを取得する Azure Storage、Azure SQL Database、または Private Link をサポートするその他の Azure サービスなどにできます。 App Service の仮想ネットワーク統合機能は、仮想ネットワーク経由で要求をルーティングします。
  2. 受信フローの手順 3 と同様に、リンクされたプライベート DNS ゾーンには、Azure サービスのドメインをプライベート エンドポイントのプライベート IP アドレスにマップする A レコードがあります。 ここでも、このリンクされたプライベート DNS ゾーンを使用すると、Azure DNS でドメインをサービスのプライベート エンドポイント IP アドレスに解決できます。
  3. 要求は、プライベート エンドポイントを介してサービスにルーティングされます。

App Services へのイングレス

Application Gateway は、このベースライン アーキテクチャの要件を満たすリージョン リソースです。 Application Gateway は、Web アプリケーション ファイアウォールや TLS オフロードなどの機能をサポートするスケーラブルなリージョン レイヤー 7 ロード バランサーです。 Azure App Services へのイングレスのために Application Gateway を実装する場合は、次の点を考慮してください。

  • Application Gateway をデプロイし、Microsoft マネージド ルールセットを使って WAF ポリシーを構成します。 防止モードを使って、配信元のサービス (このアーキテクチャでは App Service) を使用できなくする恐れのある Web 攻撃を軽減します。
  • エンド ツー エンド TLS 暗号化を実装します。
  • プライベート エンドポイントを使用して、App Service への受信プライベート アクセスを実装します。
  • 動的トラフィック フローに簡単に調整するために、Application Gateway の自動スケーリングを実装することを検討してください。
  • 最小スケール インスタンス数を 3 以上にすることを検討し、リージョンでサポートされているすべての可用性ゾーンを常に使用します。 Application Gateway は高可用性の方法でデプロイされますが、1 つのスケール インスタンスであっても、障害発生時に新しいインスタンスを作成するには最大 7 分かかることがあります。 複数のインスタンスを Availability Zones にデプロイすると、障害が発生したときに、新しいインスタンスの作成中にインスタンスが実行されていることを確認するのに役立ちます。
  • ネットワークの分離を確保するために、App Service でパブリック ネットワーク アクセスを無効にします。 これを行うには、Bicep で properties/siteConfig に publicNetworkAccess: 'Disabled' を設定します。

App Services から Azure サービスへのフロー

このアーキテクチャでは、特に仮想ネットワークを介してプライベート エンドポイントにトラフィックをルーティングするために、App Service の仮想ネットワーク統合が使用されます。 ベースライン アーキテクチャでは、すべての送信トラフィックに対して仮想ネットワークの経由を強制するような "すべてのトラフィックのルーティング" を有効にしているわけではありません。プライベート エンドポイント向けのトラフィックなど、内部トラフィックのみになります。

パブリック インターネットからのアクセスを必要としない Azure サービスでは、プライベート エンドポイントを有効にし、パブリック エンドポイントを無効にする必要があります。 プライベート エンドポイントは、このアーキテクチャ全体で使用されており、パブリック IP アドレス指定を使用せずに、App Service がプライベート仮想ネットワークから直接 Private Link サービスに接続できるようにしてセキュリティを向上させます。

このアーキテクチャでは、Azure SQL Database、Azure Storage、Key Vault ではすべてパブリック エンドポイントが無効になっています。 Azure サービスのファイアウォールは、他の認可された Azure サービスからのトラフィックのみを許可するために使われます。 プライベート エンドポイントを使用して、Azure Cosmos DB や Azure Redis Cache などの他の Azure サービスを構成する必要があります。 このアーキテクチャでは、Azure Monitor でプライベート エンドポイントを使用しませんが、使用することもできます。

ベースライン アーキテクチャでは、サービスごとにプライベート DNS ゾーンが実装されます。 プライベート DNS ゾーンには、サービスの完全修飾ドメイン名とプライベート エンドポイントのプライベート IP アドレスの間をマップする A レコードが含まれています。 ゾーンは仮想ネットワークにリンクされます。 プライベート DNS ゾーン グループを使用すると、プライベート リンク DNS レコードを自動的に作成および更新できます。

仮想ネットワーク統合とプライベート エンドポイントを実装する場合は、次の点を考慮してください。

仮想ネットワークのセグメント化とセキュリティ

このアーキテクチャのネットワークには、Application Gateway、App Service 統合コンポーネント、プライベート エンドポイント用の個別のサブネットがあります。 各サブネットにはネットワーク セキュリティ グループがあり、これらのサブネットの受信と送信の両方のトラフィックを必要なトラフィックのみに制限します。 次の表には、ベースラインによって各サブネットに追加される NSG 規則を簡単に示しています。 表では、規則名と機能を示しています。

Subnet 受信 送信
snet-AppGateway AppGw.In.Allow.ControlPlane: 受信コントロール プレーン アクセスを許可します

AppGw.In.Allow443.Internet: 受信インターネット HTTPS アクセスを許可します		 AppGw.Out.Allow.AppServices: AppServicesSubnet への送信アクセスを許可します

AppGw.Out.Allow.PrivateEndpoints: PrivateEndpointsSubnet への送信アクセスを許可します

AppPlan.Out.Allow.AzureMonitor: Azure Monitor への送信アクセスを許可します
snet-PrivateEndpoints 既定の規則: 仮想ネットワークからの受信を許可します 既定の規則: 仮想ネットワークへの送信を許可します
snet-AppService 既定の規則: vnet からの受信を許可します AppPlan.Out.Allow.PrivateEndpoints: PrivateEndpointsSubnet への送信アクセスを許可します

AppPlan.Out.Allow.AzureMonitor: Azure Monitor への送信アクセスを許可します

仮想ネットワークのセグメント化とセキュリティを実装する場合は、次の点を考慮してください。

  • パブリック IP を持つアプリケーション ゲートウェイに属するサブネットがあるすべての仮想ネットワークで、DDoS 保護を有効にします。
  • 可能であれば、すべてのサブネットに NSG を追加します。 ソリューションの全機能を有効にする最も厳密な規則を使用する必要があります。
  • アプリケーション セキュリティ グループを使用します。 アプリケーション セキュリティ グループを使用すると、NSG をグループ化し、複雑な環境でルールを簡単に作成できます。

仮想サブネット スキーマの例を次に示します。

Type 名前 アドレス範囲
Virtual Network アドレス プレフィックス 10.0.0.0/16
Subnet GatewaySubnet 10.0.1.0/24
Subnet AppServicesSubnet 10.0.0.0/24
Subnet PrivateEndpointsSubnet 10.0.2.0/27
Subnet AgentsSubject 10.0.2.32/27

「Azure-Samples\app-service-baseline-implementation」を参照してください。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

App Services のベースライン アーキテクチャでは、主要なリージョン サービスのゾーン冗長に重点を置いています。 可用性ゾーンは、リージョン内の物理的に分離された場所です。 2 つ以上のインスタンスがサポート リージョンにデプロイされている場合、サポート サービスに対するゾーン冗長が提供されます。 1 つのゾーンでダウンタイムが発生しても、他のゾーンは影響を受けない場合があります。

また、このアーキテクチャにより、需要を満たすのに十分な Azure サービス インスタンスが確保されます。 以降のセクションでは、アーキテクチャの主要なサービスの信頼性に関するガイダンスを提供します。 このように、可用性ゾーンは、高可用性とフォールト トレランスを提供して信頼性を実現するのに役立ちます。

Application Gateway

ゾーン冗長構成で Azure Application Gateway v2 をデプロイします。 障害が発生した場合に Application Gateway インスタンスの 6 分から 7 分の起動時間を回避するために、最小スケール インスタンス数を 3 以上にすることを検討してください。

アプリケーション サービス

  • 可用性ゾーンをサポートする 3 つ以上の App Services インスタンスをデプロイします。
  • アプリに正常性チェック エンドポイントを実装し、App Service Health チェック機能を構成して、要求が異常なインスタンスを迂回するようにします。 App Service Health チェックの詳細については、「正常性チェックを使用して App Service インスタンスを監視する」を参照してください。 ASP.NET アプリケーションで正常性チェック エンドポイントを実装する方法については、「ASP.NET Core の正常性チェック」を参照してください。
  • ゾーンの障害を処理できるようにするために、容量を余分にプロビジョニングします。

SQL Database

  • ゾーン冗長を有効にして Azure SQL DB General Purpose、Premium、または Business Critical をデプロイしてください。 General Purpose、Premium、Business Critical の各レベルで、Azure SQL DB のゾーン冗長がサポートされています。
  • ゾーン冗長ストレージ (ZRS) または geo ゾーン冗長ストレージ (GZRS) を使うように SQL DB のバックアップを構成します。

BLOB ストレージ

  • Azure ゾーン冗長ストレージ (ZRS) を使うと、リージョン内の 3 つの可用性ゾーンに同期的にデータをレプリケートします。 可用性ゾーン間でデータがレプリケートされるように、Standard ZRS または Standard GZRS ストレージ アカウントを作成します。
  • デプロイ、Web アセット、その他のデータ用に別々のストレージ アカウントを作成し、それぞれのアカウントの管理や設定を個別に行えるようにします。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

以降のセクションでは、このアーキテクチャの主要なコンポーネントのスケーラビリティについて説明します。

Application Gateway

App Service

SQL Server

データベース リソースのスケーリングは、このアーキテクチャの範囲外の複雑なトピックです。 データベースをスケーリングするときは、次のリソースを考慮してください。

スケーラビリティに関するその他のガイダンス

  • サブスクリプションの制限とクォータを確認し、必要に応じてサービスがスケーリングされるようにします。
  • パフォーマンスとスケーラビリティを向上させるには、次の種類のデータのキャッシュを検討してください。
    • 半静的なトランザクション データ。
    • セッションの状態。
    • HTML 出力。 複雑な HTML 出力を表示するアプリケーションの場合に役立ちます。

セキュリティ

ベースライン App Service アーキテクチャでは、Web アプリの重要なセキュリティに関する推奨事項に焦点を当てています。 ワークロードをセキュリティで保護するには、すべてのレイヤーで暗号化と ID がどのように機能するかを理解することが重要です。

App Service

  • FTP および SCM サイト デプロイのローカル認証方法を無効にします
  • リモート デバッグをオフにします。
  • 最新の TLS バージョンを使用します。
  • Microsoft Defender for App Service を有効にします。
  • サポート対象プラットフォーム、プログラミング言語、プロトコル、およびフレームワークの最新バージョンを使用します。
  • より高度な分離または安全なネットワーク アクセスが必要な場合は、App Service Environment を検討してください。

暗号化

運用 Web アプリでは、HTTPS を使用して転送中のデータを暗号化する必要があります。 HTTPS プロトコルはトランスポート層セキュリティ (TLS) に依存し、暗号化に公開キーと秘密キーを使用します。 証明書 (X.509) を Key Vault に格納し、Application Gateway による秘密キーの取得を許可する必要があります。 保存データの場合、自動的にデータが暗号化されるサービスもあれば、カスタマイズできるサービスもあります。

転送中のデータ

ベースライン アーキテクチャでは、転送中のデータはユーザーから App Service の Web アプリに暗号化されます。 次のワークフローでは、暗号化の仕組みについて大まかに説明します。

ベースライン App Service の暗号化フローを示す図。

  1. ユーザーは Web アプリに HTTPS 要求を送信します。
  2. HTTPS 要求がアプリケーション ゲートウェイに到達します。
  3. アプリケーション ゲートウェイは、Key Vault の証明書 (X.509) を使用して、ユーザーの Web ブラウザーとの安全な TLS 接続を作成します。 アプリケーション ゲートウェイは HTTPS 要求を復号化して、Web アプリケーション ファイアウォールが HTTPS 要求を検査できるようにします。
  4. アプリケーション ゲートウェイは、App Service を使用して TLS 接続を作成し、ユーザー要求を再暗号化します。 App Service によって HTTPS のネイティブ サポートが提供されるため、App Service に証明書を追加する必要はありません。 アプリケーション ゲートウェイは、暗号化されたトラフィックを App Service に送信します。 App Service はトラフィックを復号化し、Web アプリが要求を処理します。

転送中のデータの暗号化を構成する場合は、次の推奨事項を考慮してください。

  • 証明書を作成するか、Key Vault にアップロードします。 HTTPS 暗号化には証明書 (X.509) が必要です。 カスタム ドメインの信頼された証明機関からの証明書が必要です。
  • Key Vault 内の証明書に秘密キーを格納します。
  • 「Azure RBAC を使用して Azure キー コンテナーへのアクセス許可をアプリケーションに付与する」とAzure リソースのマネージド ID に関する記事のガイダンスに従って、Application Gateway に証明書秘密キーへのアクセスを提供します。 アクセスを提供するために、Key Vault アクセス ポリシーを使用しないでください。 アクセス ポリシーを使用すると、特定の値のみでなく、広範なアクセス許可を付与することしかできません。
  • エンド ツー エンド暗号化を有効にします。 App Service は、アプリケーション ゲートウェイのバックエンド プールです。 バックエンド プールのバックエンド設定を構成するときは、バックエンド ポート 443 経由で HTTPS プロトコルを使用します。
保存データ
  • 透過的なデータ暗号化を使用して、Azure SQL Database 内の機密データを暗号化します。 透過的なデータでは、データベース、バックアップ、トランザクション ログ ファイル全体が暗号化されるため、Web アプリケーションに変更を加える必要はありません。
  • データベース暗号化の待機時間を最小限に抑えます。 暗号化の待機時間を最小限に抑えるには、セキュリティで保護する必要があるデータを独自のデータベースに配置し、そのデータベースに対する暗号化のみを有効にします。
  • 組み込みの暗号化のサポートについて理解します。 Azure Storage では、サーバー側暗号化 (256 ビット AES) を使用して保存データが自動的に暗号化されます。 Azure Monitor では、Microsoft マネージド キー (MMK) を使用して保存データが自動的に暗号化されます。

ID 管理とアクセス管理

App Service ベースラインでは、ユーザー ID (ユーザー) とワークロード ID (Azure リソース) の認証と認可が構成され、最小限の特権の原則が実装されます。

ユーザー ID
  • App Service の統合認証メカニズム ("EasyAuth") を使用します。 EasyAuth を使用すると、ID プロバイダーを Web アプリに統合するプロセスが簡略化されます。 Web アプリの外部で認証が処理されるため、コードを大幅に変更する必要はありません。
  • カスタム ドメインの応答 URL を構成します。 Web アプリを https://<application-gateway-endpoint>/.auth/login/<provider>/callback にリダイレクトする必要があります。 <application-gateway-endpoint> を、アプリケーション ゲートウェイに関連付けられているパブリック IP アドレスまたはカスタム ドメイン名に置き換えます。 <provider> は、使用している認証プロバイダー (Microsoft Entra ID の場合は "aad" など) で置き換えます。 Azure Front のドキュメントを使用して、Application Gateway でこのフローを設定するか、Application Gateway を設定できます。
ワークロード ID
  • ワークロード ID にはマネージド ID を使用します。 マネージド ID を使用すると、開発者は認証資格情報を管理する必要がなくなります。
  • ユーザー割り当てマネージド ID を使用します。 システム割り当て ID を使用すると、競合状態と操作の順序に基づいて、コードとしてのインフラストラクチャのデプロイが失敗する場合があります。 ユーザー割り当てマネージド ID を使用すると、こうしたデプロイ エラー シナリオの一部を回避できます。 詳細については、「マネージド ID」を参照してください。

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

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

ベースライン App Service アプリケーションのデプロイは、Azure Pipelines を使用した Azure Web Apps の CI/CD のガイダンスに従います。 そのガイダンスに加えて、App Services のベースライン アーキテクチャでは、アプリケーションとデプロイのストレージ アカウントがネットワークで保護されていることを考慮します。 このアーキテクチャでは、App Service へのパブリック アクセスが拒否されます。 つまり、仮想ネットワークの外部からデプロイすることはできません。 ベースラインでは、セルフホステッド デプロイ エージェントを使用して仮想ネットワーク内にアプリケーション コードをデプロイする方法を示します。 次のデプロイ ガイダンスでは、アプリケーション コードをデプロイし、インフラストラクチャやデータベースの変更をデプロイしないことに重点を置いています。

ベースライン App Service デプロイ アーキテクチャを示す図。

"図 3: Azure App Service アプリケーションのデプロイ"

デプロイ フロー

  1. リリース パイプラインの一部として、パイプラインはセルフホステッド エージェントに対するジョブ要求をジョブ キューに投稿します。 このジョブ要求は、エージェントがビルド成果物の "発行 zip ファイル" を Azure Storage アカウントにアップロードするためのものです。

  2. セルフホステッド デプロイ エージェントは、ポーリングを通じて新しいジョブ要求を取得します。 ジョブとビルド成果物がダウンロードされます。

  3. セルフホステッド デプロイ エージェントは、ストレージ アカウントのプライベート エンドポイントを介して zip ファイルをストレージ アカウントにアップロードします。

  4. パイプラインが続行され、マネージド エージェントが後続のジョブを取得します。 マネージド エージェントは CLI 呼び出しを行い、appSetting の WEBSITE_RUN_FROM_PACKAGE をステージング スロットの新しい発行 zip ファイルの名前に更新します。

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. Azure App Service は、ストレージ アカウントのプライベート エンドポイントを介して、ストレージから新しい発行 zip ファイルをプルします。 WEBSITE_RUN_FROM_PACKAGE は別のファイル名に設定されているため、ステージング インスタンスは新しいパッケージで再起動されます。

  6. パイプラインは、スモーク テストを再開して実行するか、承認を待ちます。 テストに合格した場合、または承認された場合、パイプラインはステージング スロットと運用スロットを入れ替えます。

展開のガイダンス

次に、ベースライン アーキテクチャの主要なデプロイ ガイダンスのハイライトを示します。

  • [Run From Package] (パッケージから実行) を使用してデプロイの競合を避けます。 Azure App Service のパッケージから直接アプリを実行すると、パッケージ内のファイルは wwwroot ディレクトリにコピーされません。 代わりに、ZIP パッケージ自体が読み取り専用の wwwroot ディレクトリとして直接マウントされます。 これにより、デプロイとランタイムの間のファイル ロックの競合が解消され、完全にデプロイされたアプリのみが常に実行されるようになります
  • デプロイされたパッケージ zip ファイルにバージョン番号を含めます。 WEBSITE_RUN_FROM_PACKAGE appSetting を別のファイル名でデプロイ パッケージに更新すると、App Services によって新しいバージョンが自動的に取得され、サービスが再起動されます。
  • 回復性があるコードのデプロイには、デプロイ スロットを使用します。
  • マネージド エージェントとセルフホステッド エージェントを組み合わせて使用することを検討します。
  • コードとしてのインフラストラクチャ (IaC) を使用してインフラストラクチャのデプロイを自動化します。
  • Azure Load Testing や Azure Chaos Studio などのサービスを使って、ソリューション全体のパフォーマンスと回復性をテストするために、ワークロードを継続的に検証します。

構成

アプリケーションには、構成値とシークレットの両方が必要です。 構成とシークレットの管理には、次のガイダンスを使用します。

  • パスワードやアクセス キーなどのシークレットをソース管理にチェックインしないでください。
  • Azure Key Vault を使用してシークレットを格納します。
  • アプリケーション構成の App Service 構成を使用します。 アプリケーション構成から構成を外部化する必要がある場合、または機能フラグのサポートが必要な場合は、Azure App Configuration の使用を検討してください。
  • App Service 構成で Key Vault 参照を使用して、アプリケーション内のシークレットを安全に公開します。
  • 運用環境とステージングで異なる設定が必要な場合は、スワップされないスロット固有のアプリ設定を作成します。 デプロイ スロットをスワップすると、アプリ設定は既定でスワップされます。
  • ローカル開発用にローカル環境変数を設定するか、アプリケーション プラットフォーム機能を利用します。 App Services 構成では、アプリ設定が環境変数として公開されます。 たとえば、Visual Studio では、起動プロファイルで環境変数を設定できます。 また、アプリ設定とユーザー シークレットを使用して、ローカル アプリケーションの設定とシークレットを格納することもできます。

監視

監視とは、IT システムからのデータの収集と分析です。 監視の目的は、Web アプリの正常性とセキュリティを追跡するための複数のレイヤーでの監視です。 監視は、ベースライン App Service アーキテクチャの重要な側面です。

Web アプリを監視するには、アプリケーション コード、インフラストラクチャ (ランタイム)、プラットフォーム (Azure リソース) からメトリックとログを収集して分析する必要があります。 詳細については、Azure アクティビティ ログ、Azure リソース ログ、アプリケーション ログを参照してください。

プラットフォームを監視する

プラットフォームの監視は、アーキテクチャ内の Azure サービスからのデータの収集です。 プラットフォームの監視に関する次のガイダンスを検討してください。

Application Gateway

Application Gateway は、バックエンド プールのリソースの正常性を監視します。 Application Gateway のアクセス ログを使用して、タイムスタンプ、HTTP 応答コード、URL パスなどの情報を収集します。 詳細については、Application Gateway の既定の正常性プローブとバックエンドの正常性と診断ログに関する記事を参照してください。

App Service

App Service には、監視を向上させるために有効にする必要がある組み込みの統合された監視ツールがあります。 Web アプリにテレメトリと監視機能 ("インプロセス インストルメンテーション") が既にある場合は、App Service で引き続き機能します。

  • 自動インストルメンテーションを有効にします。 App Service には、コード変更なしで有効にできるインストルメンテーション拡張機能があります。 アプリケーション パフォーマンス監視 (APM) の可視性が得られます。 詳細については、Azure App Service のパフォーマンスの監視に関する記事を参照してください。
  • 分散トレースを有効にします。 自動インストルメンテーションは、分散トレースとパフォーマンス プロファイラーを使用して分散クラウド システムを監視する方法を提供します。
  • カスタム テレメトリには、コードベースのインストルメンテーションを使用します。 ­Azure Application Insights では、カスタム アプリケーション テレメトリのコード ベースのインストルメンテーションもサポートされています。 コードに Application Insights SDK を追加し、Application Insights API を使用します。
  • App Service ログ有効にします。 App Service プラットフォームでは、トラブルシューティングをサポートするために有効にする必要がある追加のログが 4 つサポートされています。 これらのログは、アプリケーション ログ、Web サーバー ログ、詳細なエラー メッセージ、失敗した要求トレースです。
  • 構造化ログを使用します。 構造化ログ ライブラリをアプリケーション コードに追加します。 キーと値のペアを使用するようにコードを更新し、App Service でアプリケーション ログを有効にして、これらのログを Log Analytics ワークスペースに格納します。
  • App Service の正常性チェックをオンにします。 正常性チェックは、異常なインスタンスから要求を再ルーティングし、異常なインスタンスを置き換えます。 正常性チェックを機能させるには、App Service プランで 2 つ以上のインスタンスを使用する必要があります。
データベース
  • ユーザー データベースの分析情報。 Azure SQL データベースの場合は、Azure Monitor で SQL Insights を構成する必要があります。 データベースの分析情報では、動的管理ビューを使用して、正常性の監視、問題の診断、パフォーマンスの調整に必要なデータを公開します。 詳細については、Azure Monitor を使用した Azure SQL Database の監視に関する記事をご覧ください。
  • アーキテクチャに Cosmos DB が含まれている場合は、Cosmos DB 分析情報を使用するために何かを有効にしたり構成したりする必要はありません。

ガバナンス

Web アプリでは、アーキテクチャとセキュリティに関する決定を実施すると Azure Policy のメリットが得られます。 Azure Policy により、(1) デプロイ (拒否) できなくする、または (2) 望ましい状態からの構成ドリフトの検出 (監査) を容易にすることができます。 これにより、コードとしてのインフラストラクチャ (IaC) のデプロイや Azure portal での変更が、合意されたアーキテクチャから逸脱する場合、それを検出できます。 アーキテクチャ内のすべてのリソースを Azure Policy ガバナンスの下に配置する必要があります。 可能な場合は、組み込みのポリシーまたはポリシー イニシアチブを使用して、必要なネットワーク トポロジ、サービス機能、セキュリティ、監視に関する決定事項を適用します。次に例を示します。

  • App Service ではパブリック ネットワーク アクセスを無効にする必要がある
  • App Service では仮想ネットワーク統合を使用する必要がある
  • App Service は、Azure Private Link を使用して PaaS サービスに接続する必要がある
  • App Service では、FTP および SCM サイト デプロイに対してローカル認証方法を無効にする必要がある
  • App Service ではリモート デバッグをオフにする必要がある
  • App Service アプリは最新の TLS バージョンを使用する必要がある
  • Microsoft Defender for App Serviceを有効にする必要があります
  • Application Gateway に対して Web アプリケーション ファイアウォール (WAF) を有効にする必要がある

Application Gateway やネットワーク コンポーネント、App Service、Key Vault、監視などの主要なサービスの組み込みポリシーを参照してください。 組み込みのポリシーがニーズを完全に満たしていない場合は、カスタム ポリシーを作成したり、コミュニティ ポリシー (Azure ランディング ゾーンなど) を使用したりできます。 組み込みのポリシーを使用できる場合は優先します。

次のステップ

可用性の高い複数リージョンの Web アプリケーションについて読む