サイドバイサイド移行機能を使用した App Service Environment v3 への移行

[アーティクル]
07/25/2024

Note

この記事で説明する移行機能は、App Service Environment v2 から App Service Environment v3 へのサイドバイサイド (異なるサブネット) の自動移行に使用されます。 30 日の猶予期間を要求していない場合は、猶予期間の概要に関する記事を確認した後、Azure portal にアクセスし、各 App Service Environment の [移行] ブレードに移動して、猶予期間を要求してください。

インプレース移行機能の情報をお探しの場合は、「インプレース移行機能を使用した App Service Environment v3 への移行」を参照してください。手動移行オプションの情報をお探しの場合は、手動移行のオプションに関する記事をご覧ください。適切な移行オプションの決定については、「移行パスのデシジョンツリー」をご覧ください。 App Service Environment v3 の詳細については、App Service Environment v3 の概要に関する記事を参照してください。

サイドバイサイド移行には、インプレース移行と比較して追加の課題が伴います。この 2 つの選択肢のどちらを使用するかを決定する必要があるお客様には、手順も複雑さも少ないため、インプレース移行を使用することをお勧めします。サイドバイサイド移行を使用する場合は、「サイドバイサイド移行機能を使用した移行時によくある問題の原因」のセクションを確認し、一般的な落とし穴を回避してください。

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

サイドバイサイド移行機能により、App Service Environment v3 への移行が自動化されます。サイドバイサイド移行機能を使用すると、すべてのアプリを別のサブネットに含む新しい App Service Environment v3 が作成されます。既存の App Service Environment は、移行プロセスの最後に削除を開始するまでは削除されません。この移行オプションは、ダウンタイムゼロで App Service Environment v3 に移行したいと考え、かつ新しい環境で別のサブネットの使用をサポートできるお客様に最適です。同じサブネットを使用する必要があり、またアプリケーションのダウンタイムの約 1 時間をサポートできる場合は、インプレース移行機能を参照してください。自分のペースで移行できる手動移行オプションについては、手動移行オプションを参照してください。

重要

このチュートリアルで説明されているすべての手順を完了できない場合は、ダウンタイムが発生します。たとえば、すべての依存リソースを新しい IP アドレスで更新しない場合や、新しいサブネットへの/からのアクセスを許可しない場合 (カスタムドメインサフィックスキーコンテナーの場合など) は、それに対処するまでのダウンタイムが発生します。

プロセスのリハーサルを行い想定外の問題が発生しないことを確認するために、運用環境の移行前にまずは開発環境でこの機能を使用することをお勧めします。この記事または機能に関連するフィードバックがありましたら、このページの下部にあるボタンを使用してご提供ください。

サポートされるシナリオ

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

Azure Public

アラブ首長国連邦中部

Azure Government

US DoD Central
US DoD East
US Gov アリゾナ
US Gov テキサス
US Gov バージニア州

21Vianet が運用する Microsoft Azure

中国東部 2
中国北部 2

次の App Service Environment 構成は、サイドバイサイド移行機能を使用して移行できます。この表は、既存の App Service Environment に基づいてサイドバイサイド移行機能を使用する際の App Service Environment v3 構成を示しています。

構成	App Service Environment v3 構成
App Service Environment v2 で内部ロードバランサー (ILB)	ILB App Service Environment v3
外部 (パブリック IP を使用した ELB/インターネット接続) App Service Environment v2	ELB App Service Environment v3
カスタムドメインサフィックスが設定されている ILB App Service Environment v2	カスタムドメインサフィックスが設定されている ILB App Service Environment v3

App Service Environment v3 はゾーン冗長として展開できます。ゾーン冗長性は、App Service Environment v3 がゾーン冗長をサポートするリージョンにある場合に限り有効にすることができます。

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

サイドバイサイド移行機能の制限事項

サイドバイサイド移行機能を使用する場合の制限事項は次のとおりです。

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

現行の App Service Environment v1 または v2 で利用している可能性のある以下の機能は、App Service Environment v3 でサポートされません。

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

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

App Service Environment v1
- Azure portal で App Service Environment に移動し、左側の [設定] の下にある [構成] を選択すると、App Service Environment のバージョンを確認できます。また、Azure Resource Explorer を使用して、App Service Environment の kind プロパティの値を確認できます。
- App Service Environment v1 をお持ちの場合は、インプレース移行機能または、手動移行オプションのうちのいずれかを使用して移行できます。
IP SSL アドレスが設定されている ELB App Service Environment v2
ゾーン固定 App Service Environment v2
文字制限を満たしていない名前を持つ 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 v3 では IP SSL はサポートされていません。 IP SSL を使用する場合は、App Service Environment v3 に移行する前に、すべての IP SSL バインディングを削除する必要があります。すべての IP SSL バインディングが削除されると、移行機能によって環境がサポートされます。

トラブルシューティング

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

エラーメッセージ	説明	推奨
移行は ARM VNET の ASE でのみ呼び出すことができます。この ASE はクラシック VNET 内にあります。	クラシック仮想ネットワークの App Service Environment では、サイドバイサイド移行機能を使用して移行することはできません。	手動移行のオプションのいずれかを使用して移行します。
ASEv3 の移行はまだ準備ができていません。	基になるインフラストラクチャは、App Service Environment v3 をサポートする準備ができていません。	すぐに移行する場合は、手動移行のオプションのいずれかを使用して移行します。あるいは、ご利用のリージョンでサイドバイサイド移行機能が使用できるようになるまでお待ちください。
この ASE のゾーン冗長を有効にすることはできません。	App Service Environment が存在するリージョンでは、ゾーン冗長がサポートされていません。	ゾーンの冗長性を有効にする必要がある場合は、手動の移行オプションのいずれかを使用して、ゾーン冗長をサポートするリージョンに移行してください。
現時点では、このカスタム DNS サフィックス ASE で Migrate を呼び出すことはできません。	カスタムドメインサフィックスの移行がブロックされています。	サポートケースを開き、サポートに問い合わせて問題を解決します。
現時点では、ゾーン冗長 ASE 移行を呼び出すことはできません。	ゾーン冗長 App Service Environment の移行がブロックされています。	サポートケースを開き、サポートに問い合わせて問題を解決します。
ゾーン固定の ASEv2 で移行を呼び出すことはできません。	現時点では、ゾーン固定の App Service Environment v2 を、サイドバイサイド移行機能を使用して移行することはできません。	すぐに移行する場合は、手動移行のオプションのいずれかを使用して移行します。
既存の移行を元に戻す操作が進行中です。後でもう一度やり直してください。	以前の移行の試行が元に戻されています。	進行中の元に戻す操作が完了するまで待ってから、もう一度移行を開始してください。
Properties.VirtualNetwork.Id にはサブネットリソース ID が含まれている必要があります。	App Service Environment v3 の配置するための新しいサブネットを指定せずに移行しようとすると、エラーが表示されます。	ガイダンスに従い、手順を完了して、App Service Environment v3 に使用するサブネットを特定してください。
ダウンタイムなし移行の現在のフェーズ `<previous phase>` から `<requested phase>` に移ることができません。	このエラーは、移行の手順を正しくない順序で実行しようとすると表示されます。	移行の手順は必ず順番に実行してください。
ハイブリッド状態の ASE で元に戻す操作を開始できませんでした。後でもう一度やり直してください。	このエラーは、移行を元に戻そうとしても問題が発生した場合に表示されます。このエラーは、古い環境または新しい環境には影響しません。	サポートケースを開き、サポートに問い合わせて問題を解決します。
この ASE はダウンタイムなしでは移行できません。	このエラーは、App Service Environment v1 でサイドバイサイド移行機能を使用しようとすると表示されます。	サイドバイサイド移行機能では、App Service Environment v1 はサポートされていません。インプレース移行機能または、手動移行オプションのうちのいずれかを使用して移行してください。
移行は、このサブスクリプションでは利用できません。	この App Service Environment を移行するには、サポートに依頼する必要があります。	サポートケースを開き、サポートに問い合わせて問題を解決します。
事前移行中に作成された IP アドレスがゾーン冗長ではないため、ゾーン冗長移行を呼び出すことができません。	このエラーは、IP 生成手順中に生成された IP がゾーン冗長として作成されなかったにも関わらず、ユーザーがゾーン冗長移行を試みた場合に表示されます。プラットフォームは、バックエンドの回復性を確保するために、すべての IP ゾーンを冗長化しようとします。	ゾーン冗長を有効にする必要がある場合は、サポートケースを開いてください。エンジニアは移行を元に戻し、IP の作成を再度試みることができるようにします。それ以外の場合は、ゾーン冗長を有効にせずに移行できます。
いずれかのサイトで IP SSL が有効になっている場合に、移行を呼び出すことができません。	IP SSL が有効になっているサイトが存在する App Service Environment は、サイドバイサイド移行機能を使用して移行することはできません。	App Service Environment 内のすべてのアプリから IP SSL を削除して、移行機能を有効にします。
同じサブネット内での移行はできません。	このエラーは、App Service Environment v3 の配置に現在の環境と同じサブネットを指定すると表示されます。	App Service Environment v3 には別のサブネットを指定する必要があります。同じサブネットを使用する必要がある場合は、インプレース移行機能を使用して移行してください。
サブスクリプションに App Service Environment が多すぎます。さらに作成する場合は、事前に一部を削除してください。	App Service Environment のサブスクリプションのクォータがいっぱいになりました。	不要な環境を削除するか、サポートに連絡してオプションを確認します。
アクティブなアップグレードが完了するまで、この ASE で移行を呼び出すことはできません。	プラットフォームのアップグレード中に App Service Environment を移行することはできません。 Azure portal からアップグレードの優先順位を設定できます。アップグレードには、App Service Environment のサイズ (インスタンス/コアの数) に応じて 8 から 12 時間、またはそれ以上かかります。	アップグレードが完了するまで待ってから移行します。
進行中の App Service Environment 管理操作。	App Service Environment は管理操作中です。これらの操作には、デプロイやアップグレードなどのアクティビティを含めることができます。移行は、これらの操作が完了するまでブロックされます。	これらの操作を完了したら、移行できます。
InternalLoadBalancingMode は現在サポートされていません。	現時点では、InternalLoadBalancingMode が特定の値に設定された App Service Environment は、移行機能を使用して移行することができません。 Microsoft チームは、InternalLoadBalancingMode を手動で変更する必要があります。	サポートケースを開き、サポートに問い合わせて問題を解決します。 InternalLoadBalancingMode の更新を依頼します。
IP アドレスを生成する前に、完全な移行を呼び出すことができません。	このエラーは、移行前の手順を完了する前に移行しようとすると表示されます。	移行を試みる前に、移行前の手順がすべて完了していることを確認してください。移行に関する詳細なガイドを参照してください。
カスタム DNS サフィックスが設定されているものの、AseV3 カスタム DNS サフィックス構成が設定されていない Ase では、完全な移行を実行することはできません。	既存の App Service Environment ではカスタムドメインサフィックスが使用されています。移行プロセス中に App Service Environment v3 のカスタムドメインサフィックスを構成する必要があります。	カスタムドメインサフィックスの構成。カスタムドメインサフィックスを使用しない場合は、移行が完了すると削除できます。

サイドバイサイド移行機能を使用した移行プロセスの概要

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

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 のサブネットを選択して準備する

プラットフォームは、既存の App Service Environment とは異なるサブネットに新しい App Service Environment v3 を作成します。次の要件を満たすサブネットを選択する必要があります。

サブネットは、既存の App Service Environment と同じ仮想ネットワーク、したがって同じリージョン内に存在する必要があります。
- 仮想ネットワークに使用可能なサブネットがない場合は、作成する必要があります。新しいサブネットを作成するには、仮想ネットワークのアドレス空間を増やす必要がある場合があります。詳細については、「仮想ネットワークの作成」をご覧ください。
サブネットは、既存の App Service Environment が存在するサブネットと双方向で通信できる必要があります。サブネット間の通信を妨げるネットワークセキュリティグループやその他のネットワーク構成がないことを確認します。
サブネットには Microsoft.Web/hostingEnvironments の委任が 1 つ必要です。
サブネットには、新しい App Service Environment v3 をサポートするのに十分な数の使用可能 IP アドレスが必要です。必要な IP アドレスの数は、新しい App Service Environment v3 に使用したいインスタンスの数によって異なります。詳細については、App Service Environment v3 ネットワークに関するページを参照してください。
サブネットにロックを適用することはできません。ロックがある場合は、移行前に解除する必要があります。移行が完了したら、必要に応じてロックを再度追加することができます。ロックとロックの継承の詳細については、「リソースをロックしてインフラストラクチャを保護する」を参照してください。
移行や関連するアクションをブロックする Azure ポリシーが一切存在しないようにしてください。 App Service Environment の作成やサブネットの変更をブロックするポリシーがある場合は、移行前に削除する必要があります。移行が完了したら、必要に応じてポリシーを再度追加できます。 Azure Policy の詳細については、Azure Policy の概要に関するページを参照してください。

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

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

完了すると、App Service Environment v3 で今後使用される新しいアウトバウンド IP が作成されます。新しい IP は既存の環境には影響しません。

新しいインバウンド IP アドレスは、移行が完了した後、新しい App Service Environment v3 に顧客のトラフィックをリダイレクトするように DNS を変更する前に取得できます。移行手順中に作成される App Service Environment v3 リソースには依存関係があるため、プロセスのこの時点ではインバウンド IP を取得できません。新しい App Service Environment v3 にトラフィックをリダイレクトする前に、新しいインバウンド IP に依存するすべてのリソースを更新できます。

依存リソースを新しいアウトバウンド IP で更新する

実際の移行を開始する前に、新しいアウトバウンド IP が作成され、提供されます。移行を完了する前に、外部ファイアウォール、DNS ルーティング、ネットワークセキュリティグループ、およびこれらの IP に依存するその他のリソースを調整できるように、インターネットパブリックアドレスへの新しい既定のアウトバウンド IP が提供されます。新しい App Service Environment v3 に関連付けられている IP アドレスの変更の影響を受けるリソースをすべて更新する作業は、ユーザーが行う必要があります。必要な更新がすべて完了するまでは、次のステップに進まないでください。アウトバウンド IP に依存関係があり、必要なすべての更新を実行できない場合は、移行手順の最中または後にダウンタイムが発生する可能性があります。これは、移行が開始すると、トラフィックが引き続き App Service Environment v2 フロントエンドに送信されても、基になるコンピューティングに新しい App Service Environment v3 が新しいサブネットで使用されるためです。

この手順は、App Service Environment v3 に移行する際にAzure Load Balancer のポート変更でポート 80 を使用するようになった場合などに、インバウンドおよびアウトバウンドネットワークの依存関係の変更を確認するのにもお勧めです。

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

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

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

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

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

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

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

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

カスタムドメインサフィックスを追加する (省略可能)

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

移行にカスタムドメインサフィックスを含めた場合、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 への移行

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

移行中にアプリケーションのダウンタイムはありませんが、IP 生成手順と同様に、このプロセス中にスケーリングしたり、既存の App Service Environment を変更したり、アプリをデプロイしたりすることはできません。

重要

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

この手順では、新しい App Service Environment v3 のゾーン冗長性を有効にするかどうかも決定します。ゾーン冗長性は、App Service Environment v3 がゾーン冗長をサポートするリージョンにある場合に限り有効にすることができます。

サイドバイサイド移行では、App Service Environment v2 から v3 への移行に 3 - 6 時間のサービス期間が必要です。移行中は、スケーリングと環境の構成がブロックされ、次のイベントが発生します。

選択したサブネットに新しい App Service Environment v3 が作成されます。
新しい App Service プランは、対応する Isolated v2 レベルの新しい App Service Environment v3 に作成されます。
アプリは、新しい App Service Environment v3 上に作成されます。
アプリの基になるコンピューティング/ワーカーは、新しい App Service Environment v3 に移動されます。つまり、アプリは現在 App Service Environment v3 で実行されています。ただし、App Service Environment v2 フロントエンドは、既定では引き続き実行され、トラフィックを処理します。古い受信 IP アドレスは引き続き使用されますが、新しい送信 IP が使用されています。さらに、新しい App Service Environment v3 フロントエンドが作成され、トラフィックを処理する準備が整っています。
- ILB App Service Environment の場合、プライベート DNS ゾーンを新しい受信 IP アドレスで更新するまで、App Service Environment v3 フロントエンドは使用されません。
- ELB App Service Environment の場合、移行プロセスは、移行の最後の手順を完了するまでトラフィックは App Service Environment v3 フロントエンドにリダイレクトされません。

この手順が完了しても、アプリケーショントラフィックは引き続き以前の App Service Environment v2 フロントエンドと、それに割り当てられたインバウンド IP に送信されます。ただし、アプリは実際には新しい App Service Environment v3 のワーカーで実行されています。

Note

既知のバグにより、Web ジョブがハイブリッドデプロイの手順中に開始されない場合があります。 Web ジョブを使用すると、このバグによってアプリの問題/ダウンタイムが発生する可能性があります。この問題に関する質問や懸念事項がある場合、サポートケースをオープンします。

新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

Traffic Manager や Azure Front Door などのサービスで新しいエンドポイントを設定してプライベート DNS ゾーンのいずれかを更新できるように、新しいインバウンド IP アドレスが指定されます。これらの変更を反映させるまで、次の手順に進まないでください。依存リソースを新しいインバウンド IP で更新しないと、ダウンタイムが発生します。新しい App Service Environment v3 に関連する IP アドレス変更の影響を受けるリソースをすべて更新する作業は、ユーザーが行う必要があります。必要な更新がすべて完了するまでは、次のステップに進まないでください。

顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

最後の手順では、新しい App Service Environment v3 フロントエンドにトラフィックをリダイレクトし、移行を完了します。この手順を実行する前に、新しい App Service Environment v3 を確認し、必要なテストを全て実行して、意図したとおりに機能していることを検証する必要があります。既定では、トラフィックは App Service Environment v2 のフロントエンドに移動します。 ILB App Service Environment v3 を使用している場合、プライベート DNS ゾーンを新しい受信 IP アドレスで更新することで、App Service Environment v3 フロントエンドをテストできます。 ELB App Service Environment v3 を使用している場合、テストのプロセスは特定のネットワーク構成に依存します。 ELB 環境をテストする簡単な方法の 1 つは、新しい App Service Environment v3 の受信 IP アドレスを使用するようにホストファイルを更新することです。個々のアプリにカスタムドメインが割り当てられている場合は、その DNS を更新して新しい受信 IP をポイントするようにすることもできます。この変更をテストすることで、移行の最終段階で古い App Service Environment が削除される前に、App Service Environment v3 を完全に検証することができます。

トラフィックをリダイレクトする準備ができたら、移行の最後の手順を完了できます。この手順では、新しい App Service Environment v3 のロードバランサー IP アドレスと移行中に作成したフロントエンドを指すように内部/プラットフォーム DNS レコードを更新します。変更は数分で有効になります。新しい受信 IP アドレスを指すように DNS レコードを更新することは、お客様の責任において行ってください。問題やアプリケーションのダウンタイムが発生した場合は、キャッシュと TTL の設定を確認します。この手順では、古い App Service Environment もシャットダウンし、削除します。そして、新しい App Service Environment v3 が運用環境になります。

重要

このプラットフォームでは、ダウンタイムなしの移行エクスペリエンスが保証されます。ただし、DNS の設定によっては、DNS の変更手順中にダウンタイムが発生する可能性があります。これは、TTL とキャッシュの設定に関連する問題が原因である可能性があり、その理由は、DNS 変更後も、トラフィックが古い App Service Environment に送信される可能性があるためです。 DNS 設定を確認し、TTL が低く、DNS プロバイダーが高速伝達をサポートしていることを確認する必要があります。 TTL が高い場合は、DNS の変更手順中にダウンタイムが発生する可能性があります。

Note

できるだけ早くこの手順を完了することが重要です。 App Service Environment がハイブリッド状態の場合、プラットフォームのアップグレードおよびセキュリティパッチを受け取ることができないため、不安定性やセキュリティの脅威に対して脆弱になります。

この手順を完了するには 14 日かかります。 14 日経過後、プラットフォームは自動的に移行を完了し、以前の環境を削除します。さらに時間が必要な場合は、サポートケースを開いてオプションについて話し合うことができますから始めます。

新しい App Service Environment v3 で問題が検出された場合は、顧客のトラフィックをリダイレクトするためのコマンドを実行しないでください。このコマンドは、App Service Environment v2 の削除も開始します。問題が見つかった場合は、サポートにお問い合わせください。

サイドバイサイド移行機能を使用する

前提条件

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

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

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

App Service Environment v3 は仮想ネットワーク内の別のサブネット内に作成されるため、App Service Environment v3 のサブネット要件を満たすサブネットがお使いの仮想ネットワーク内で利用できることを確認する必要があります。既存の App Service Environment があるサブネットと通信できるサブネットを選ぶ必要があります。 2 つのサブネット間の通信をブロックするものがないことを確認します。利用できるサブネットがない場合は、移行する前に作成する必要があります。新しいサブネットを作成するには、仮想ネットワークのアドレス空間の拡大が必要な場合があります。詳しくは、仮想ネットワークとサブネットの作成に関する記事をご覧ください。

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

Azure REST API を呼び出すので、以下で説明する手順を書かれているとおりの順序で行ってください。これらの API 呼び出しを行うには、Azure CLI を使用することをお勧めします。その他の方法に関する情報については、「Azure REST API リファレンス」を参照してください。

このガイドに従うには、Azure CLI をインストールするか、Azure Cloud Shell を使用して Bash シェルを使用します。

Note

このガイドに記載されているコマンドを実行するには、Bash シェルを使用することをお勧めします。コマンドは、PowerShell の規則やエスケープ文字と互換性がない場合があります。

重要

移行時に、Azure portal に App Service Environment とアプリについて誤った情報が表示される場合があります。 Azure portal の移行エクスペリエンスではサイドバイサイド移行機能を使用できないため、アクセスしないでください。 Azure CLI を使用して移行の状態を確認することをお勧めします。移行またはアプリの状態についてご質問がある場合は、サポートにお問い合わせください。

1. 新しい App Service Environment v3 用のサブネットを選択する

App Service Environment v3 内で、App Service Environment v3 のサブネット要件を満たすサブネットを選びます。選んだサブネットの名前を後でわかるようにしておきます。このサブネットは、既存の App Service Environment が含まれるサブネットとは異なっている必要があります。

2. App Service Environment ID を取得する

以下のコマンドを実行して、App Service Environment ID を取得し、それを環境変数として保存します。名前とリソースグループのプレースホルダーは、移行したい App Service Environment の値に置き換えます。仮想ネットワークと App Service Environment が同じリソースグループ内にある場合、ASE_RG と VNET_RG は同じです。

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)

3. 移行がサポートされていることを検証する

次のコマンドにより、お使いの App Service Environment が移行をサポートしているかどうかを確認します。このコマンドは、App Service Environment が移行でサポートされているビルドバージョンにあることも検証します。 App Service Environment がサポート対象のビルドバージョン上にない場合は、手動でアップグレードを開始する必要があります。移行前のアップグレードの詳細については、「App Service Environment のサイドバイサイド移行機能を使用して移行がサポートされていることを検証する」を参照してください。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

エラーがない場合は、移行がサポートされているので、次の手順に進むことができます。

App Service Environment をサポートされているビルドバージョンにアップグレードするためにアップグレードを開始する必要がある場合は、環境のサイズに応じて 8 ~ 12 時間以上かかる場合は、次のコマンドを実行します。検証手順に失敗し、App Service Environment をアップグレードするように指示された場合にのみ、このコマンドを実行してください。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. 新しい App Service Environment v3 用のアウトバウンド IP アドレスを生成する

次のコマンドを実行して、新しいアウトバウンド IP アドレスを作成します。この手順の所要時間は約 15 分です。この期間は、既存の App Service Environment をスケーリングしたり、変更を加えたりしないでください。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

次のコマンドを実行して、このステップの状態を確認します。

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

ステップが進行中の場合は、Migrating という状態が表示されます。状態が Ready になったら、次のコマンドを実行して、新しいアウトバウンド IP を確認します。新しい IP がすぐに表示されない場合は、数分待ってから再度実行してみてください。

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5.依存リソースを新しいアウトバウンド IP で更新する

新しいアウトバウンド IP を使用して、リソースまたはネットワークコンポーネントをすべて更新し、移行の開始後に新しい環境が意図したとおりに動作するようにします。必要な更新を行うのはユーザーの責任です。移行手順中に App Service Environment v3 が作成されると、新しい送信 IP が使用されます。たとえば、カスタムドメインサフィックスと Azure Key Vault があり、ファイアウォールでアクセス制限を管理している場合は、Azure Key Vault のファイアウォールを更新して、新しい送信 IP または新しいサブネット全体のみを許可する必要があります。

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

App Service Environment v3 では、それが含まれているサブネットで、Microsoft.Web/hostingEnvironments の単一の委任が必要です。以前のバージョンでは、この委任は不要でした。サブネットが適切に委任されていることを確認し、必要に応じて移行前に委任を更新する必要があります。委任を更新するには、次のコマンドを実行するか、Azure portal でサブネットに移動します。

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

7.仮想ネットワークにロックがないことを確認する

仮想ネットワークロックによって、移行中のプラットフォーム操作がブロックされます。仮想ネットワークにロックがある場合は、移行する前にそれらのロックを削除する必要があります。必要に応じて、移行が完了した後にロックを追加し直すことができます。

次のコマンドを使用して、仮想ネットワークに何らかのロックがあるかどうかを確認します。

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

サブスクリプションまたはリソースグループにロックがあるかどうかを確認するための関連コマンドについては、「ロックに関する Azure CLI リファレンス」を参照してください。

8.構成を準備する

既存の App Service Environment がカスタムドメインサフィックスを使用している場合は、移行プロセス時に新しい App Service Environment v3 リソースのカスタムドメインサフィックスを構成する必要があります。カスタムドメインサフィックスを構成せずに、現在これを使用している場合、移行は失敗します。要件、ステップバイステップの手順、ベストプラクティスなど、App Service Environment v3 カスタムドメインサフィックスの詳細については、「App Service Environment のカスタムドメインサフィックス」を参照してください。

Note

カスタムドメインサフィックスを構成する場合は、Azure キーコンテナーに対するネットワークアクセス許可を追加するときに、必ず App Service Environment v3 の新しいサブネットからのアクセスをキーコンテナーで許可してください。プライベートエンドポイントを使用してキーコンテナーにアクセスする場合は、新しいサブネットでプライベートアクセスを正しく構成していることを確かめてください。移行前にこのアクセス権を正しく設定できなかった場合、ダウンタイムが発生します。

既存の環境がゾーン冗長をサポートしているリージョンにある場合は、新しい App Service Environment v3 ゾーン冗長を作成できます。ゾーン冗長は、zoneRedundant プロパティを true に設定して構成できます。ゾーン冗長は省略可能な構成です。この構成は、新しい App Service Environment v3 の作成時にのみ設定でき、後で削除することはできません。

前に選択したサブネットの識別を含め、これらの構成を設定するには、実際のシナリオに基づいて以下の詳細を使用して parameters.json という名前のファイルを作成します。新しい App Service Environment v3 用に選んだ新しいサブネットを必ず使ってください。この機能を移行に適用しない場合は、カスタムドメインサフィックスのプロパティは含めないでください。 zoneRedundant プロパティの値に注意を払い、各自の回復性の要件に従ってそれを設定します。

カスタムドメインサフィックスなしで移行する場合は、次のコードを使います。

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

カスタムドメインサフィックスの構成にユーザー割り当てマネージド ID を使っている場合は、次のコードを使います。

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

カスタムドメインサフィックスの構成にシステム割り当てマネージド ID を使っている場合は、次のコードを使います。

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9.App Service Environment v3 に移行して状態を確認する

上記のすべての手順を完了したら、移行を開始できます。移行の影響を理解していることを確認してください。

このステップには 3 から 6 時間かかります。その間、前の手順に従った場合、アプリケーションのダウンタイムはありません。この手順では、既存の App Service Environment のスケーリング、デプロイ、変更はブロックされます。

Note

次のコマンドを実行して移行を始めます。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

移行の状態を確認するには、次のコマンドを実行します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

MigrationPendingDnsChange という状態が表示されたら、移行は完了しており、App Service Environment v3 リソースが使用できます。アプリは現在、新しい環境と古い環境で実行されています。

次のコマンドを実行して、新しい環境の詳細を取得します。

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

重要

移行時や MigrationPendingDnsChange ステップ時に、Azure portal に App Service Environment とアプリについて誤った情報が表示されます。 Azure CLI を使用して移行の状態を確認します。移行またはアプリの状態についてご質問がある場合は、サポートにお問い合わせください。

Note

移行にカスタムドメインサフィックスが含まれている場合、既知のバグにより、移行が完了するとカスタムドメインサフィックス構成がデグレードされたと表示される場合があります。 App Service Environment は引き続き期待どおりに機能するはずです。デグレードした状態は 6 - 8 時間以内に解決するはずです。 8 時間後に構成がデグレードしている場合、またはカスタムドメインサフィックスが機能していない場合は、サポートにお問い合わせください。

デグレードされたカスタムドメインサフィックス構成のサンプルのスクリーンショット。

10。新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

移行プロセスでは、この段階で 2 セットの App Service Environment フロントエンドがあり、両方のセットでアプリケーショントラフィックを処理できます。 DNS は変更されていないため、既定では、トラフィックは古い App Service Environment フロントエンドに送信されます。新しい App Service Environment v3 用の新しい IP インバウンドアドレスを使うように、依存リソースを更新する必要があります。内部に接続している (ILB) App Service Environment の場合は、新しいインバウンド IP アドレスを指すようにプライベート DNS ゾーンを更新する必要があります。

新しい App Service Environment v3 の新しい受信 IP アドレスを取得するには、お使いの App Service Environment ロードバランサーの種類に対応する、次のコマンドを実行します。必要な更新を行うのはユーザーの責任です。

ILB App Service Environment の場合、次のコマンドを実行してプライベート受信 IP アドレスを取得します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

ELB App Service Environment の場合、次のコマンドを実行してパブリック受信 IP アドレスを取得します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

重要

移行にカスタムドメインサフィックスが含まれている場合、App Service Environment v3 の既定のホスト名は、App Service Environment v2 のとは異なる動作となります。 App Service Environment v3 の場合は、既定のホスト名は常に既定のドメインサフィックスを使用し、APP-NAME.ASE-NAME.appserviceenvironment.net の形式になります。アプリのホスト名を使用するすべての依存リソース (App Gateway など) をレビューし、この動作を考慮して更新されていることを確認します。異なるバージョン間の App Service Environment 機能の違いの詳細については、「App Service Environment のバージョン比較」を参照してください。

11.顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

このステップでは、新しい App Service Environment v3 をテストして検証できます。

重要

この手順を完了するには 14 日かかります。 14 日経過後、プラットフォームは自動的に移行を完了し、以前の環境を削除します。さらに時間が必要な場合は、サポートケースを開いてオプションについて話し合うことができます。

アプリが予期したとおりに動作していることを確認したら、次のコマンドを実行して移行を完了できます。このコマンドは、古い環境も削除します。

問題が見つかった場合、またはこの時点で移行をそれ以上続けないことにした場合は、サポートに連絡して、どうしたら良いか相談してください。 DNS 変更コマンドによって移行が完了するため、このコマンドを実行しないでください。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

次のコマンドを実行して、このステップの状態を確認します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

この手順では、CompletingMigration の状態が表示されます。 MigrationCompleted の状態になると、トラフィックリダイレクトの手順が実行されて移行が完了します。

サイドバイサイド移行機能を使用した移行時によくある問題の原因

サイドバイサイド移行機能を使用して移行する場合に発生するよくある問題の原因の例を次に示します。移行プロセス中または移行後にダウンタイムやサービスの停止が発生しないように、これらの領域を確認する必要があります。

Azure Key Vault は、新しい送信 IP/サブネットからのトラフィックを許可する必要があります。
2 つのサブネットはお互い双方向に通信できるようにする必要があります。顧客は、以前のサブネットから新しいサブネットへのトラフィックは許可しますが、新しいサブネットから以前のサブネットへのトラフィックを許可することを忘れがちです。
App Gateway は新しい IP アドレスで更新される必要があります。
DNS レコードは新しい IP アドレスで更新される必要があります。
アプリケーションに IP アドレスをハードコーディングしている場合は、新しい IP アドレスに更新する必要があります。
ルートテーブルは新しいルートに更新する必要があります。

価格

App Service Environment の移行は無料です。ただし、移行プロセスを開始すると、App Service Environment v2 と新しい App Service Environment v3 の両方に対して課金されます。古い環境が削除される最後の移行手順を完了すると、古い App Service Environment v2 の課金が停止されます。超過料金の蓄積を防ぐために、できるだけ早く検証を完了する必要があります。 App Service Environment v3 の価格の詳細については、価格の詳細に関するセクションを参照してください。

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

Note

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

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 に移行したいが、アプリケーションのダウンタイムをサポートできないお客様に最適です。新しいサブネットが新しい環境に使用されるため、新しい IP を含め、ネットワークに関する考慮事項に注意する必要があります。ダウンタイムをサポートできる場合は、インプレース移行機能を参照してください。その結果、構成の変更が最小限に抑えられます。または、手動の移行オプションを参照してください。インプレース移行機能は、既存の環境と同じサブネットに App Service Environment v3 を作成し、同じネットワークインフラストラクチャを使用します。
移行中にダウンタイムが発生しますか?
このプラットフォームでは、サイドバイサイド移行プロセス中にダウンタイムがないことが保証されます。ただし、DNS の設定によっては、DNS の変更手順中にダウンタイムが発生する可能性があります。これは、TTL とキャッシュの設定に関連する問題が原因である可能性があり、その理由は、DNS 変更後も、トラフィックが古い App Service Environment に送信される可能性があるためです。 DNS 設定を確認し、TTL が低く、DNS プロバイダーが高速伝達をサポートしていることを確認する必要があります。
移行の完了後に新しい App Service Environment でアプリを実行するために、アプリに何らかの操作を行う必要がありますか?
いいえ。古い環境で実行されていたアプリはすべて、新しい環境に自動的に移行され、以前と同様に実行されます。ユーザー入力は必要ありません。
App Service Environment にカスタムドメインサフィックスが設定されている場合はどうなりますか?
サイドバイサイド移行機能では、この移行シナリオはサポートされています。
App Service Environment がゾーン固定されている場合はどうなりますか?
サイドバイサイド移行機能では、現時点ではこの移行シナリオはサポートされていません。ゾーン固定 App Service Environment があり、すぐに移行したい場合は、手動移行オプションを参照してください。
App Service Environment に IP SSL アドレスがある場合はどうすればよいですか?
IP SSL は App Service Environment v3 ではサポートされていません。移行機能またはいずれかの手動オプションを使用して、移行する前にすべての IP SSL バインディングを削除する必要があります。サイドバイサイド移行機能を使用する場合は、すべての IP SSL バインディングを削除すれば検証検査に合格し、自動移行を進めることができます。
App Service Environment のどのプロパティが変更されますか?
App Service Environment v3 になったら、以前のバージョンと比較して、機能と機能の相違点を確認してください。サイドバイサイド移行機能を使用すると、インバウンドおよびアウトバウンド 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 に移行するか、あるいは保持する必要があるリソースまたはデータをすべて保存またはバックアップしてください。

次の手順

App Service Environment v3 ネットワーク

App Service Environment v3 の使用

カスタムドメインサフィックス

次の方法で共有

サイド バイ サイド移行機能を使用した App Service Environment v3 への移行

サポートされるシナリオ

Azure Public

Azure Government

21Vianet が運用する Microsoft Azure

サイド バイ サイド移行機能の制限事項

トラブルシューティング

サイド バイ サイド移行機能を使用した移行プロセスの概要

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

新しい App Service Environment v3 のサブネットを選択して準備する

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

依存リソースを新しいアウトバウンド IP で更新する

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

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

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

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

カスタム ドメイン サフィックスを追加する (省略可能)

App Service Environment v3 への移行

新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

サイドバイサイド移行機能を使用する

前提条件

1. 新しい App Service Environment v3 用のサブネットを選択する

2. App Service Environment ID を取得する

3. 移行がサポートされていることを検証する

4. 新しい App Service Environment v3 用のアウトバウンド IP アドレスを生成する

5.依存リソースを新しいアウトバウンド IP で更新する

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

7.仮想ネットワークにロックがないことを確認する

8.構成を準備する

9.App Service Environment v3 に移行して状態を確認する

10。新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

11.顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

サイド バイ サイド移行機能を使用した移行時によくある問題の原因

価格

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

よく寄せられる質問

次の手順

フィードバック

その他のリソース

サイドバイサイド移行機能を使用した App Service Environment v3 への移行

サイドバイサイド移行機能の制限事項

サイドバイサイド移行機能を使用した移行プロセスの概要

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

カスタムドメインサフィックスを追加する (省略可能)

サイドバイサイド移行機能を使用した移行時によくある問題の原因