この記事では、App Service リソースを別の Azure リージョンに移動する方法について説明します。
既存のAzureリソースをあるリージョンから別のリージョンに移動したい理由はさまざまです。 次のいずれかを行うことを考慮してください。
- 新しい Azure リージョンを活用してください。
- 特定の地域でのみ利用可能な機能やサービスを展開する。
- 内部ポリシーおよびガバナンスの要件を満たす。
- 企業の合併・買収に適応する
- 計画能力の要件を満たす。
App Service リソースはリージョン固有のものであり、リージョン間で移動することはできません。 ターゲット リージョンに既存の App Service リソースのコピーを作成し、新しいアプリにコンテンツを再配置する必要があります。 ソース アプリでカスタム ドメインを使用している場合は、再配置の完了後に、ターゲット リージョンの新しいアプリに移行できます。
アプリのコピーを容易にするために、個々の App Service アプリをバックアップし、別のリージョンの App Service プランに復元できます。
[前提条件]
- App Service アプリが、移動元の Azure リージョンにあることを確認します。
- ターゲット リージョンで App Service と、そのリソースを移動する関連サービスがサポートされていることを確認します。
- App Service リソースをターゲット サブスクリプションとリージョンにデプロイするための十分なアクセス許可が存在することを確認します。
- Azure ポリシーにリージョン制限が割り当てられているかどうかを確認します。
- コンピューティング リソースの価格はリージョンによって異なる可能性があるため、運用コストを考慮します。 考えられるコストを見積もる方法については、料金計算ツールを参照してください。
準備する
現在使用しているすべての App Service リソースを特定します。 例えば次が挙げられます。
- App Service アプリ
- App Service プラン
- デプロイ スロット
- Azure で購入したカスタム ドメイン
- TLS/SSL 証明書
- Azure Virtual Network の統合
- ハイブリッド接続。
- マネージド ID
- バックアップの設定
インポートされた証明書やハイブリッド接続などの特定のリソースには、他の Azure サービスとの統合が含まれています。 これらのリソースをリージョン間で移動する方法については、それぞれのサービスのドキュメントを参照してください。
計画
このセクションは、次の領域の計画チェックリストです。
- 状態、ストレージ、およびダウンストリームの依存関係
- 証明 書
- コンフィギュレーション
- 仮想ネットワーク接続 / カスタム名 / DNS
- アイデンティティーズ
- サービス エンドポイント
状態、ストレージ、ダウンストリームの依存関係
App Service アプリがステートフルかステートレスかを判断します。 App Service Apps はステートレスであり、
%HOME%\siteドライブ上のファイルは、任意の一時ファイルでデプロイされたアプリケーションを実行するために必要なファイルのみにすることをお勧めしますが、その場合でも、仮想ドライブにランタイム アプリケーションの状態を格納することはできます%HOME%\site。 アプリケーションがアプリの共有ストレージ パスに状態を書き込む場合は、リソースの移動中にその状態を管理する方法を計画してください。ヒント
Kudu を使用すると、ポータル アクセスと共に、
%HOME%\siteディレクトリのファイルを読み取り/書き込みできるファイル アクセス API (仮想ファイル システム (VFS)) を提供できます。 詳細については、「Kudu Wiki」をご覧ください。アプリケーション コードで内部キャッシュと状態を確認します。
セッション アフィニティ設定を無効にします。 可能であれば、セッション アフィニティ設定を無効にすることをお勧めします。 セッション アフィニティを無効にすると、水平方向のスケールアウトの負荷分散が向上します。内部状態は、特に、ダウンタイムがゼロであるのが要件の場合、ワークロードの一括移行のための計画に影響を与える可能性があります。 可能であれば、アプリケーションの状態をリファクターして、移動の準備でアプリケーションをステートレスにすると有益な場合があります。
データベース接続文字列を分析します。 データベース接続文字列は、アプリの設定で確認できます。 ただし、アプリケーションに付属する構成ファイルでハードコーディングまたは管理することもできます。 ワークロードを移動するためのより高いレベルの計画の一環として、データの移行やレプリケーションを分析して計画します。 チャットやレイテンシーが重要なアプリケーションの場合、ターゲットリージョン内のアプリケーションがソースリージョンのデータソースにアクセスするのは効率的ではありません。
外部キャッシュ (Redis など) を分析します。 アプリケーション キャッシュは、できるだけアプリケーションの近くにデプロイする必要があります。 キャッシュの設定方法、有効期限または削除のためのポリシー、コールド キャッシュが一括移行後にワークロードにアクセスするために最初のユーザーに与える可能性がある影響を分析します。
API (またはアプリケーション) の依存関係の分析と計画 ターゲット リージョン内のアプリがソース リージョンにまだ存在する依存関係に戻った場合、リージョン間の通信のパフォーマンスは低下します。 ワークロードの再配置の一環として、すべてのダウンストリーム依存関係を再配置することをお勧めします。 ただし、*オンプレミス* リソースは例外であり、特にターゲット リージョンに地理的に近いリソースは除きます (復帰シナリオの場合と同様)。
Azure Container Registry (ACR) は、カスタム コンテナー イメージを使用するように構成されている場合、App Service のダウンストリーム (ランタイム) 依存関係として機能できます。 コンテナー レジストリがアプリ自体と同じリージョンにある方が理にかなっています。 ターゲット取得リージョンの新しいコンテナー レジストリに必要なイメージをアップロードすることを検討してください。 または、ソース リージョン内にイメージを保持する予定がある場合、geo レプリケーション機能の使用を検討してください。
リージョン サービスを分析して計画します。 Application Insights と Log Analytics データはリージョン別のサービスです。 ターゲット リージョンに新しい Application Insights と Log Analytics ストレージを作成することを検討してください。 App Insights の場合、新しいリソースは、Azure App Configuration の変更の一環として更新する必要がある接続文字列にも影響します。
証明 書
App Service 証明書リソースは、新しいリソース グループまたはサブスクリプションに移動できますが、リージョン間では移動できません。 エクスポート可能な証明書を、新しいリージョンのアプリまたは Key Vault にインポートすることもできます。 このエクスポートとインポートのプロセスは、リージョン間の移動と同じです。
サービスの再配置を計画するときに考慮する必要がある証明書の種類には、さまざまなものがあります。
| 証明書タイプ | エクスポート可能 | コメント |
|---|---|---|
| App Service マネージド | いいえ | これらの証明書を新しいリージョンで再作成します。 |
| Azure Key Vault 管理されています | イエス | これらの証明書は、Key Vault からエクスポートした後、新しいリージョンの Key Vault にインポートできます。 |
| 秘密キー (自己管理型) | イエス | Azure の外部で取得した証明書は、App Service からエクスポートした後、新しいリージョンの新しいアプリまたは Key Vault にインポートできます。 |
| 公開キー | いいえ | アプリの証明書の中には、公開キーのみがあって秘密を含まないものがあります。これらは、他のセキュリティ保護エンドポイントへのアクセスに使用されます。 必要な公開キー証明書ファイルを取得し、新しいリージョン内のアプリにインポートします。 |
さらに考慮すべき点は次のとおりです。
- App Service アプリの SSL 接続が特定のアプリ指定 IP にバインドされているアプリ割り当てアドレスは、サード パーティのネットワークから App Service への呼び出しを許可するために使用できます。 たとえば、ネットワーク/IT 管理者は、オンプレミス ネットワークまたは仮想ネットワークからの発信呼び出しをロックダウンして、静的で既知のアドレスを使用することができます。 そのように、アプリ割り当てアドレス機能が使用されている場合は、アプリの呼び出し元の内部、外部、サード パーティなどのアップストリーム ファイアウォール規則を確認し、新しいアドレスを通知する必要があります。 ファイアウォール規則には、パートナーや既知の顧客などの内部、外部、またはサード パーティを指定できます。
- アップストリーム ネットワーク仮想アプライアンス (NVA) またはリバース プロキシを検討します。 ホスト ヘッダーまたは SSL 終端を書き換える場合は、NVA 構成の変更が必要になる場合があります。
注
App Service Environment は、SSL 経由のダウンストリーム アプリケーション依存関係へのダウンストリーム呼び出しを許可する唯一の App Service オファリングです。SSL は 、非標準のルート CA 証明書を使用して構築された自己署名/PKI に依存します。 マルチテナント サービスでは、顧客が信頼された証明書ストアにアップロードするためのアクセス権は提供されません。
現在、App Service Environment では SSL 証明書の購入は許可されておらず、独自の証明書を持ち込むことだけができます。 IP-SSL は不可能ですが (意味がありません)、SNI は有効です。 内部 App Service Environment はパブリック ドメインに関連付けられていないため、使用される SSL 証明書は顧客が提供する必要があるため、PKI を使用して生成された内部使用の証明書など、転送可能です。 外部モードの App Service Environment v3 は、通常のマルチテナント App Service と同じ機能を共有します。
コンフィギュレーション
Azure portal から、既存のアプリ設定と接続文字列のスナップショットをキャプチャできます。 [設定]>[環境変数] を展開し、[アプリ設定] または [接続文字列] で [高度な編集] を選択して、既存の設定または接続を含む JSON 出力を保存します。 これらの設定は新しいリージョンで再作成する必要がありますが、値自体は、接続済みサービスでのその後のリージョン変更の結果として変更される可能性があります。
既存の Key Vault の参照は、Azure の地理的境界を越えてエクスポートできません。 必要な参照は新しいリージョンで再作成する必要があります。
アプリ構成は、Azure App Configuration によって、または他の何らかの中央 (ダウンストリーム) データベースの依存関係から管理される場合があります。 変更が必要と考えられる環境およびリージョンに固有の設定については、App Configuration ストアまたは同様のストアを確認してください。
- ディスクファイルの設定を確認してください。それはアプリケーション設定によって上書きされるか、されない場合があります。
仮想ネットワーク接続 / カスタム名 / DNS
App Service Environment は、VNet によって挿入されるシングル テナント サービスです。 App Service Environment ネットワークは、"プライベート エンドポイント" または "リージョン VNet 統合" のいずれかまたは両方を必要とするマルチテナント App Service とは異なります。 その他のオプションとして、従来の P2S VPN ベースの VNet 統合やハイブリッド接続 (Azure Relay サービス) などがあります。
注
ASEv3 ネットワークは簡略化されています。Azure 管理トラフィックと App Service Environment 独自のダウンストリーム依存関係は顧客の仮想ネットワークに表示されないため、お客様がすべてのトラフィックに強制トンネルを使用している場合や、ネットワーク仮想アプライアンス/ファイアウォール経由で送信トラフィックのサブセットを送信するときに必要な構成が大幅に簡素化されます。
ハイブリッド接続 (Azure Relay) はリージョン別です。 ハイブリッド接続を使用している場合、多くの場合、移動は可能ですが、Azure Relay 名前空間を別のリージョンに移動するのではなく、再デプロイする方が簡単です。 ターゲット リソースをデプロイするときに、ハイブリッド接続が新しいリージョンで構成されていることを確認し、ハイブリッド接続マネージャーに再リンクします。 必ず、ハイブリッド接続マネージャーの場所を慎重に検討してください。
ウォーム スタンバイ リージョンの戦略に従います。 リソースの再配置の前に、コア ネットワークと接続、ハブ ネットワーク、ドメイン コントローラー、DNS、VPN、Express Route などが存在し、テストされていることを確認します。
アップストリームまたはダウンストリームのネットワーク ACL と構成を検証します。 たとえば、アプリ トラフィックのみを許可リストに含める外部ダウンストリーム サービスについて考えます。 マルチテナント App Service の新しいアプリケーション計画に再配置することは、送信 IP アドレスの変更でもあります。
ほとんどの場合、ターゲット リージョンの VNet に一意のアドレス空間があることを保証するのが最も有益です。 一意のアドレス空間を使用すると、データのレプリケートなど、仮想ネットワークの接続が容易になります。 したがって、これらのシナリオでは、変更することが暗黙的な要件となります。
- プライベート DNS
- IP アドレスによってリソースを参照するハード コーディングまたは外部構成 (ホスト名なし)
- ネットワーク セキュリティ グループとファイアウォールの構成を含むネットワーク ACL (ここではオンプレミスの NVA への影響も考慮する)
- ルーティング規則、ユーザー定義ルート テーブル
また、既存の DevOps デプロイ リソースを転送する場合は、リージョン固有の IP 範囲/サービス タグを含む構成を確認してください。
Azure ドメインと Azure DNS Private Zones 用に Azure に転送するように構成された、顧客がデプロイしたプライベート DNS に対しては、変更を少なくする必要があります。 ただし、プライベート エンドポイントはリソース FQDN に基づいており、多くの場合、これはリソース名 (ターゲット リージョンでは異なると予想される) であるため、構成で参照される FQDN が適宜更新されるように、構成は必ずクロス チェックしてください。
プライベート エンドポイントを使用する場合、ターゲット リージョンで再作成します。 リージョンの仮想ネットワーク統合にも同じことが当てはまります。
- App Service Environment の DNS は、通常、お客様のプライベート カスタム DNS ソリューションを介して管理されます (アプリごとの基本では、手動設定のオーバーライドが使用できます)。 App Service Environment はイングレス/エグレス用のロード バランサーを提供しますが、App Service 自体はホスト ヘッダーでフィルター処理します。 そのため、同じ App Service Environment イングレス エンドポイントに複数のカスタム名を指定できます。 App Service Environment では、ドメインの検証は必要ありません。
注
App Service Environment v3 の Kudu エンドポイントは、
{resourcename}.scm.{asename}.appserviceenvironment.netでのみ使用できます。 App Service Environment v3 DNS とネットワークの詳細については、「 App Service Environment のネットワーク」を参照してください。App Service Environment の場合、顧客はルーティングを所有しており、そのために、一括移行に使用されるリソースを所有しています。 App Service Environment への外部アクセスが有効になっている場合は、通常、レイヤー 7 NVA またはリバース プロキシ (Traffic Manager) または Azure Front Door/Other L7 グローバル負荷分散サービスを使用できます。
サービスのパブリック マルチテナント バージョンの場合、データ プレーン エンドポイントの既定の名前
{resourcename}.azurewebsites.netが、Kudu (SCM) エンドポイントの既定の名前と一緒にプロビジョニングされます。 サービスは既定でパブリック エンドポイントを提供するため、ドメインの所有権を証明するためにバインドを検証する必要があります。 ただし、一度バインドを設定すると、再確認は必要ありません。また、パブリック DNS レコードが App Service エンドポイントを指す必要もありません。カスタム ドメインを使用する場合は、ターゲット アプリに事前にバインドします。 ターゲット アプリでドメインを確認して有効にします。
アイデンティティーズ
新しいターゲット リージョンで、アプリと共にシステム割り当てマネージド ID を再作成する必要があります。 通常、自動的に作成された、EasyAuth で使用される Microsoft Entra ID アプリは、既定でアプリ リソース名に設定されます。
ユーザー割り当てマネージド ID も、リージョン間で移動できません。 ユーザー割り当てマネージド ID をアプリと同じリソース グループに保持するには、それらを新しいリージョンで再作成する必要があります。 詳細については、「Azure リソースのマネージド ID を別のリージョンに再配置する」を参照してください。
再配置されるサービスのマネージド ID には、置き換えられる元の ID と同じアクセス許可を付与します (グループ メンバーシップを含む)。
- ID プロバイダー (IDP) をターゲット リージョンに再配置することを計画します。 Microsoft Entra ID はグローバル サービスですが、一部のソリューションはローカル (またはオンプレミスのダウンストリーム) IDP に依存しています。
- Kudu FTP 資格情報に依存する可能性のあるすべてのリソースを App Service に更新します。
サービス エンドポイント
Azure App Service の仮想ネットワーク サービス エンドポイントは、指定した仮想ネットワークへのアクセスを制限します。 エンドポイントは、IPv4 (インターネット プロトコル バージョン 4) アドレス範囲のリストへのアクセスを制限することもできます。 これらのソース以外から Event Hubs に接続しようとするユーザーは、アクセスを拒否されます。 Event Hubs リソースのソース リージョンでサービス エンドポイントが構成されている場合は、ターゲット リージョンでも同じ手順を実行する必要があります。
Azure App Service をターゲット リージョンに正常に再作成するには、事前に仮想ネットワークとサブネットを作成する必要があります。 これら 2 つのリソースの移動が Azure Resource Mover ツールで実行されている場合、サービス エンドポイントは自動的に構成されません。 そのため、手動で構成する必要があります。これは、Azure portal、Azure CLI、または Azure PowerShell 経由で行うことができます。
移転
App Service リソースを再配置するには、Azure portal またはコードとしてのインフラストラクチャ (IaC) を使用できます。
Azure portal を使用して再配置する
Azure portal を使用して再配置する最大の利点は、この方法がシンプルであることです。 アプリ、計画、コンテンツ、多くの設定は、新しい App Service リソースと計画に複製されます。
App Service Environment (Isolated) レベルの場合は、最初に App Service Environment 全体を別のリージョンに再デプロイする必要があります。その後、新しいリージョンの新しい App Service Environment で個々の計画の再デプロイを開始できます。
Azure portal を使用して App Service リソースを新しいリージョンに再配置するには:
- ソース アプリのバックアップを作成します。
- 新しい App Service プランのアプリを、ターゲット リージョンに作成します。
- ターゲット アプリでバックアップを復元します
- カスタム ドメインを使用する場合は、 を指定して
asuid.し、ターゲット アプリでドメインを有効にします。 - ターゲット アプリ内の他のすべてを、ソース アプリと同じになるように構成し、構成を確認します。
- カスタム ドメインでターゲット アプリをポイントする準備ができたら、ドメイン名を再マッピングします。
IaC を使用して再配置する
既存の継続的インテグレーションと継続的デリバリー/デプロイ (CI/CD) パイプラインが存在する場合、またはこれを作成できる場合は、IaC を使用します。 CI/CD パイプラインを配置すると、デプロイ アクションまたは Kudu zip デプロイを使用して、App Service リソースをターゲット リージョンに作成できます。
SLA 要件では、追加の作業が必要な量を決定する必要があります。 たとえば、これはダウンタイムが限られた再デプロイですか、またはダウンタイムを最小限に抑えてほぼリアルタイムのカットオーバーを必要としますか?
Traffic Manager や Azure Front Door などの外部のグローバル トラフィック ルーティング エッジ サービスを含めることで、外部ユーザーとアプリケーションの一括移行を容易にします。
ヒント
プライベート エンドポイントの背後にある App Services をフェールオーバーするときに、Traffic Manager (ATM) を使用できます。 プライベート エンドポイントは Traffic Manager プローブから到達可能ではありませんが、すべてのエンドポイントが低下している場合、ATM はルーティングを許可します。 詳細については、「Azure Traffic Manager による Azure App Service トラフィックの制御」を参照してください。
検証
再配置が完了したら、推奨されるガイドラインを使用して Azure App Service をテストして検証します。
- Azure App Service がターゲット リージョンに再配置されたら、スモーク テストと統合テストを実行します。 スクリプトを使用して、テストを手動でテストまたは実行できます。 すべての構成と依存リソースが適切にリンクされており、構成されているすべてのデータにアクセスできることを確認します。
- すべての Azure App Service コンポーネントと統合を検証します。
- すべての正式な回帰テストを含め、ターゲット リージョンのデプロイで統合テストを実行します。 統合テストは、通常のビジネス デプロイの周期と、ワークロードに適用できるテスト プロセスに合わせる必要があります。
- 一部のシナリオでは、特に再配置に更新、アプリケーションまたは Azure リソースの変更、使用状況プロファイルの変更が含まれる場合、ロード テストを使用して、新しいワークロードが目的に合っていることを検証します。 ロード テストは、運用と監視の対象範囲を検証する機会でもあります。 たとえば、ロード テストを使用して、必要なインフラストラクチャとアプリケーション ログが正しく生成されていることを検証します。 ロード テストは、確立されたワークロード パフォーマンス ベースラインと照らし合わせて測定する必要があります。
ヒント
App Service の再配置は、可用性とディザスター リカバリーの計画を再評価する機会でもあります。 App Service と App Service Environment (App Service Environment v3) は 可用性ゾーンを サポートしており、可用性ゾーンの構成を使用して構成することをお勧めします。 デプロイ、価格、制限事項の前提条件に留意し、これらをリソース移動計画に組み込みます。 可用性ゾーンと App Service の詳細については、「Azure App Service の信頼性」を参照してください。
クリーンアップ
ソース アプリと App Service プランを削除します。 無料レベルの App Service プランには、アプリが実行されていない場合でも料金が発生します。