App Service Environment の自動移行によって発生する問題を防ぎ、解決する

重要

App Service Environment v1 と v2 は廃止され、サポートされなくなりました。 App Service Environment v1 または v2 をご利用の場合は、App Service Environment v3 に移行する必要があります。 詳細については、「App Service Environment v3 にアップグレードする」を参照してください。

自動移行は、Microsoft によって開始される移行です。 Microsoft は 2024 年 9 月 1 日以降、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、リソースとそれに関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。

ご利用の App Service Environment v1 または v2 が App Service Environment v3 に自動移行された場合は、アプリまたはサービスで問題が発生する可能性があります。 この記事では、これらの問題に対処する方法に関するガイダンスを提供します。

概要

2024 年 9 月 1 日以降、特に明記されていない限り、すべての App Service Environment v1 と v2 は、いつでも App Service Environment v3 に自動的に移行 (自動移行) される対象となります。 このプラットフォームは自動移行を開始します。これは、App Service Environment がサポートされているプラットフォームで実行されるようにするために必要です。

Note

自動移行と削除はバッチで行われます。 ご利用の App Service Environment がまだ自動移行されていない場合は、いつでも自動移行または削除の対象となります。 App Service Environment が予期せず自動移行または削除されないようにする唯一の方法は、30 日間の猶予期間を要求することです。

自動移行は、インプレース移行機能を使用して実行されます。 この移行プロセス中に、約 1 時間のダウンタイムがあります。 App Service Environment の受信 IP アドレスと送信 IP アドレスは、移行プロセス中に変更される可能性があります。 これらの IP アドレスに依存している場合、ダウンタイムが長くなる可能性があります。 また、App Service Environment v3 でサポートされていない機能を使用している場合にも、ダウンタイムが長くなる可能性があります。

猶予期間

移行を完了するためにさらに時間が必要な場合は、1 回限りの 30 日間の猶予期間を設定できます。 猶予期間中は、App Service Environment が自動移行または削除されることはありません。 猶予期間が終了すると、App Service Environment の自動移行が試行されます。 自動移行を実行できない場合、リソースとそれに関連するアプリ データは削除されます。

この猶予期間を受け取るには、Azure portal に移動し、App Service Environment の [移行] ページにアクセスします。 複数の App Service Environment がある場合は、移行に時間が必要な環境ごとの猶予期間に同意して受け取る必要があります。

猶予期間を受け取ると、[移行] ページの上部にあるバナーに猶予期間の終了日が表示されます。 更新されたバナーを表示するには、ページの更新が必要な場合があります。 バナーの日付が更新されるまでに最大 5 分かかることがあります。

さらにサポートが必要な場合、または質問がある場合は、Azure portal の [移行] ページの [サポート チケットを開く] オプションを使用して Azure サポートにお問い合わせください。 サポート リクエストを開く前に、移行に時間を要する環境ごとの猶予期間に同意して受け取る必要があります。 同意と猶予期間により、サポート リクエストの処理中に環境が自動移行されなくなります。

自動移行の制限事項

自動移行は、インプレース移行機能を使用して実行されます。 自動移行には、インプレース移行の制限と同様に、次の制限が適用されます。

• 新しい App Service Environment v3 は、古い環境に使用されていた既存のサブネット内に配置されます。
• 新しい App Service Environment v3 は、古い環境と同じリージョン内に配置されます。
• 新しい App Service Environment v3 は、古い環境と同じリソース グループ内に配置されます。
• すべてのリソースは、同じ名前とリソース ID を保持します。
• App Service Environment v3 では、IP ベースの TLS/SSL バインドはサポートされていません。 IP ベースの TLS/SSL バインドがある場合は、移行が完了したらそれらを削除する必要があります。 バインドを削除するまで、アプリは機能しません。
• クラシック仮想ネットワーク内の App Service Environment v1 は移行ではサポートされていません。 クラシック仮想ネットワークに App Service Environment v1 がある場合は、手動で移行を実行する必要があります。 30 日間の猶予期間を要求しない場合、ご利用の App Service Environment はいつでも削除の対象となります。
• インプレース移行機能は、中国東部 2 と中国北部 2 では使用できません。 App Service Environment v3 はこれらのリージョンでは使用できないため、この機能はサポートされていません。 そのため、これらのリージョンの App Service Environment では、自動移行を実行できません。 これらのリージョンに App Service Environment がある場合は、サポートされているいずれかのリージョン (中国東部 3、中国北部 3 など) に手動で移行する必要があります。 30 日間の猶予期間を要求しない場合、ご利用の App Service Environment はいつでも削除の対象となります。

インプレース移行の詳細と、自動移行中に実行されるプロセスの詳細については、「インプレース移行機能を使用した App Service Environment v3 への移行」を参照してください。

自動移行の対象外

自動移行の対象外となる可能性があるシナリオは 2 つあります。 最初のシナリオは、現在の環境が App Service Environment v3 をサポートしていないリージョンにある場合です。 もう 1 つのシナリオは、クラシック仮想ネットワークに App Service Environment v1 がある場合です。 自動移行の対象外で、自動移行できない場合は、その理由を示すメッセージがポータルに表示されます。 手動で移行する必要があります。 30 日間の猶予期間を要求しない場合、ご利用の App Service Environment はいつでも削除の対象となります。

場合によっては、自動移行が一時的にブロックされることがありますが、障害となっている問題を解決して自動移行を有効にすることができます。 たとえば、App Service Environment にリソース ロックがある場合は、リソース ロックを削除して自動移行を有効にすることができます。 リソース ロック、Azure Policy、またはネットワーク構成によってブロックされる自動移行は、自動的に中断されます。 App Service Environment の一時停止を解除する必要がある場合は、サポート チケットを開きます。

自動移行の対象外の場合は、ポータルに次のエラーが表示されることがあります。

エラー	推奨
App Service Environment v1 はクラシック仮想ネットワークにあります。 クラシック仮想ネットワークでは、App Service Environment v3 はサポートされていません。	手動で移行する必要があります。
移行を妨げている App Service Environment、仮想ネットワーク、リソース グループ、サブスクリプションにリソース ロックがあります。	自動移行を有効にするには、リソース ロックを削除します。
移行を妨げている Azure Policy があります。	自動移行を有効にするには、App Service Environment または環境が存在する仮想ネットワークのリソースの変更または削除をブロックする Azure Policy を削除します。
App Service Environment は自動移行をサポートしていないリージョンにあります。	手動で移行する必要があります。

App Service Environment が一時停止された場合の対応

App Service Environment が一時停止された場合は、3 つのオプションがあります。

一時停止を解除して自己移行

自分で移行する場合は、[移行] ページのオプションを使用してサポート チケットを開き、App Service Environment の一時停止を解除できるかどうかを確認します。 お客様の環境の一時停止を確実に解除できる保証はありません。

App Service Environment v3 として再開/一時停止解除

移行を迅速化する場合は、ご利用の環境を App Service Environment v3 として再開または一時停止解除できます。 App Service Environment を v3 として再開するには、Azure portal に移動し、App Service Environment の [移行] ページにアクセスします。 App Service Environment v3 として環境を再開するには、[今すぐ移行] ボタンを選択します。 このボタンを選択すると、自動移行に使用されるのと同じプロセスが開始されます。 制限事項、ダウンタイム、およびその他の考慮事項は、自動移行の場合と同じです。 複数の App Service Environment がある場合は、一時停止されている環境ごとに再開する必要があります。

App Service Environment の消去

App Service Environment が不要になった場合は、次の CLI コマンドを使用して環境を削除できます。 サブスクリプション ID、環境名、リソース グループのプレースホルダーを、削除する App Service Environment の値に置き換えます。 Azure CLI は、環境を削除するための唯一の方法です。 Azure CLI をこれまでに使用していない場合は、Azure CLI を インストールするか Azure Cloud Shell を使用して Bash シェルを使用します。 環境を削除すると、関連付けられているアプリと App Service プランも削除されます。 この操作は、元に戻すことはできません。

az rest --method delete --url "https://management.azure.com/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Web/hostingEnvironments/<ASE-NAME>?api-version=2020-12-01" --url-parameters forceDelete=true --verbose

自動移行の影響を制限する機能

自動移行の影響を制限するために、自動移行機能に次の機能を実装しました。

送信 IP アドレスの保持

以前は、App Service Environment の送信 IP アドレスは、移行プロセス中に常に変更されていました。 今回より、移行プロセス中に App Service Environment の送信 IP アドレスが保持される場合があります。 App Service Environment v1/v2 パブリック IP アドレスは保持される可能性があり、App Service Environment v3 の送信 IP アドレスとして使用されます。 送信 IP アドレスを保持できる保証はありません。 ただし、App Service Environment v3 には 2 つの送信 IP アドレスがあります。 カスタム ドメイン サフィックス構成があり、パブリック インターネット経由で Azure Key Vault に接続する場合は、引き続き他の新しい送信 IP アドレスを考慮する必要があります。

内部ロード バランサー (ILB) の App Service Environment の移行では、受信 IP は常に保持されます。 この機能は、自動移行中も変わりません。

外部ロード バランサー (ELB) の App Service Environment の移行では、受信 IP は引き続き変更されます。 この変更は、A レコードを使用して App Service Environment の受信 IP アドレスをポイントする場合に影響する可能性があります。 A レコードを使用する場合は、移行プロセスが完了した後で、A レコードを更新して新しい受信 IP アドレスをポイントする必要があります。 CNAME レコードを使用する場合は、DNS を変更する必要はほとんどありません。 受信 IP アドレスに他の依存関係がある場合は、それに応じて更新する必要があります。

App Service Environment v2 カスタム ドメイン サフィックス構成の互換性

App Service Environment v3 のカスタム ドメイン サフィックスは、App Service Environment v2 とは異なる方法で実装されます。 App Service Environment v2 では、証明書は App Service Environment に直接アップロードされます。 さらに、非ワイルドカード証明書を使用できます。 App Service Environment v3 では、証明書を Azure Key Vault に格納し、App Service Environment がキー コンテナーにアクセスできる必要があります。 また、非ワイルドカード証明書は許可されません。

自動移行の影響を減らすために、App Service Environment v2 カスタム ドメイン サフィックス構成の制限付き互換モードを App Service Environment v3 に実装しました。 App Service Environment v2 にカスタム ドメイン サフィックス構成がある場合、その構成は App Service Environment v3 に移行されます。 証明書は App Service Environment v3 にアップロードされ、アップロードされた証明書を使用するように構成が更新されます。 このプロセスは一時的な措置として実行され、現在の証明書の有効期限が切れるまで有効です。 移行プロセスが完了し、証明書の有効期限が切れる前に Azure Key Vault を使用するように構成を更新する必要があります。 構成を更新しない場合、証明書の有効期限が切れると、カスタム ドメイン サフィックスは機能しません。 詳細については、「App Service Environment v3 のカスタム ドメイン サフィックス」を参照してください。

重要

カスタム ドメイン サフィックス互換モードの場合でも、カスタム ドメイン サフィックスの構成が想定どおりに動作しない場合があります。 自動移行後にカスタム ドメイン サフィックスが機能する保証はありません。 移行プロセスが完了したら、できるだけ早く Azure Key Vault を使用するように構成を更新することを強くお勧めします。

IP ベースの TLS/SSL バインドを使用したアプリの移行サポート

App Service Environment v3 では、IP ベースの TLS/SSL バインドはサポートされていません。 以前の移行機能では、バインドを削除してからでないと移行ができませんでした。 自動移行を有効にするには、IP ベースの TLS/SSL バインドを確認するための自動検証が削除されます。 IP ベースの TLS/SSL バインドがある場合は、移行が完了したらそれらを削除する必要があります。 バインドを削除するまで、アプリは機能しません。

自動移行によって発生する問題に対処する

自動移行後にアプリまたはサービスで発生する可能性がある問題を次に示します。 問題がここに記載されておらず、サポートが必要な場合は、Azure サポートにお問い合わせください。

問題: App Service Environment v3 で古いカスタム ドメイン サフィックス構成が使用されている

App Service Environment v2 にカスタム ドメイン サフィックス構成がある場合、その構成は App Service Environment v3 に移行されます。 証明書は App Service Environment v3 にアップロードされ、アップロードされた証明書を使用するように構成が更新されます。 このプロセスは一時的な措置として実行され、現在の証明書の有効期限が切れるまで有効です。 自動移行後に古いカスタム ドメイン サフィックス構成が機能する保証はありません。

この非互換性に対処するには、移行プロセスが完了した後、証明書の有効期限が切れる前に Azure Key Vault を使用するように構成を更新する必要があります。 構成を更新しない場合、証明書の有効期限が切れると、カスタム ドメイン サフィックスは機能しません。 カスタム ドメイン サフィックス構成を更新するには、「App Service Environment v3 のカスタム ドメイン サフィックス」の手順に従ってください。

問題: App Service Environment v3 上のアプリに IP ベースの TLS/SSL バインドがある

App Service Environment v3 では、IP ベースの TLS/SSL バインドはサポートされていません。 移行が完了したら、バインドを削除する必要があります。 バインドを削除するまで、アプリは機能しません。

問題: 新しい受信 IP アドレスを使用するように依存リソースが更新されない

ILB App Service Environment の移行では受信 IP アドレスが保持されるため、操作は必要ありません。

ELB App Service Environment の移行により、受信 IP アドレスが変更されます。 A レコードを使用して App Service Environment の受信 IP アドレスをポイントする場合は、移行プロセスが完了した後、A レコードを更新して新しい受信 IP アドレスをポイントする必要があります。 CNAME レコードを使用する場合は、DNS を変更する必要はほとんどありません。 受信 IP アドレスに他の依存関係がある場合は、それに応じて更新する必要があります。 移行プロセスが完了した後、古い受信 IP アドレスは無効になります。

問題: 依存リソースが新しい送信 IP アドレスを使用するように更新されない

App Service Environment v3 には、2 つの送信 IP アドレスがあります。 移行プロセスの後、既存の送信 IP アドレスが保持される可能性がありますが、別の送信 IP が作成されます。 カスタム ドメイン サフィックス構成があり、パブリック インターネット経由で Azure Key Vault に接続する場合は、この他の新しい送信 IP アドレスを考慮する必要がある場合があります。 元の送信 IP アドレスが保持されていない場合は、この変更についても考慮する必要があります。

問題: App Service Environment v3 での機能の変更または非互換性

一般に、App Service Environment v3 は App Service Environment v1 および v2 と互換性があります。 ただし、いくつかの違いがあります。 バージョン間の違いを確認するには、「App Service Environment バージョンの比較」を確認してください。 App Service Environment v3 でサポートされていない機能や動作が異なる機能を使用している場合は、それに応じてアプリを更新する必要があります。

App Service Environment v3 の主な変更点を次に示します。

• IP ベースの TLS/SSL バインドはサポートされていません。
• カスタム ドメイン サフィックスの構成は異なります。
• カスタム ドメイン サフィックスがある場合でも、既定のドメインは常に維持されます。
• カスタム ドメイン サフィックスの非ワイルドカード証明書は許可されません。
• App Service Environment v3 には、2 つの送信 IP アドレスがあります。
• 使用可能な SKU はサイズが異なります。
• 予測モデルが異なります。
• ネットワーク モデルが異なります。
• FTPS エンドポイントの構造が異なります。 カスタム ドメイン サフィックスを使用した FTPS エンドポイントへのアクセスはサポートされていません。
• 仮想ネットワーク内の構成済みのカスタム DNS サーバーで特定の名前を解決できない場合、App Service Environment v3 は Azure DNS にフォールバックされません。 この動作が必要な場合は、パブリック DNS へのフォワーダーがあることを確認するか、カスタム DNS サーバーの一覧に Azure DNS を含めます。

価格

App Service Environment の自動移行に関連するコストはありません。 移行プロセス中にシャットダウンされるとすぐに、以前の App Service Environment に対する課金が停止されます。 デプロイされるとすぐに、新しい App Service Environment v3 に対して課金が開始されます。 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 v1 および v2 の提供終了後のサポート ポリシー

次のステートメントは、2024 年 9 月 1 日時点の Azure App Service Environment v1 および v2 サポート ポリシーを表しています。 App Service Environment v3 で実行されているワークロードには影響しません。

このサポート ポリシーは、予定されている提供終了日を過ぎたサービスを実行するために Microsoft から書面による承認を受けた延長期間または猶予期間の終了時に期限切れになります。 その日付までに移行しないと、残りの Azure App Service Environment v1 と v2 がすべて廃止されます。これには、アプリとデータの削除、自動インプレース移行、その他の廃止手順が含まれる場合がありますが、これらに限定されません。

拡張サポート ポリシーには、次のものが含まれます。

• 2024 年 9 月 1 日の時点で、サービス レベル アグリーメント (SLA) は App Service Environment v1 および v2 には適用されなくなります。 提供終了日を超えて製品を引き続き使用する場合、廃止された環境に対して Azure が 99.95% の SLA にコミットしないことに同意することになります。
• Microsoft は、プラットフォームを維持し、移行を完了できるように取り組んでいます。 そのため、カスタマー サポート サービス (CSS) と製品グループ (PG) のサポート チャネルは、引き続き、サポート ケースと重大な対応インシデント (CRI) を商業的に妥当な方法で処理します。 App Service Environment v1 と v2 では、新しいセキュリティとコンプライアンスへの投資は行われません。
• App Service は引き続き、こちらに記載されているプラットフォームの更新プロセスに従って、オペレーティング システムと言語ランタイムに修正プログラムを適用します。
• App Service は引き続き、ロールアウト前に Azure App Service の更新プログラムをテストおよび検証し、プラットフォーム更新プログラムの安全なデプロイ手順に従います。
• App Service は引き続き、Azure App Service Environment v1/v2 の運用フットプリントを積極的に監視し、現在と同じ緊急度でこの監視によって検出された問題に対処します。
• Microsoft は引き続き、Azure App Service のサポート ケースを受け入れ、Azure App Service の問題をタイムリーに解決していきます。
• App Service では引き続き、発生する可能性のある Azure App Service プラットフォームの重大なバグに対するパッチと修正プログラムが適用されます。
• ただし、すべての Cloud Services および Azure サービス管理 (ASM)/RedDog Front End (RDFE) コンポーネントに影響を与える提供終了により、下位レベルの Azure 依存関係から発生する可能性のある問題を効果的に軽減する機能が正常に機能しなくなる可能性があります。

サービスの中断を回避するために、できるだけ早く Azure App Service Environment v3 への移行を完了することをお勧めします。 移行プロセスに関するヘルプが必要な場合や質問がありましたら、サポート チームまでお問い合わせください。 提供終了と移行の手順、使用可能なリソース、移行の利点の詳細については、製品のドキュメントを参照してください。

よく寄せられる質問

• App Service Environment v1/v2 で一時的なアプリケーションの停止が発生するのはなぜですか?
  Azure プラットフォームは、App Service Environment v1 と v2 が実行されるインフラストラクチャである Cloud Services (クラシック) の提供終了に向けて準備をしています。 この準備の一環として、一時的な停止とサービスの中断が予想されます。 これらの中断の影響を最小限に抑えるために、できるだけ早く App Service Environment v3 に移行することをお勧めします。
• App Service Environment が自動移行されたのはなぜですか?
  App Service Environment v1 と v2 は廃止され、サポートされなくなりました。 App Service Environment v1 と v2 のサポート インフラストラクチャは使用停止中です。 ご利用の App Service Environment がサポートされているプラットフォームで実行されるよう、Microsoft は App Service Environment v3 への自動移行を開始します。
• 自動移行後にアプリが動作しないのはなぜですか?
  自動移行後、機能の更新や互換性がないため、アプリまたはサービスに問題が発生する可能性があります。 これらの問題に対処するには、「自動移行によって発生する問題に対処する」を参照してください。
• 自動移行プロセス中のダウンタイムはどのくらいですか?
  自動移行プロセス中に約 1 時間のダウンタイムが発生します。 App Service Environment の受信 IP アドレスと送信 IP アドレスは、移行プロセス中に変更される可能性があります。 これらの IP アドレスに依存している場合、ダウンタイムが長くなる可能性があります。 また、App Service Environment v3 でサポートされていない機能を使用している場合にも、ダウンタイムが長くなる可能性があります。
• 自動移行に対して請求されますか?
  App Service Environment の自動移行に関連するコストはありません。 移行プロセス中にシャットダウンされるとすぐに、以前の App Service Environment に対する課金が停止されます。 デプロイされるとすぐに、新しい App Service Environment v3 に対して課金が開始されます。
• App Service Environment が削除されたのはなぜですか?
  自動移行を実行できない場合、リソースとそれに関連するアプリ データは削除されます。 このシナリオを回避するために、今すぐ行動することを強くお勧めします。 移行を完了するためにさらに時間が必要な場合は、1 回限りの 30 日間の猶予期間を設定できます。 猶予期間中は App Service Environment は削除されません。 猶予期間が終了すると、App Service Environment とすべての関連データが削除される可能性があります。