チュートリアル: Azure App Serviceで高可用性マルチリージョンアプリを作成する

高可用性とフォールトトレランスは、適切に設計されたソリューションの重要なコンポーネントです。堅牢な構成には、ダウンタイムを減らし、システムを自動的に実行し続けるために、予期しない障害に対する緊急計画が含まれています。

クラウドにアプリをデプロイするときは、そのクラウド内のアプリインフラストラクチャベースのリージョンを選択します。アプリを 1 つのリージョンにのみデプロイし、そのリージョンが使用できなくなった場合、アプリも使用できなくなります。可用性の欠如は、アプリのサービスレベルアグリーメント (SLA) の条件では受け入れられない可能性があります。可用性を確保するには、クラウド内の複数のリージョンにアプリとそのサービスをデプロイします。

このチュートリアルでは、高可用性マルチリージョン Web アプリをデプロイする方法について説明します。この手順では、Web アプリと Azure Front Door で構成される単純なシナリオを実装します。他のインフラストラクチャパターンをサポートするように概念を拡張できます。たとえば、アプリがAzure データベースオファリングまたはストレージアカウントに接続する場合は、「 SQL データベースのアクティブ geo レプリケーションとAzure Storage冗長性を参照してください。より詳細なシナリオの参照アーキテクチャについては、.NET の実行可能な Web アプリパターンを参照してください。

このチュートリアルでは、次の操作を行います。

別のリージョンに同一の App Service アプリを作成する
App Service へのパブリックアクセスをブロックするアクセス制限付きのAzure Front Doorを作成する

前提条件

Azure アカウントがない場合は、開始する前に free アカウントを作成します。

このチュートリアルを完了するには、以下が必要です。

Azure Cloud Shell で Bash 環境を使用します。詳細については、「Get started with Azure Cloud Shell」を参照してください。
CLI 参照コマンドをローカルで実行する場合は、Azure CLIinstallします。 Windowsまたは macOS で実行している場合は、Docker コンテナーでAzure CLIを実行することを検討してください。詳細については、「 Docker コンテナーでAzure CLIを実行する方法を参照してください。
- ローカルインストールを使用している場合は、az login コマンドを使用してAzure CLIにサインインします。認証プロセスを完了するには、ターミナルに表示される手順に従います。その他のサインインオプションについては、「Azure CLI を使用して Azure に認証する方法」を参照してください。
- メッセージが表示されたら、最初に使用するときにAzure CLI拡張機能をインストールします。拡張機能の詳細については、「Azure CLIを参照してください。
- az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。最新バージョンにアップグレードするには、az upgrade を実行します。

シナリオのアーキテクチャを確認する

次のアーキテクチャ図は、このチュートリアルで作成するインフラストラクチャを示しています。これは、異なるリージョン内の 2 つの同一の App Service アプリで構成されます。最初の Web アプリはアクティブなリージョンにあります。これは、受信トラフィックの処理を担当する プライマリ アプリです。 2 つ目のアプリは スタンバイ リージョンにあり、プライマリアプリの可用性を待機します。 Azure Front Doorは、プライマリ Web アプリへのトラフィックのルーティングを試みます。プライマリリージョンが使用できない場合、トラフィックはスタンバイ Web にルーティングされます。図の点線は、リージョンの状態に基づいてトラフィックルーティングを表しています。アクセス制限が構成されているため、インターネットからアプリへの直接アクセスがブロックされます。

複数リージョンの App Service のアーキテクチャを示す図。

Azureでは、負荷分散とトラフィックルーティングのさまざまなオプションが提供されます。 Azure Front Doorは、複数のリージョンにデプロイされたAzure App Serviceでホストされるインターネットに接続された Web アプリが含まれるため、このチュートリアルで選択します。構成がこのチュートリアルの例と異なる場合は、「シナリオに合わせて負荷分散ソリューションを選択する」を参照してください。

このチュートリアルのシナリオでは、次の動作を行います。

同じ App Service アプリが、2 つの異なるリージョンにデプロイされます。
Web アプリに直接送信されるパブリックトラフィックはブロックされます。
Azure Front Doorは、プライマリリージョンのアクティブなアプリにトラフィックをルーティングします。
セカンダリリージョンのスタンバイアプリは、必要に応じてトラフィックを処理するために使用できます。

リソースグループを作成します

このチュートリアルでは、異なる Azure リージョンで実行される Web アプリの 2 つのインスタンスが必要です。

使用可能なリージョンペアを確認し、Web アプリ用にペアになっている 2 つのリージョンを選択します。

このチュートリアルでは、2 つのリージョンを <primary-region> (eastus) と <standby-region> (westus) と呼びます。

このチュートリアルで構成するすべてのリソースのリソースグループを作成します。このチュートリアルでは、 <primary-region> の場所にリソースグループを作成します。

az group create --name <resource-group> --location <primary-region>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--name`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--location`	`<primary-region>`	リソースグループのリージョンの場所。このチュートリアルでは、リソースグループとプライマリ Web アプリに同じリージョンの場所を使用します。	`eastus`

実際の実装では、リージョン/リソースごとに個別のリソースグループを使用します。分離により、ディザスターリカバリーの状況でリソースを分離できます。

詳細については、 az group create コマンドリファレンスを参照してください。

2 つの App Service プランを作成する

Web アプリごとに 1 つずつ、2 つの App Service プランを作成します。対応するアプリを作成する予定のリージョンの場所に各プランを作成します。

このコマンドでは、先ほど選択したリージョンペアを使用します。プライマリ Web アプリのアクティブなリージョンとスタンバイ Web アプリのパッシブリージョンを使用します。

次のコマンドを実行してプライマリ Web アプリの App Service プランを作成し、もう一度コマンドを実行してスタンバイアプリのプランを作成します。

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--name`	`<app-service-plan>`	Web アプリの App Service プランの名前。各プランインスタンスには一意の名前が必要です。	`zava-primary-plan` `zava-standby-plan`
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--location`	`<region>`	Web アプリのリージョンの場所。	- プライマリ Web アプリ、アクティブなリージョン `eastus` - 待機ウェブアプリ、パッシブリージョン `westus`

詳細については、 az appservice plan create コマンドリファレンスを参照してください。

2 つのアプリケーションを作成する

2 つの App Service Web アプリを作成します。対応する App Service プランとリージョンの場所に各アプリを配置します。

Web アプリの --runtime 言語バージョンを特定します。

使用可能なランタイムの一覧に対して、次のコマンドを実行できます。
```
az webapp list-runtimes
```
このチュートリアルで説明するサンプル Node.js アプリの使用を計画している場合は、 <language-version> の値を NODE:24-lts に設定します。

2 つの Web アプリを作成します。次のコマンドを実行してプライマリ Web アプリを作成し、もう一度コマンドを実行してスタンバイアプリを作成します。

az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--name`	`<web-app-name>`	Web アプリの名前。各アプリにはグローバルに一意の名前が必要です。有効な文字は、 `a-z`、 `0-9`、および `-`です。	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--name`	`<app-service-plan>`	Web アプリの App Service プランの名前。	`zava-primary-plan` `zava-standby-plan`
`--runtime`	`<language-version>`	Web アプリのランタイム言語バージョン。	`NODE:24-lts`

詳細については、 az webapp create コマンドリファレンスを参照してください。

各 Web アプリの defaultHostName 値を識別します。ホスト名の形式は <web-app-name>.azurewebsites.net。

各 Web アプリのコマンド出力をスキャンして値を見つけるか、Web アプリごとに次のコマンドを実行します。

az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--name`	`<web-app-name>`	Web アプリの名前。	`zava-primary-app` `zava-standby-app`
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`

Azure ポータルでは、各アプリのホスト名が Web アプリ Overview ページに表示されます。

後で使用するためにホスト名の値を記録します。ホスト名を使用して、Azure Front Doorデプロイのバックエンドアドレスを定義します。

新しい Web アプリにアクセスできることを確認します。
1. ブラウザーで、プライマリ Web アプリのホスト名 ( zava-primary-app.azurewebsites.netなど) を入力します。
  
  接続が成功すると、次のメッセージが表示されます。
2. スタンバイ Web アプリのホスト名でテストを繰り返します。

Azure Front Doorの構成

複数リージョンのデプロイでは、 アクティブ/アクティブ または アクティブ/パッシブ の構成を使用できます。プライマリリージョンがアクティブで、スタンバイリージョンがパッシブです。

アクティブ/アクティブ構成では、要求は複数のアクティブなリージョンに分散されます。
アクティブ/パッシブ構成では、スタンバイ (パッシブ) リージョンでインスタンスが実行され続けますが、プライマリ (アクティブ) リージョンが失敗しない限り、トラフィックは送信されません。

Azure Front Doorでは、両方の構成を有効にすることができます。高可用性とフォールトトレランスのためのアプリの設計の詳細については、信頼性の設計レビューチェックリストを参照してください。

プロファイルを作成する

トラフィックを Web アプリにルーティングするために、Azure Front Door Premium のインスタンスを作成します。

Azure Front Doorレベルの比較を確認し、デプロイのレベルを選択します。

このチュートリアルでは、Azure Front Door Premium (Premium_AzureFrontDoor) を使用します。

Azure Front Door Standard を展開することをお考えの場合、Standard レベルでは WAF ポリシーを使用したマネージドルールのデプロイメントがサポートされていないことにご注意ください。

次のコマンドを実行してプロファイルを作成します。

az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。リソースグループ内で一意となる名前を使用してください。	`zava-profile`
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--sku`	`<front-door-tier>`	Azure Front Door のデプロイ用階層 SKU。	`Premium_AzureFrontDoor` (推奨) `Standard_AzureFrontDoor`

詳細については、 az afd profile create コマンドリファレンスを参照してください。

エンドポイントの追加

プロファイルにエンドポイントを作成します。最初のエンドポイントを作成したら、プロファイルに複数のエンドポイントを作成できます。

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door プロファイルのエンドポイントの名前。名前はグローバルに一意である必要があります。	`zava-endpoint`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`

詳細については、 az afd endpoint create コマンドリファレンスを参照してください。

オリジングループを作成する

Azure Front Doorにデプロイする場合は、Web アプリバックエンドのエンドポイントとして機能する配信元が必要です。詳細については、Azure Front Door の「オリジンとオリジングループ」を参照してください。配信元は、配信元グループに格納されます。

Azure Front Door プロファイルに配信元グループを作成し、2 つの Web アプリの配信元を含めます。

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Doorのオリジングループの名前。名前はグローバルに一意である必要があります。	`zava-origin-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`
`--probe-request-type`	`<probe-request>`	正常性プローブの要求の種類。	`GET`
`--probe-protocol`	`<probe-protocol>`	ヘルスプローブに使用するプロトコル。	`Http`
`--probe-interval-in-seconds`	`<probe-interval>`	正常性プローブ間の秒数。	60
`--probe-path`	`<probe-path>`	原点を基準とした相対パス。原点の正常性を判断するために使用されます。	`/` (バックスラッシュ)
`--sample-size`	`<sample-size>`	負荷分散決定で考慮するサンプルの数。	4
`--successful-samples-required`	`<required-samples>`	サンプル期間内に成功する必要があるサンプルの数。	3
`--additional-latency-in-milliseconds`	`<extra-latency>`	プローブが最小遅延カテゴリに入るための追加遅延 (ミリ秒単位)。	50

詳細については、 az afd origin-group create コマンドリファレンスを参照してください。

配信元グループに配信元を追加する

各 Web アプリの配信元をAzure Front Door配信元グループに追加します。

プライマリ Web アプリの配信元を追加します。 --priority パラメーターを 1 に設定します。このパラメーターは、このアプリがトラフィックのプライマリレシーバーであることをAzure Front Doorに通知します。

az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
   --origin-group-name <front-door-origin-group> \
   --origin-name <web-app-origin-name> \
   --origin-host-header <web-app-name>.azurewebsites.net \
   --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
   --http-port <origin-port> --https-port <origin-secure-port>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--host-name`	`<web-app-name>.azurewebsites.net`	プライマリ Web アプリのホスト名。ホスト名は、Web アプリ名 ( `zava-primary-app` とホスト識別子など) を組み合わせた `azurewebsites.net`。	`zava-primary-app.azurewebsites.net`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Doorのオリジングループの名前。	`zava-origin-group`
`--origin-name`	`<web-app-origin-name>`	プライマリ Web アプリの配信元の名前。名前は、配信元グループ内で一意である必要があります。	`primary-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	プライマリ Web アプリの配信元に要求を送信するホストヘッダー。値を指定しない場合、要求ホスト名によってこの値が決定されます。 Web Apps、Blob Storage、Cloud Services などのAzure CDN配信元では、このホストヘッダー値が既定で配信元のホスト名と一致する必要があります。	`zava-primary-app.azurewebsites.net`
`--priority`	`<origin-priority>`	配信元グループ内でこの配信元の優先順位。プライマリ Web アプリの場合は、優先度を 1 に設定します。 Azure Front Doorでは、配信元とアクティブリージョン間の負荷分散に優先順位の値が使用されます。値は 1 から 5 の間である必要があります。	1
`--weight`	`<origin-weight>`	負荷分散のためのオリジングループ内のオリジンの重み。値は 1 から 1000 の間である必要があります。	1000
`--enabled-state`	`<origin-state>`	この配信元がトラフィックを受信できるようにするかどうかを示します。	`Enabled`
`--http-port`	`<origin-port>`	配信元への HTTP 要求に使われるポート。	80
`--https-port`	`<origin-secure-port>`	配信元へのセキュリティで保護された HTTPS 要求に使用されるポート。	443

詳細については、 az afd origin create コマンドリファレンスを参照してください。

コマンドをもう一度実行し、 スタンバイ Web アプリの配信元を追加します。コマンドは同じパラメーターを使用しますが、次の一意のパラメーター値を使用します。

パラメーター	価値	説明	例
`--host-name`	`<web-app-name>.azurewebsites.net`	スタンバイ Web アプリのホスト名。	`zava-standby-app.azurewebsites.net`
`--origin-name`	`<web-app-origin-name>`	スタンバイ Web アプリの配信元の名前。	`standby-origin`
`--origin-host-header`	`<web-app-name>.azurewebsites.net`	スタンバイ Web アプリの配信元に要求を送信するホストヘッダー。	`zava-standby-app.azurewebsites.net`
`--priority`	`<origin-priority>`	配信元グループ内でこの配信元の優先順位。スタンバイ Web アプリの場合は、優先度を 2 に設定します。 Azure Front Doorは、すべてのトラフィックをプライマリ配信元に転送しようとします。プライマリ配信元が使用できない場合、トラフィックはスタンバイ配信元にルーティングされます。	2

ルートルールを追加する

Azure Front Door エンドポイントを配信元グループにマップするルーティング規則を追加します。ルートは、エンドポイントから配信元グループに要求を転送します。

Azure Front Door エンドポイントを配信元グループにマップするルートルールを作成します。

az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
   --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
   --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door プロファイルのエンドポイントの名前。	`zava-endpoint`
`--forwarding-protocol`	`<protocol-type>`	バックエンドアプリにトラフィックを転送するときに、このルート規則によって使用されるプロトコル。	`MatchRequest`
`--route-name`	`<route-rule-name>`	ルートルールの名前。 Azure Front Door プロファイル内で一意である必要があります。	`zava-route-rule`
`--https-redirect`	`<secure-redirect>`	HTTP トラフィックを HTTPS トラフィックに自動的にリダイレクトするかどうかを示します。	`Enabled`
`--origin-group-name`	`<front-door-origin-group>`	Azure Front Doorのオリジングループの名前。	`zava-origin-group`
`--supported-protocols`	`<protocol-list>`	このルート規則でサポートされているプロトコルの一覧。スペースを使用してプロトコルの種類を区切ります。	`Http Https`
`--link-to-default-domain`	`<domain-link>`	このルートが既定のエンドポイントドメインにリンクされているかどうかを示します。	`Enabled`

詳細については、 az afd route create コマンドリファレンスを参照してください。

デプロイが完了するまで約 15 分かかります。変更がグローバルに反映されるまでに時間がかかる場合があります。

Azure Front Doorのみを使用してアクセスを制限する

現在、ブラウザーでホスト名を入力することで、Web アプリに直接アクセスできます。アプリにアクセス制限を設定した場合は、トラフィックがAzure Front Door経由でのみアプリに到達するようにすることができます。

Azure Front Door機能は、トラフィックがサービス経由でのみ流れる場合に最適です。 Azure Front Door経由で送信されないトラフィックをブロックするように Web アプリの配信元を構成することをお勧めします。そうしないと、Azure Front Door Web アプリケーションファイアウォール、DDoS 保護、およびその他のセキュリティ機能がトラフィックによってバイパスされる可能性があります。

Azure Front Doorからアプリへのトラフィックは、AzureFrontDoor.Backend サービスタグで定義されている既知の IP 範囲のセットから発生します。サービスタグ制限規則を使用すると、トラフィックをAzure Front Doorからのみ発信するよう制限できます。

Azure Front Door プロファイルの識別子を取得します。

トラフィックが特定のAzure Front Door インスタンスからのみ送信されるようにするには、プロファイル ID が必要です。アクセス制限により、Azure Front Door プロファイルから送信された一意の HTTP ヘッダーに基づいて、受信要求がさらにフィルター処理されます。

az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`

コマンド出力には、プロファイル ID (32 桁の英数字値) が表示されます。

"0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"

次の手順では、 <profile-identifier> 値にプロファイル ID を使用します。

次のコマンドを実行してプライマリ Web アプリのアクセス制限を設定し、コマンドをもう一度実行してスタンバイアプリに制限を設定します。

az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
   --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--name`	`<web-app-name>`	アクセス制限を設定する Web アプリの名前。	`zava-primary-app` `zava-standby-app`
`--priority`	`<access-priority>`	プロファイルに対して定義されているすべてのルールで、アクセス制限規則の優先順位を指定します。値が小さいほど、優先度が高くなります。	100
`--service-tag`	`<tag-name>`	Azure Front Doorによって認識されるサービスタグ名。アクセス制限は、サービスタグによって示される IP 範囲に適用されます。	`AzureFrontDoor.Backend`
`--http-header`	`x-azure-fdid=<profile-identifier>`	受信トラフィックを追加でフィルター処理するために、1 つ以上の一意の HTTP ヘッダーを指定します。アクセス制限は、Azure Front Door プロファイルから送信された一意の HTTP ヘッダーに基づいて受信要求をフィルター処理します。ヘッダーは、Azure Front Door インスタンスのAzure Front Door プレフィックスとプロファイル識別子を結合します。	`x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee`

詳細については、 az webapp config access-restriction add コマンドリファレンスを参照してください。

アクセス制限をテストする

アクセス制限によってアプリへの直接アクセスが禁止されたことを確認します。

ブラウザーで、プライマリ Web アプリのホスト名 ( zava-primary-app.azurewebsites.netなど) を入力します。

接続が失敗し、次のメッセージが表示されます。
スタンバイ Web アプリのホスト名 ( zava-standby-app.azurewebsites.netなど) でテストを繰り返します。

Azure Front Doorデプロイをテストする

Azure Front Door Standard または Premium プロファイルを作成すると、構成がグローバルにデプロイされるまでに時間がかかる場合があります。デプロイが完了したら、フロントエンドホストにアクセスできます。

Azure Front Door エンドポイントのホスト名を取得します。

az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

パラメーター	価値	説明	例
`--resource-group`	`<resource-group>`	このチュートリアルで作成したリソースを含むリソースグループ。	`zava-resource-group`
`--profile-name`	`<front-door-profile>`	Azure Front Door プロファイルの名前。	`zava-profile`
`--endpoint-name`	`<front-door-endpoint>`	Azure Front Door プロファイルのエンドポイントの名前。	`zava-endpoint`

コマンド出力には、エンドポイントのホスト名が表示されます。

"zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"

ホスト名は、エンドポイント名、一意の英数字ハッシュ、識別子、およびAzure Front Doorサフィックスで構成されます。次の手順では、エンドポイントのホスト名を使用します。

詳細については、 az afd endpoint show コマンドリファレンスを参照してください。

ブラウザーで、エンドポイントのホスト名 ( zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.netなど) を入力します。

要求は、アクティブなリージョンのプライマリアプリに自動的にルーティングされます。

接続が成功すると、次のメッセージが表示されます。
ペアになっているリージョン内のアプリ間の即時グローバルフェールオーバーをテストします。
1. ブラウザーで、エンドポイントのホスト名 ( zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.netなど) を入力します。
2. az webapp stop コマンドを実行して、プライマリアプリを停止します。
  
  次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。
```
az webapp stop --name <primary-web-app> --resource-group <resource-group>
```
3. ブラウザーを更新します。
  
  トラフィックが他のリージョンの スタンバイ アプリに正しくリダイレクトされた場合は、同じページとメッセージが表示されます。
  
  ヒント
  
  フェールオーバーが完了するには、ページの更新が数回必要になる場合があります。
  
  Azure ポータルで Web アプリの状態を確認することで、Azure Front Doorがスタンバイアプリにリダイレクトされていることを確認できます。プライマリ Web アプリの [概要 ] ページで、[ スタート ] オプションを使用できる必要があります (灰色表示ではありません)。スタンバイ Web アプリの [概要 ] ページでは、[ スタート ] オプションを使用できません (灰色表示)。
4. az webapp stop コマンドをもう一度実行し、スタンバイ アプリを停止します。
  
  次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。
```
az webapp stop --name <standby-web-app> --resource-group <resource-group>
```
5. ブラウザーをもう一度更新します。
  
  スタンバイアプリも停止した場合は、すべてのトラフィックルーティングを停止する必要があります。今回は、次のエラーメッセージが表示されます。
6. az webapp start コマンドを実行し、スタンバイ アプリを再起動します。
  
  次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。
```
az webapp start --name <standby-web-app> --resource-group <resource-group>
```
7. ブラウザーを更新すると、正常なアプリ接続が表示されます。

検証では、意図したとおりにAzure Front Doorおよびフェールオーバー機能を使用してアプリにアクセスできることを確認します。

フェールオーバーテストが完了したら、 プライマリ アプリを再起動します。

リソースをクリーンアップする

前の手順では、Azureリソースをリソースグループ内に作成しました。今後これらのリソースが必要ない場合は、Cloud Shellで次のコマンドを実行してリソースグループを削除します。

<placeholder> パラメーターの値を、独自のリソースの情報に置き換えます。

az group delete --name <resource-group>

このコマンドの実行には数分かかることがあります。

ARM または Bicep からデプロイする

このチュートリアルで作成したリソースは、Azure Resource Manager テンプレート (ARM テンプレート) またはBicep テンプレートを使用してデプロイできます。 GitHubで高可用性マルチリージョン Web アプリ Bicep ファイルから開始できます。このテンプレートは、Azure Front Doorの背後にある異なるリージョンに 2 つの Web アプリを含む、セキュリティで保護された高可用性のマルチリージョンのエンドツーエンドソリューションを作成するのに役立ちます。

ARM テンプレートと Bicep テンプレートをデプロイする方法については、「 Azure CLI を使用してBicep ファイルをデプロイする」を参照してください。

よく寄せられる質問

このチュートリアルでは、複数リージョンの Web アプリを有効にするベースラインインフラストラクチャをデプロイしました。 App Service には、セキュリティのベストプラクティスと推奨事項に従ったアプリケーションの実行に役立つ機能が用意されています。

このセクションでは、ベストプラクティスに従ってアプリをさらにセキュリティで保護し、リソースをデプロイおよび管理するのに役立つ、よく寄せられる質問に対する回答を示します。

インフラストラクチャとAzure リソースの管理とデプロイ

このチュートリアルでは、Azure CLIを使用してインフラストラクチャリソースをデプロイしました。継続的デプロイメカニズムを構成してアプリケーションインフラストラクチャを管理することを検討してください。異なるリージョンにリソースをデプロイするため、リージョン全体でそれらのリソースを個別に管理する必要があります。リソースが各リージョンで同一であることを確認するには、コードとしてのインフラストラクチャ (IaC) (ARM テンプレートや Teraform) は、Azure Pipelines や GitHub Actions などのデプロイパイプラインで使用する必要があります。この構成を適切に設定すると、リソースを変更すると、すべてのデプロイリージョンで更新がトリガーされます。詳細については、「継続的配置を Azure App Serviceを参照してください。

ステージングスロットを使用して運用環境に安全にデプロイする

運用環境のアプリとスロットにアプリケーションコードを直接デプロイすることはお勧めしません。運用環境にプッシュする前に、アプリをテストして変更を検証するための安全な場所を確保することが重要です。ステージングスロットとスロットスワップの組み合わせを使用して、テスト環境から運用環境にコードを移動します。

このチュートリアルでは、ステージングスロットの使用をサポートするベースラインインフラストラクチャを作成しました。 Web アプリのインスタンスごとにデプロイスロットを作成し、GitHub Actionsを使用してこれらのステージングスロットへの継続的デプロイを構成できます。インフラストラクチャ管理と同様に、リージョン間の変更が確実に同期されるように、アプリケーションソースコードの継続的デプロイを構成することもお勧めします。継続的デプロイを構成しない場合は、コードが変更されるたびに、各リージョンの各アプリを手動で更新する必要があります。

ステージングスロットを使用するには、次の手順に従います。

この手順では、App Service アプリにデプロイする準備ができているアプリが必要です。

チュートリアルを完了した場合は、プライマリ Web アプリとスタンバイ Web アプリを使用できます。ただし、十分なデプロイスロットをサポートする App Service プランが必要です。詳細については、「Azureサブスクリプションとサービスの制限、クォータ、制約を参照してください。

アプリがない場合は、Node.js Hello World サンプルアプリから開始できます。 GitHub リポジトリをフォークして、変更を加える独自のコピーを作成します。
Web アプリの App Service スタック設定を構成します。

スタック設定は、アプリで使用される言語バージョンまたはランタイムを参照します。

Azure ポータルで設定を構成することも、az webapp config set コマンドを使用することもできます。 Node.js サンプルを使用する場合は、スタック設定を Node 24 LTS に設定します。
1. Azure ポータルで、primary Web アプリに移動します。
2. 左側のメニューで、[設定]>[構成] の順に選択します。
3. [ スタック設定 ] タブで、次の設定を構成します。
  1. [ノード] などのスタック値を選択します。
  2. ノード 24 LTS などのバージョン値を選択します。
  3. を選択してを適用します。
4. プロセスを繰り返して、 スタンバイ Web アプリの App Service スタック設定を構成します。
Azure ポータルで継続的デプロイを設定します。 GitHub Actionsなどのプロバイダーを使用して継続的配置を構成する方法の詳細なガイダンスについては、「継続的配置を Azure App Serviceに構成する」を参照してください。

次のコマンドを実行して、stage Web アプリのという名前のステージングスロットを作成します。

az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>

az webapp deployment slot create コマンドをもう一度実行し、stage Web アプリのという名前のステージングスロットを作成します。
ステージングスロットごとにGitHub Actionsを使用して継続的デプロイを構成します。
1. Azure ポータルで、primary Web アプリに移動します。
2. 左側のメニューで、 デプロイ>デプロイスロットを選択します。
3. 一覧で ステージ スロットを見つけ、スロットを選択して詳細ウィンドウを開きます。
4. 左側のメニューで、[ デプロイ>デプロイセンター] を選択します。
5. Settings タブで、Source オプションを GitHub に設定します。
6. GitHubから初めてデプロイする場合は、Authorize を選択し、承認プロンプトに従います。別のユーザーのリポジトリからデプロイする場合は、 [アカウントの変更] を選択します。
7. GitHubを使用してAzure アカウントを承認したら、CI/CD を構成する Organization、Repository、および Branch を選択します。組織またはリポジトリが見つからない場合は、GitHubに対してさらに多くのアクセス許可を有効にする必要があります。詳細については、「組織のリポジトリへのユーザーアクセスを管理する」を参照してください。
  
  Node.js サンプルアプリを使っている場合は、次の設定を使います。
  
  設定価値
  
  組織 <your-GitHub-organization>
  
  リポジトリ nodejs-docs-hello-world
  
  ブランチ メイン
8. [保存] を選択します。

設定	価値
組織	`<your-GitHub-organization>`
リポジトリ	nodejs-docs-hello-world
ブランチ	メイン

選んだリポジトリとブランチでの新しいコミットが、App Service アプリスロットに継続的にデプロイされるようになりました。コミットとデプロイは、 [ログ] タブで追跡できます。

発行プロファイルを使用して App Service に対する認証を行う既定のワークフローファイルが、GitHub リポジトリに追加されます。このファイルは、<repo-name>/.github/workflows/ ディレクトリに移動して見ることができます。

App Service で基本認証を無効にする

FTP および SCM エンドポイントへのアクセスを、Microsoft Entra ID によって認証されたユーザーのみに制限するには、基本認証を無効化します。

継続的配置ツールを使用してアプリケーションのソースコードをデプロイする場合、基本認証を無効にするには、継続的配置を構成するための追加の手順が必要です。たとえば、Microsoft Entra資格情報を使用しないため、発行プロファイルを使用することはできません。代わりに、サービスプリンシパルまたは OpenID Connect 資格情報を使用する必要があります。

次のコマンドは、App Service プライマリ Web アプリとステージングスロット、およびスタンバイ Web アプリとステージングスロットの基本認証を無効にします。次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

プライマリ Web アプリの運用サイトとステージングスロットの FTP アクセスを無効にします。

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name> --set properties.allow=false

az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<web-app-name>/slots/stage --set properties.allow=false

スタンバイ Web アプリのコマンドをもう一度実行します。

プライマリ Web アプリの運用サイトとステージングスロットの WebDeploy ポートと SCM サイトへの基本認証アクセスを無効にします。

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app> --set properties.allow=false

az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
   --parent sites/<primary-web-app>/slots/stage --set properties.allow=false

スタンバイ Web アプリのコマンドをもう一度実行します。

サインインをテストおよび監視する方法など、基本認証の無効化の詳細については、「 App Service デプロイでの基本認証の無効化」を参照してください。

基本認証を無効にした場合に継続的デプロイを使用する

App Service アプリで基本認証を許可する場合は、App Service で使用可能なデプロイ方法のいずれかを使用できます。たとえば、ステージングスロットセクションで構成した発行プロファイルを使用できます。

App Service アプリの基本認証を無効にした場合、継続的デプロイには認証にサービスプリンシパルまたは OpenID Connect が必要です。 GitHub Actions をコードリポジトリとして使用する場合は、GitHub Actions を使用して Azure App Service にデプロイする方法については、GitHub Actions を使用して Azure App Service にデプロイするを参照してください。このチュートリアルでは、GitHub Actionsを使用して App Service にデプロイするサービスプリンシパルまたは OpenID Connect を作成する手順について説明します。次のセクションの手順に従って、プロセスを完了することもできます。

GitHub Actionsを使用してサービスプリンシパルと資格情報を作成する

GitHub Actionsとサービスプリンシパルを使用して継続的デプロイを構成します。

プライマリ Web アプリとスタンバイ Web アプリのサービスプリンシパルを作成します。

次の <placeholder> パラメーター値を、独自のリソースの情報に置き換えます。

az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>

出力は、その App Service アプリへのアクセスを提供するロール割り当て資格情報を含む JSON オブジェクトです。

{
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
  "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
  "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

JSON にはクライアントシークレットが含まれています。このシークレットは現時点でのみ表示されます。

ヒント

最小限のアクセス権を付与することをお勧めします。この例では、スコープは、リソースグループ全体ではなく、アプリのみに制限されます。

クライアントシークレットのレコードが作成されるように JSON オブジェクトをコピーします。

GitHub アクションワークフローの一部として、Azure サインイン操作にサービスプリンシパルの資格情報を指定します。

ワークフローに値を直接指定することも、ワークフローで参照されるシークレットGitHubとして格納することもできます。値をGitHubシークレットとして保存すると、より安全なオプションになります。

アプリのGitHub リポジトリを開きます。
設定>セキュリティ>Secrets と変数>Actions に移動します。

[ 新しいリポジトリシークレット ] を選択し、次の設定ごとにシークレットを作成します。 JSON 出力の値を使用します。

設定	価値	例
AZURE_APP_ID	`<application/client-id>`	`00001111-aaaa-2222-bbbb-3333cccc4444`
AZURE_PASSWORD	`<client-secret>`	`ffffffff-5a5a-6b6b-7c7c-888888888888`
AZURE_TENANT_ID	`<tenant-id>`	`aaaabbbb-6666-cccc-7777-dddd8888eeee`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`	`cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a`

GitHub Actionsのワークフローを作成する

App Service アプリにアクセスできるサービスプリンシパルを作成したら、アプリの既定のワークフローを編集します。これらのワークフローは、継続的デプロイを構成するときに自動生成されます。

公開プロファイルではなく、サービスプリンシパルを使用して認証する必要があります。サンプルワークフローについては、GitHub リポジトリにワークフローファイルを追加するにあるサービスプリンシパルタブを参照してください。次のサンプルワークフローは、 Node.js サンプルアプリに使用できます。

アプリのGitHub リポジトリを開きます。
<repo-name>/.github/workflows/ ディレクトリに移動します。自動生成されたワークフローが表示されます。
ワークフローファイルごとに、[ 編集] (鉛筆) を選択します。

ワークフローファイルの内容を次の内容に置き換えます。このコードでは、資格情報のGitHub シークレットが既に作成されていることを前提としています。

env セクションで、次の設定を構成します。

AZURE_WEBAPP_NAME: <web-app-name> プレースホルダーを Web アプリの名前に置き換えます。
NODE_VERSION: 使用するノードのバージョンを指定します。 Node.js サンプルの場合、値は '24.x'。
AZURE_WEBAPP_PACKAGE_PATH: Web アプリプロジェクトへのパスを指定します。既定値はリポジトリルート ( '.') です。
AZURE_WEBAPP_SLOT_NAME: アプリケーションスロット名を指定します。共通名は stage。


 name: Build and deploy Node.js app to Azure Web App

 on:
   push:
     branches:
       - main
   workflow_dispatch:

 env:
   AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
   NODE_VERSION: '24.x'                # Node version to use
   AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
   AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name

 jobs:
   build:
     runs-on: ubuntu-latest

     steps:
       - uses: actions/checkout@v4

       - name: Set up Node.js version
         uses: actions/setup-node@v4
         with:
           node-version: ${{ env.NODE_VERSION }}

       - name: npm install, build
         run: |
           npm install
           npm run build --if-present

       - name: Upload artifact for deployment job
         uses: actions/upload-artifact@v4
         with:
           name: node-app
           path: .

   deploy:
     runs-on: ubuntu-latest
     needs: build
     environment:
       name: 'stage'
       url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

     steps:
       - name: Download artifact from build job
         uses: actions/download-artifact@v4
         with:
           name: node-app

       - uses: azure/login@v2
         with:
           creds: |
             {
               "clientId": "${{ secrets.AZURE_APP_ID }}",
               "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
               "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
               "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
             }

       - name: 'Deploy to Azure Web App'
         id: deploy-to-webapp
         uses: azure/webapps-deploy@v3
         with:
           app-name: ${{ env.AZURE_WEBAPP_NAME }}
           slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
           package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

       - name: logout
         run: |
           az logout

ワークフローファイルの変更を保存し、リポジトリのメインブランチに直接コミットします。

コミットによって、GitHub アクションがトリガーされ、もう一度実行され、コードがデプロイされます。今回は、サービスプリンシパルが認証に使用されます。

スロットトラフィックルーティングを使用してアプリの更新をテストする

スロットによるトラフィックルーティングを使うと、ユーザートラフィックの事前定義された部分を各スロットに転送できます。最初は、トラフィックの 100% が運用サイトに送信されます。ただし、10% のトラフィックをステージングスロットに送信できます。スロットトラフィックルーティングに対するこの方法では、ステージングスロットへのアクセスを試みるユーザーの 10% が自動的に送信されます。このアプローチでは、Azure Front Door インスタンスを変更する必要はありません。 App Service のスロットスワップとステージング環境の詳細については、「 Azure App Serviceを参照してください。

ステージングスロットから運用スロットにコードを移動する

ステージングスロットでのテストと検証が完了したら、ステージングスロットから運用サイトへのスロットスワップを実行できます。各リージョン内のアプリのすべてのインスタンスのスワップを完了します。スロットスワップの間、App Service プラットフォームによって、ターゲットスロットにダウンタイムが発生しないことが保証さます。

プライマリ Web アプリのスワップを実行します。

az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production

スタンバイ Web アプリのスワップを実行します。

az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production

数分後、Azure ポータルの Azure Front Door エンドポイントに移動し、スロットのスワップが成功したことを検証します。

この時点で、アプリが稼働しており、アプリケーションのソースコードに加えた変更によって、両方のステージングスロットへの更新が自動的にトリガーされます。その後、そのコードを運用環境に移動する準備ができたら、スロットスワッププロセスを繰り返すことができます。

複数リージョンデプロイを使用して中断と継続性の問題を回避する

スロットスワップが発生しているサイトをAzure Front Doorの配信元グループから一時的に削除することで、リージョン間の継続性に関する潜在的な中断や問題を回避できます。このアクションは、お客様が異なるバージョンのアプリを同時に表示するのを防ぐのに役立ちます。また、アプリに大きな変更を加える場合にも役立ちます。一時的な削除により、すべてのトラフィックが他の配信元にリダイレクトされます。

Azure ポータルで、Azure Front Door インスタンスに移動します。
左側のメニューで、[設定]>[Origin グループ]を選択します。
配信元グループの一覧で、一時的に削除するスロットを含む配信元グループを選択します。
[ 配信元グループの更新 ] ウィンドウで、 配信元ホスト名 の一覧で削除するスロットを見つけます。
その他のアクション (...) を選択>削除し、[更新] を選択します。

変更の適用には数分かかる場合があります。
削除されたスロットへのトラフィックを許可する準備ができたら、[ 配信元グループの更新 ] ウィンドウに戻ります。
上部にある + 配信元の追加 を選択して、配信元スロットを配信元グループに再追加します。

追加の配信元グループを作成し、ルートの関連付けを変更する

オリジンを削除して再追加しない場合は、Azure Front Door インスタンス用に追加のオリジングループを作成できます。その後、目的の原点を指す起点グループにルートを関連付けることができます。

たとえば、2 つの追加の配信元グループを作成できます。1 つはプライマリ (アクティブ) リージョン用、1 つはスタンバイ (パッシブ) リージョン用です。プライマリリージョンに変更が発生している場合は、ルートをスタンバイリージョンに関連付けます。スタンバイリージョンが変更されている場合は、ルートをプライマリリージョンに関連付けます。すべての変更が終わったら、両方のリージョンを含む元の配信元グループにルートを関連付けることができます。この方法が機能するのは、ルートは一度に 1 つの配信元グループにのみ関連付けることができるためです。

次の 3 つの配信元グループを含む構成を検討します。

Main-Origin グループには、それぞれのリージョンのプライマリ Web アプリとスタンバイ Web アプリの両方が含まれています。
Primary-Origin グループには、アクティブなリージョン内のプライマリ Web アプリのみが含まれます。
Standby-Origin グループには、パッシブリージョン内のスタンバイ Web アプリのみが含まれます。

プライマリ Web アプリが変更されるとします。変更が開始される前に、 Main-Origin グループのルートの関連付けが Secondary-Origin グループに変更されます。このアクションにより、それぞれのリージョンのプライマリ Web アプリが変更されている間に、それぞれのリージョンのスタンバイ Web アプリにすべてのトラフィックルートが確実に送信されます。

配信元グループのルートの関連付けを変更するには、次の手順に従います。

Azure ポータルで、Azure Front Door インスタンスに移動します。
左側のメニューで、[設定]>[Origin グループ]を選択します。
配信元グループの一覧で、[ルート] 列に 関連付けられていない インジケーターを示す配信元グループを見つけます。
その他のアクション (...) を選択>エンドポイントとルートを関連付けます。
[ ルートの関連付け ] ウィンドウで、配信元グループに関連付けたいルートを 1 つ以上選択し、[ 関連付け ] を選択します。

高度なツールサイトへのアクセスを制限する

Azure App サービスでは、SCM/高度なツールサイトを使用してアプリを管理し、アプリケーションのソースコードを展開します。 Front Door 経由でのこのサイトへのアクセスが必要になることはほとんどないため、SCM /高度なツールのサイトをロックダウンすることを検討してください。たとえば、選択したツールを使って自分がテストを実施して継続的デプロイを有効にすることのみを許可するアクセス制限を設定できます。デプロイスロットを使っている場合、テストと検証はステージングスロットで行われるので、特に運用スロットでは、SCM サイトへのほぼすべてのアクセスを拒否できます。

フィードバック

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

Last updated on 2026-04-14

チュートリアル: Azure App Serviceで高可用性マルチリージョン アプリを作成する

前提条件

シナリオのアーキテクチャを確認する

リソース グループを作成します

2 つの App Service プランを作成する

2 つのアプリケーションを作成する

Azure Front Doorの構成

プロファイルを作成する

エンドポイントの追加

オリジングループを作成する

配信元グループに配信元を追加する

ルート ルールを追加する

Azure Front Doorのみを使用してアクセスを制限する

アクセス制限をテストする

Azure Front Doorデプロイをテストする

リソースをクリーンアップする

ARM または Bicep からデプロイする

よく寄せられる質問

インフラストラクチャとAzure リソースの管理とデプロイ

ステージング スロットを使用して運用環境に安全にデプロイする

App Service で基本認証を無効にする

基本認証を無効にした場合に継続的デプロイを使用する

GitHub Actionsを使用してサービス プリンシパルと資格情報を作成する

GitHub Actionsのワークフローを作成する

スロット トラフィック ルーティングを使用してアプリの更新をテストする

ステージング スロットから運用スロットにコードを移動する

複数リージョンデプロイを使用して中断と継続性の問題を回避する

追加の配信元グループを作成し、ルートの関連付けを変更する

高度なツール サイトへのアクセスを制限する

関連するコンテンツ

フィードバック

その他のリソース

チュートリアル: Azure App Serviceで高可用性マルチリージョンアプリを作成する

リソースグループを作成します

ルートルールを追加する

ステージングスロットを使用して運用環境に安全にデプロイする

GitHub Actionsを使用してサービスプリンシパルと資格情報を作成する

スロットトラフィックルーティングを使用してアプリの更新をテストする

ステージングスロットから運用スロットにコードを移動する

高度なツールサイトへのアクセスを制限する