インプレース移行機能を使用した App Service Environment v3 への移行

App Service では App Service Environment v1 および v2 の App Service Environment v3 への移行を自動化できます。 さまざまな移行オプションがあります。 移行パスのデシジョン ツリーを確認して、自分のユース ケースに最適なオプションを決定します。 App Service Environment v3 には、以前のバージョンとは異なる特長と機能が備わっています。 予期しないアプリケーションの問題が発生するリスクを軽減するため、移行前に App Service Environment v3 でサポートされている機能を確認してください。

インプレース移行機能は、同じサブネット内の既存の App Service Environment をアップグレードすることで、App Service Environment v3 への移行を自動化します。 この移行オプションは、ネットワーク構成への変更を最小限に抑えて App Service Environment v3 に移行したいお客様に最適です。 また、約 1 時間のアプリケーションのダウンタイムにも対応できる必要があります。 ダウンタイムをサポートできない場合は、サイド マイグレーション機能または手動移行オプションに関する情報を参照してください。

サポートされるシナリオ

現時点では、次のリージョンでの App Service Environment v3 への移行はインプレース移行機能でサポートされていません。

21Vianet が運用する Microsoft Azure

• 中国東部 2
• 中国北部 2

次の App Service Environment 構成は、インプレース移行機能を使用して移行できます。 この表は、既存の App Service Environment に基づいてインプレース移行機能を使用する際の App Service Environment v3 構成を示しています。 サポートされているすべての App Service 環境は、環境がゾーン冗長性をサポートするリージョンにある限り、インプレース移行機能を使用して ゾーン冗長 App Service Environment v3 に移行できます。 移行プロセス中にゾーンの冗長性を構成できます。

新しい App Service Environment v3 でカスタム ドメイン サフィックスを使用する必要があり、現在使用していない場合は、移行が完了したらいつでもカスタム ドメイン サフィックスを構成できます。 詳細については、「App Service Environment のカスタム ドメイン サフィックスを構成する」を参照してください。

Azure portal で App Service Environment に移動し、左側の [設定] の下にある [構成] を選択すると、App Service Environment のバージョンを確認できます。 また、Azure Resource Explorer を使用して、App Service Environment の kind プロパティの値を確認できます。

インプレース移行機能の制限

インプレース移行機能を使用する場合の制限は次のとおりです。

• 新しい App Service Environment v3 は、古い環境に使用されていた既存のサブネット内になります。
• App Service Environment が配置されているリージョンを変更することはできません。
• ELB App Service Environment を、ILB App Service Environment v3 に移行することはできません。またその逆もできません。
• 既存の App Service Environment でカスタム ドメイン サフィックスを使用している場合は、移行プロセス中に App Service Environment v3 のカスタム ドメイン サフィックスを構成する必要があります。
  • カスタム ドメイン サフィックスを使用しない場合は、移行が完了すると削除できます。

App Service Environment v3 は、現在の App Service Environment v1 または v2 で使用できる次の機能をサポートしていません。

• アプリに IP ベースの TLS/SSL バインドを構成する。
• 仮想ネットワーク内の構成済みのカスタム DNS サーバーで特定の名前を解決できない場合、App Service Environment v3 は Azure DNS にフォールバックされません。 この動作が必要な場合は、パブリック DNS へのフォワーダーがあることを確認するか、カスタム DNS サーバーの一覧に Azure DNS を含めます。

インプレース移行機能では、次のシナリオがサポートされていません。 ご使用の App Service Environment がこれらカテゴリの 1 つに該当する場合は、手動移行オプションに関するページを参照してください。

• クラシック仮想ネットワークの App Service Environment v1
• IP SSL アドレスが設定されている ELB App Service Environment v2
• IP SSL アドレスが設定されている ELB App Service Environment v1
• 文字制限を満たしていない名前を持つ App Service Environment。 ドメイン サフィックスを含む名前全体を、64 文字以下にする必要があります。 たとえば、ILB の my-ase-name.appserviceenvironment.net と ELB の my-ase-name.p.azurewebsites.net は 64 文字以内にする必要があります。 文字制限を満たしていない場合は、手動で移行する必要があります。 App Service Environment 名の具体的な文字制限は次のとおりです。
  • ILB App Service Environment の名前の文字制限: 36 文字
  • ELB App Service Environment の名前の文字制限: 42 文字

App Service プラットフォームで、インプレース移行のサポートを確認するために、App Service Environment を見直します。 シナリオがすべての検証チェックに合格しない場合、現時点では、インプレース移行機能を使用して移行することはできません。 環境が異常な状態や中断状態にある場合、必要な更新を行うまで移行することができません。

トラブルシューティング

ご使用の App Service Environment が検証検査に合格しないか、正しくない順序で移行ステップを試みた場合、次のいずれかのエラー メッセージが表示される可能性があります。

インプレース移行機能を使用した移行プロセスの概要

インプレース移行は一連の手順で構成されており、これらの手順は順序に従って実行する必要があります。 キー ポイントは、ステップのサブセットで示されます。 これらの手順で何が起きるのか、環境とアプリにどのような影響があるのかを理解することが重要です。 次の情報を確認し、移行の準備ができたら、ステップ バイ ステップ ガイドの説明に従います。

App Service Environment のインプレース移行機能を使って移行がサポートされていることを検証する

プラットフォームにより、インプレース移行機能を使って App Service Environment を移行できることが検証されます。 App Service Environment がすべての検証チェックに合格しない場合、現時点では、インプレース移行機能を使って移行することはできません。 検証失敗の考えられる原因の詳細については、トラブルシューティングのセクションを参照してください。 環境が異常な状態や中断状態にある場合、必要な更新を行うまで移行することができません。 インプレース移行機能を使って移行できない場合は、手動移行オプションに関する記事を参照してください。

この検証では、App Service Environment が移行に必要な最小限のビルド上にあるかどうかも確認されます。 このビルドは、プラットフォームの定期的なアップグレード/メンテナンス サイクルでデプロイされる標準ビルドよりも新しい場合があります。 最新のバグ修正と機能強化を確実に使用できるように、最小限のビルドは定期的に更新されます。 App Service Environment が最小限のビルド上にない場合は、手動でアップグレードを開始する必要があります。 このアップグレードは App Service Environment には影響しない標準プロセスですが、アップグレードの進行中に App Service Environment をスケーリングすることや変更することはできません。 アップグレードが完了するまでは移行できません。 アップグレードが完了するまでに 8 時間から 12 時間、環境の規模によってはそれ以上かかる場合があります。 移行に特定の期間を計画する場合は、計画した移行時間の 24 時間から 48 時間前に検証チェックを実行して、アップグレードが必要な場合に時間を確保する必要があります。

新しい App Service Environment v3 用の IP アドレスを生成する

プラットフォームによって、新しい受信 IP (ELB App Service Environment を移行する場合) と新しい送信 IP アドレスが作成されます。 これらの IP が作成されている間、既存の App Service Environment でのアクティビティは中断されませんが、既存の環境のスケーリングや変更はできません。 このプロセスの完了には約 15 分かかります。

完了すると、App Service Environment v3 で今後使用される新しい IP が提供されます。 新しい IP は既存の環境には影響しません。 既存の環境で使用されている IP は、移行ステップで既存の環境がシャットダウンされるまで、引き続き使用されます。

依存リソースを新しい IP で更新する

新しい IP が作成されると、インターネット パブリック アドレスへの新しい既定の送信が作成されます。 移行の準備として、外部ファイアウォール、DNS ルーティング、ネットワーク セキュリティ グループ、およびこれらの IP に依存するその他のリソースを調整できます。 ELB App Service Environment の場合、新しい受信 IP アドレスも作成されます。これは、Traffic Manager や Azure Front Door などのサービスを使用して新しいエンドポイントを設定するときに使用できます。 新しい App Service Environment v3 に関連付けられている IP アドレスの変更の影響を受けるリソースをすべて更新する作業は、ユーザーが行う必要があります。 必要な更新がすべて完了するまでは、次のステップに進まないでください。 この手順は、App Service Environment v3 に移行する際にAzure Load Balancer のポート変更でポート 80 を使用するようになった場合などに、インバウンドおよびアウトバウンド ネットワークの依存関係の変更を確認するのにもお勧めです。

App Service Environment サブネットを委任する

App Service Environment v3 では、それが含まれているサブネットで、Microsoft.Web/hostingEnvironments の単一の委任が必要です。 App Service Environment のサブネットが委任されていない、または別のリソースに委任されている場合、移行は成功しません。

インスタンス サイズの変更の確認

App Service プランは、移行の一環として Isolated から対応する Isolated v2 レベルに変換されます。 たとえば、I2 は I2v2 に変換されます。 Isolated v2 レベルでは対応するインスタンス サイズあたりのメモリと CPU が多くなることから、移行後にアプリがオーバープロビジョニングになる可能性があります。 移行完了後に、必要に応じて環境をスケーリングできます。 詳細については、SKU の詳細に関するセクションを参照してください。

リソースにロックがないことを確認する

仮想ネットワーク ロックによって、移行中のプラットフォーム操作がブロックされます。 仮想ネットワークにロックがある場合は、移行する前にそれらのロックを削除する必要があります。 移行が完了したら、必要に応じてロックを再度追加することができます。 ロックは、サブスクリプション、リソース グループ、リソースの 3 つの異なるスコープに存在することができます。 親スコープでロックを適用すると、そのスコープ内のすべてのリソースは同じロックを継承します。 サブスクリプション、リソース グループ、またはリソースのスコープでロックが適用されている場合は、移行前に削除する必要があります。 ロックとロックの継承の詳細については、「リソースをロックしてインフラストラクチャを保護する」を参照してください。

移行をブロックする Azure ポリシーがないことを確認する

Azure Policy を使用して、リソースの作成と特定のプリンシパルへの変更を拒否できます。 App Service Environment の作成またはサブネットの変更をブロックするポリシーがある場合は、移行する前に削除する必要があります。 移行が完了したら、必要に応じてポリシーを再度追加できます。 Azure Policy の詳細については、Azure Policy の概要に関するページを参照してください。

App Service Environment v3 構成を選択する

App Service Environment v3 は、それをサポートするリージョン内の可用性ゾーン全体にデプロイできます。 このアーキテクチャは、ゾーン冗長と呼ばれます。 ゾーン冗長性は、App Service Environment の作成時にのみ構成できます。 新しい App Service Environment v3 をゾーン冗長にする場合は、移行プロセス中に構成を有効にします。 インプレース移行機能を使用して移行する App Service Environment では、App Service Environment v3 のゾーン冗長性をサポートするリージョンを使用している限り、ゾーン冗長として構成できます。 既存の環境がゾーン冗長性をサポートしていないリージョン内にある場合、構成オプションは無効になり、構成できません。 インプレース移行機能では、リージョンの変更はサポートされていません。 別のリージョンを使用する場合は、手動移行オプションのいずれかを使用します。

既存の App Service Environment でカスタム ドメイン サフィックスを使用している場合は、新しい App Service Environment v3 用にカスタム ドメイン サフィックスを構成するように求められます。 カスタム ドメイン名、マネージド ID、証明書を提供する必要があります。 要件、詳細な手順、ベスト プラクティスなど、App Service Environment v3 カスタム ドメイン サフィックスの詳細については、「App Service Environment のカスタム ドメイン サフィックスを構成する」を参照してください。 使用しなくなった場合でも、新しい環境のカスタム ドメイン サフィックスを構成する必要があります。 移行が完了すると、必要に応じてカスタム ドメイン サフィックス構成を削除できます。

移行にカスタム ドメイン サフィックスを含めた場合、App Service Environment v3 では、App Service Environment v1 または v2 の場合と同様に、カスタム ドメインは、ポータルの [概要] ページの [要点] セクションに表示されません。 代わりに、App Service Environment v3 の場合は、[カスタム ドメイン サフィックス] ページに移動して、カスタム ドメイン サフィックスが正しく構成されていることを確認できます。 また、App Service Environment v2 では、カスタム ドメイン サフィックスがある場合、既定のホスト名にはカスタム ドメイン サフィックスが含まれており、APP-NAME.internal.contoso.com 形式になります。 App Service Environment v3 では、既定のホスト名は常に既定のドメイン サフィックスを使用し、APP-NAME.ASE-NAME.appserviceenvironment.net の形式になります。 この違いは、App Service Environment v3 では、ユーザーがカスタム ドメイン サフィックスを追加したときに既定のドメイン サフィックスが維持されるためです。 App Service Environment v2 では、ドメイン サフィックスは 1 つだけです。

App Service Environment v3 への移行

前の手順を完了後、できるだけ早く移行を続行する必要があります。

App Service Environment v2 から v3 への移行には、3 - 6 時間のサービス期間が必要です。 v1 から v3 への移行の環境サイズに応じて、最大 6 時間のサービス期間が必要です。 まれなケースですが、サービス チームによる手動の介入が必要な場合は、サービス時間帯が延長される可能性があります。 移行中は、スケーリングと環境の構成がブロックされ、次のイベントが発生します。

• 既存の App Service Environment がシャットダウンされ、新しい App Service Environment v3 に置き換えられます。
• App Service Environment 内のすべての App Service プランが、Isolated から Isolated v2 レベルに変換されます。
• App Service Environment 上のアプリがすべて一時的にダウンする。 この期間中に、約 1 時間のダウンタイムを想定しておく必要があります。
  • ダウンタイムをサポートできない場合は、サイド バイ サイドの移行機能または移行の代替手段に関する情報を参照してください。
• App Service Environment で使用されているパブリック アドレスは、IP 生成手順の際に生成された IP に変更されます。

移行プロセス中は、次の状態が表示されます。

IP 生成手順と同様に、このプロセスの実行中も、App Service Environment のスケーリングと変更はできず、アプリのデプロイもできません。 移行が完了すると、古い App Service Environment にあったアプリは、App Service Environment v3 で実行されます。

インプレース移行機能を使用する

前提条件

App Service Environment v3 への移行がアプリケーションに及ぼす影響について理解していることを確認してください。 移行プロセスを確認して、プロセスのタイムラインと、ユーザーによる操作が必要になるタイミングを理解してください。 また、FAQ も確認してください。ここには、疑問に対する回答が示されている可能性があります。

お使いの仮想ネットワーク、リソース グループ、リソース、またはサブスクリプションがロックされていないことを確認します。 ロックは、移行中にプラットフォームの操作をブロックします。

サブネットの変更や Azure App Service リソースの作成など、移行に必要なアクションをブロックしている Azure ポリシーがないことを確認します。 リソースの変更や作成をブロックするポリシーにより、移行が停止したり失敗したりする可能性があります。

移行中はスケーリングがブロックされるため、移行を開始する前に、環境を目的のサイズにスケーリングする必要があります。 移行後に環境をスケーリングする必要がある場合は、移行が完了したらそれを行うことができます。 自動スケーリングを有効にしている場合に、移行の開始前にスケーリング イベントが発生した場合は、スケーリング イベントが完了するまで移行はブロックされます。 この問題を回避するには、移行を開始する前に自動スケーリングを無効にする必要があります。

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"

az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true,
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

価格

App Service Environment の移行は無料です。 インプレース移行機能を使用すると、移行プロセス中にシャットダウンするとすぐに、以前の App Service Environment の課金が停止します。 デプロイされるとすぐに、新しい App Service Environment v3 に対して課金が開始されます。 App Service Environment v3 の価格の詳細については、価格の詳細に関するセクションを参照してください。

以前のバージョンから App Service Environment v3 に移行する場合、毎月のコストを削減できる可能性があるシナリオを検討する必要があります。 コストをさらに削減するために、予約と節約計画 を検討してください。 コスト削減の機会については、「App Service Environment v3 へのアップグレード後のコスト削減の機会」を参照してください。

App Service プランをスケールダウンする

App Service Environment v3 で使用できる App Service プラン SKU は、Isolated v2 (Iv2) レベルで実行されます。 コアの数と RAM の量は、Isolated レベルと比較すると、対応するレベルごとに実質的に 2 倍になります。 移行すると、App Service プランは対応するレベルに変換されます。 たとえば、I2 インスタンスは I2v2 に変換されます。 I2 には 2 つのコアと 7 GB RAM が搭載されていますが、I2v2 には 4 つのコアと 16 GB の RAM が搭載されています。 容量要件が変わらないと予想される場合は、オーバープロビジョニング状態になり、使用していないコンピューティングとメモリに対して料金が支払うことになります。 このシナリオでは、I2v2 インスタンスを I1v2 にスケールダウンし、結果的に、以前と同じようなコア数と RAM にできます。

よく寄せられる質問

• 使用している App Service Environment の移行が現在サポートされていない場合は、どうしたらよいですか?
  現時点では、インプレース移行機能を使用して移行することはできません。 ご使用の環境がサポートされていない場合でも、すぐに移行したい場合には、手動移行オプションに関するページを参照してください。
• 自分に適した移行オプションを選択するにはどうすればよいですか?
  移行パスのデシジョン ツリーを確認して、自分のユース ケースに最適なオプションを決定します。
• インプレース移行機能を使用する必要があるかどうかを確認するにはどうすればよいですか?
  インプレース移行機能は、ネットワーク構成に最小限の変更を加えて App Service Environment v3 に移行したいと考えていて、1 時間程度のアプリケーション ダウンタイムをサポートできるお客様に最適です。 ダウンタイムをサポートできない場合は、サイド マイグレーション機能または手動移行オプションに関する情報を参照してください。 インプレース移行機能は、既存の環境と同じサブネットに App Service Environment v3 を作成し、同じネットワーク インフラストラクチャを使用します。 これらの特定の IP に依存関係がある場合は、受信および送信 IP アドレスの変更を考慮することが必要な場合があります。
• 移行中にダウンタイムが発生しますか?
  はい。移行手順の間は 3~6 時間のサービス時間帯中に約 1 時間のダウンタイムが予想されるため、それに応じて計画しておいてください。 インプレース移行機能を使用して移行中にトラフィックを転送できる別の App Service Environment がある場合は、アプリケーションのダウンタイムをなくすことができます。 別の App Service Environment がなく、ダウンタイムをサポートできない場合は、サイド バイ サイド移行機能または手動移行オプションに関する情報を参照してください。
• 移行の完了後に新しい App Service Environment でアプリを実行するために、アプリに何らかの操作を行う必要がありますか?
  いいえ。古い環境で実行されていたアプリはすべて、新しい環境に自動的に移行され、以前と同様に実行されます。 ユーザー入力は必要ありません。
• App Service Environment にカスタム ドメイン サフィックスが設定されている場合はどうなりますか?
  インプレース移行機能では、この移行シナリオがサポートされています。
• App Service Environment がゾーン固定されている場合はどうなりますか?
  ゾーン固定 App Service Environment v2 が移行機能を使用した移行のサポート シナリオになりました。 App Service Environment v3 では、ゾーンのピン留めをサポートしていません。 App Service Environment v3 に移行するとき、ゾーン冗長性構成をオプションで選択できます。
• App Service Environmentに IP SSL アドレスがある場合はどうすればよいですか? IP SSL は App Service Environment v3 ではサポートされていません。 移行機能またはいずれかの手動オプションを使用して、移行する前にすべての IP SSL バインディングを削除する必要があります。 インプレース移行機能を使用する場合は、すべての IP SSL バインディングを削除すると、その検証検査に合格して自動の移行に進むことができます。
• App Service Environment のどのプロパティが変更されますか?
  App Service Environment v3 になったら、以前のバージョンと比較して、機能と機能の相違点を確認してください。 ILB App Service Environment の場合は、同じ ILB IP アドレスを保持します。 インターネットに接続している App Service Environment の場合は、パブリック IP アドレスと送信 IP アドレスが変更されます。 ELB App Service Environment では、以前は受信と送信の両方に 1 つの IP が使用されていました。 App Service Environment v3 では、これらは別々になります。 詳細については、App Service Environment v3 ネットワークに関するページを参照してください。 App Service Environment バージョンの完全な比較については、「App Service Environment バージョンの比較」を参照してください。
• 移行に失敗した場合、または移行中に予期しない問題が発生した場合はどうなりますか?
  予期しない問題が発生した場合は、サポート チームを利用できます。 運用環境を移行する前に、開発環境を移行することで移行プロセスについて学習し、ワークロードに与える影響を確認してください。
• 古い App Service Environment はどうなりますか?
  インプレース移行機能を使用して App Service Environment を移行すると決定した場合は、古い環境がシャットダウンされて削除され、すべてのアプリが新しい環境に移行されます。 古い環境にはもうアクセスできません。 古い環境へのロールバックはできません。
• App Service Environment v1/v2 リソースは 2024 年 8 月 31 日を過ぎるとどうなりますか?
  2024 年 8 月 31 日の後、App Service Environment v3 に移行していない場合、App Service Environment v1/v2s とそこにデプロイされているアプリは使用できなくなります。 App Service Environment v1/v2 は、2024 年 8 月 31 日に廃止される予定の Cloud Services (クラシック) アーキテクチャで実行される App Service スケール ユニットでホストされています。 このため、App Service Environment v1/v2 は、その日付の後は使用できなくなります。 アプリが引き続き実行されるように App Service Environment v3 に移行するか、あるいは保持する必要があるリソースまたはデータをすべて保存またはバックアップしてください。

次の手順