Azure App Services を別のリージョンに再配置する
この記事では、App Service リソースを別の Azure リージョンに移動する方法について説明します。
既存の Azure リソースを、1 つのリージョンから他のリージョンに移動する理由には、さまざまが考えられます。 以下を行うことができます。
- 新しい 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 サービスとの統合が含まれています。 これらのリソースをリージョン間で移動する方法については、それぞれのサービスのドキュメントを参照してください。
プラン
このセクションは、次の領域の計画チェックリストです。
- 状態、ストレージ、ダウンストリームの依存関係
- 証明書
- 構成
- VNet 接続 / カスタム名 / DNS
- ID
- サービス エンドポイント
状態、ストレージ、ダウンストリームの依存関係
App Service アプリがステートフルかステートレスかを判断します。 App Service Apps はステートレスであり、
%HOME%\siteドライブ上のファイルは、任意の一時ファイルでデプロイされたアプリケーションを実行するために必要なファイルのみにすることをお勧めしますが、その場合でも、仮想ドライブにランタイム アプリケーションの状態を格納することはできます%HOME%\site。 アプリケーションがアプリの共有ストレージ パスに状態を書き込む場合は、リソースの移動中にその状態を管理する方法を計画してください。ヒント
Kudu を使用すると、ポータル アクセスと共に、
%HOME%\siteディレクトリのファイルを読み取り/書き込みできるファイル アクセス API (仮想ファイル システム (VFS)) を提供できます。 詳細については、「Kudu Wiki」をご覧ください。アプリケーション コードで内部キャッシュと状態を確認します。
セッション アフィニティ設定を無効にします。 可能であれば、セッション アフィニティ設定を無効にすることをお勧めします。 セッション アフィニティを無効にすると、水平方向のスケールアウトの負荷分散が向上します。内部状態は、特に、ダウンタイムがゼロであるのが要件の場合、ワークロードの一括移行のための計画に影響を与える可能性があります。 可能であれば、アプリケーションの状態をリファクターして、移動の準備でアプリケーションをステートレスにすると有益な場合があります。
データベース接続文字列を分析します。 データベース接続文字列は、アプリの設定で確認できます。 ただし、アプリケーションに付属する構成ファイルでハードコーディングまたは管理することもできます。 ワークロードを移動するためのより高いレベルの計画の一環として、データの移行やレプリケーションを分析して計画します。 通信頻度が高い、または待機時間が重要な意味を持つアプリケーションの場合、ターゲット リージョン内のアプリケーションにとって、ソース リージョン内のデータ ソースに戻ってアクセスすることは効率的ではありません。
外部キャッシュ (Redis など) を分析します。 アプリケーション キャッシュは、できるだけアプリケーションの近くにデプロイする必要があります。 キャッシュの設定方法、有効期限または削除のためのポリシー、コールド キャッシュが一括移行後にワークロードにアクセスするために最初のユーザーに与える可能性がある影響を分析します。
API (またはアプリケーション) の依存関係を分析して計画 ターゲット リージョン内のアプリが、まだソース リージョン内にある依存関係を使用する場合、リージョン間の通信の効率は大幅に低下します。 ワークロードの再配置の一環として、すべてのダウンストリーム依存関係を再配置することをお勧めします。 ただし、*オンプレミス* リソースは例外であり、特にターゲット リージョンに地理的に近いリソースは除きます (復帰シナリオの場合と同様)。
Azure Container Registry は、カスタム コンテナー イメージに対して実行するように構成された App Service のダウンストリーム (ランタイム) 依存関係にできます。 Azure Container Registry がアプリ自体と同じリージョンにある方が合理的です。 ターゲット取得リージョンの新しい ACR に必要なイメージをアップロードすることを検討してください。 または、ソース リージョン内にイメージを保持する予定がある場合、geo レプリケーション機能の使用を検討してください。
リージョン サービスを分析して計画します。 Application Insights と Log Analytics データはリージョン別のサービスです。 ターゲット リージョンに新しい Application Insights と Log Analytics ストレージを作成することを検討してください。 App Insights の場合、新しいリソースは、Azure App Configuration の変更の一環として更新する必要がある接続文字列にも影響します。
証明書
App Service 証明書リソースは、新しいリソース グループまたはサブスクリプションに移動できますが、リージョン間では移動できません。 エクスポート可能な証明書を、新しいリージョンのアプリまたは Key Vault にインポートすることもできます。 このエクスポートとインポートのプロセスは、リージョン間の移動と同じです。
サービスの再配置を計画するときに考慮する必要がある証明書の種類には、さまざまなものがあります。
| 証明書タイプ | Exportable | Comments |
|---|---|---|
| App Service マネージド | いいえ | これらの証明書を新しいリージョンで再作成します。 |
| Azure Key Vault マネージド | はい | これらの証明書は、Key Vault からエクスポートした後、新しいリージョンの Key Vault にインポートできます。 |
| 秘密キー (自己管理型) | はい | Azure の外部で取得した証明書は、App Service からエクスポートした後、新しいリージョンの新しいアプリまたは Key Vault にインポートできます。 |
| 公開キー | いいえ | アプリの証明書の中には、公開キーのみがあって秘密を含まないものがあります。これらは、他のセキュリティ保護エンドポイントへのアクセスに使用されます。 必要な公開キー証明書ファイルを取得し、新しいリージョン内のアプリにインポートします。 |
さらに考慮すべき点は次のとおりです。
App Service アプリの SSL 接続が特定のアプリ指定 IP にバインドされているアプリ割り当てアドレスは、サード パーティのネットワークから App Service への許可リスト呼び出しに使用できます。 たとえば、ネットワーク/IT 管理者は、オンプレミス ネットワークまたは VNet からの発信呼び出しをロックダウンして、固定の既知のアドレスを使用する必要がある場合があります。 そのように、アプリ割り当てアドレス機能が使用されている場合は、アプリの呼び出し元の内部、外部、サード パーティなどのアップストリーム ファイアウォール規則を確認し、新しいアドレスを通知する必要があります。 ファイアウォール規則には、パートナーや既知の顧客などの内部、外部、またはサード パーティを指定できます。
アップストリーム ネットワーク仮想アプライアンス (NVA) またはリバース プロキシを検討します。 ホスト ヘッダーまたは SSL 終端を書き換える場合は、NVA 構成の変更が必要になる場合があります。
Note
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 ストアまたは同様のストアを確認してください。
- ディスク ファイルの構成を確認します。これは、アプリケーション設定でオーバーライドされる場合とオーバーライドされない場合があります。
VNet 接続 / カスタム名 / DNS
App Service Environment は、VNet によって挿入されるシングル テナント サービスです。 App Service Environment ネットワークは、"プライベート エンドポイント" または "リージョン VNet 統合" のいずれかまたは両方を必要とするマルチテナント App Service とは異なります。 その他のオプションとして、従来の P2S VPN ベースの VNet 統合やハイブリッド接続 (Azure Relay サービス) などがあります。
Note
ASEv3 ネットワークは簡略化されています。Azure の管理トラフィックと App Service Environment 独自のダウンストリーム依存関係は、顧客の仮想ネットワークから見えないため、顧客がすべてのトラフィックに強制トンネルを使用している場合や、ネットワーク仮想アプライアンス/ファイアウォール経由で送信トラフィックのサブセットを送信するときに必要な構成が大幅に簡素化されます。
ハイブリッド接続 (Azure Relay) はリージョン別です。 ハイブリッド接続が使用されていて、Azure Relay 名前空間を別のリージョンに移動できる場合は、ハイブリッド接続を再デプロイし (ターゲット リソースのデプロイ時にハイブリッド接続が新しいリージョンにセットアップされていることを確認)、ハイブリッド接続マネージャーに再リンクする方が簡単です。 ハイブリッド接続マネージャーの場所は慎重に検討する必要があります。
ウォーム スタンバイ リージョンの戦略に従います。 リソースの再配置の前に、コア ネットワークと接続、ハブ ネットワーク、ドメイン コントローラー、DNS、VPN、Express Route などが存在し、テストされていることを確認します。
アップストリームまたはダウンストリームのネットワーク ACL と構成を検証します。 たとえば、アプリ トラフィックのみを許可リストに含める外部ダウンストリーム サービスについて考えます。 マルチテナント App Service の新しいアプリケーション計画に再配置することは、送信 IP アドレスの変更でもあります。
ほとんどの場合、ターゲット リージョンの VNet に一意のアドレス空間があることを保証するのが最も有益です。 一意のアドレス空間を使用すると、データのレプリケートなど、必要に応じた VNet 接続が容易になります。 したがって、これらのシナリオでは、変更することが暗黙的な要件となります。
- プライベート DNS
- IP アドレスによってリソースを参照するハード コーディングまたは外部構成 (ホスト名なし)
- ネットワーク セキュリティ グループとファイアウォールの構成を含むネットワーク ACL (ここではオンプレミスの NVA への影響も考慮する)
- ルーティング規則、ユーザー定義ルート テーブル
また、既存の DevOps デプロイ リソースを転送する場合は、リージョン固有の IP 範囲/サービス タグを含む構成を確認してください。
Azure ドメインと Azure DNS Private Zones 用に Azure に転送するように構成された、顧客がデプロイしたプライベート DNS に対しては、変更を少なくする必要があります。 ただし、プライベート エンドポイントはリソース FQDN に基づいており、多くの場合、これはリソース名 (ターゲット リージョンでは異なると予想される) であるため、構成で参照される FQDN が適宜更新されるように、構成は必ずクロス チェックしてください。
プライベート エンドポイントを使用する場合、ターゲット リージョンで再作成します。 リージョン VNet 統合にも同じことが当てはまります。
App Service Environment の DNS は、通常、顧客のプライベート カスタム DNS ソリューションを介して管理されます (アプリごとの基本では、手動設定のオーバーライドが行えます)。 App Service Environment はイングレス/エグレス用のロード バランサーを提供しますが、App Service 自体はホスト ヘッダーでフィルター処理します。 そのため、同じ App Service Environment イングレス エンドポイントに複数のカスタム名を指定できます。 App Service Environment では、ドメインの検証は必要ありません。
Note
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
新しいターゲット リージョンで、アプリと共にシステム割り当てマネージド 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 を正常に再作成するには、VNet とサブネットを事前に作成する必要があります。 これら 2 つのリソースの移動が Azure Resource Mover ツールで実行される場合、サービス エンドポイントは自動的に構成されません。 そのため、手動で構成する必要があります。これは、Azure portal、Azure CLI、または Azure PowerShell 経由で行うことができます。
Relocate
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 プランを削除します。 非 Free レベルの App Service プランでは、アプリが実行されていない場合でも料金が発生します。