App Service Environment v3 への移行

[アーティクル]
03/06/2024

Note

App Service Environment v3 へのアップグレードに役立つ 2 つの自動移行機能が使用できます。これらの機能の詳細と、どの移行オプションが最適かを判断するには、「移行パスのデシジョンツリー」を参照してください。 App Service Environment v3 への迅速なパスを実現するための自動化オプションの 1 つを検討してください。

現在 App Service Environment v1 または v2 を使用している場合は、App Service Environment v3 にワークロードを移行することができます。 App Service Environment v3 には、ワークロードのサポートを強化し、全体的なコストを削減できる、以前とは異なる特徴と機能が備わっています。環境が「移行パスのデシジョンツリー」に記載されている条件を満たしている場合は、自動移行機能の使用を検討してください。

お使いの App Service Environment が移行機能でサポートされていない場合は、手動の方法のいずれかを使って App Service Environment v3 に移行する必要があります。

前提条件

シナリオ: App Service Environment v1 または App Service Environment v2 で実行されているアプリがあり、そのアプリを App Service Environment v3 で実行する必要があります。

自動移行機能を使わない移行方法の場合は、選んだ方法を使って App Service Environment v3 リソースを作成し、新しいサブネットを作成する必要があります。

App Service Environment v1/v2 と App Service Environment v3 の間でのネットワークの変更には、新しい (そしてインターネットに接続する環境の場合は追加の) IP アドレスが含まれます。これらの IP に依存するインフラストラクチャを更新する必要があります。 Azure Load Balancer ポートなど、インバウンドの依存関係の変更を考慮してください。

単一のサブネットに複数の App Service Environment が存在することはできません。新しい App Service Environment v3 リソースに既存のサブネットを使う必要がある場合は、先に既存の App Service Environment を削除してから、新しいものを作成する必要があります。このシナリオでは、環境を作成して構成した後、アプリをバックアップしてから、新しい環境で復元することをお勧めします。このプロセスでは、次の処理に時間がかかるためにアプリケーションでダウンタイムが発生します。

古い環境を削除する。
App Service Environment v3 リソースを作成する。
新しい環境で動作するように、インフラストラクチャおよび接続されたリソースを構成する。
新しい環境にアプリをデプロイする。

アプリを移行する前のチェックリスト

App Service Environment v3 リソースを作成します。
新しい環境に関連付けられている IP アドレスで、ネットワークの依存関係を更新します。
ダウンタイムを計画します (該当する場合)。
新しい環境でアプリを再作成するプロセスを決定します。

移行のサイズとスケールを決定する

App Service Environment v3 では、Isolated プランとは異なる価格とサイズの Isolated v2 Azure App Service プランが使われます。価格の詳細を確認して、適切な容量を確保するために、新しい環境をどれくらいのサイズとスケールにする必要があるかを理解してください。以前のバージョンと比較して、App Service Environment v3 の App Service プランを作成する方法に違いはありません。

バックアップと復元を評価する

バックアップと復元の機能を使って、新しい環境に移行するときに、アプリの構成、ファイルの内容、アプリに接続されているデータベースを保つことができます。

App Service Environment v3 に復元するには、アプリのカスタムバックアップを構成する必要があります。自動バックアップでは、異なる App Service Environment バージョンでの復元はサポートされていません。カスタムバックアップについて詳しくは、「自動バックアップとカスタムバックアップ」をご覧ください。 Screenshot that shows options for configuring custom backups for an App Service app.

カスタムバックアップを選んで、App Service Environment v3 リソースの App Service に復元できます。アプリを復元する前に、復元先の App Service プランを作成する必要があります。運用スロット、既存のスロット、または復元プロセスの間に作成した新しいスロットのいずれかを選んで、バックアップを復元できます。

Screenshot that shows how to use a backup to restore an App Service app in App Service Environment v3.

メリット	制限事項
迅速 - アプリあたり 5 分から 10 分しかかかりません。	サポートは特定のデータベースの種類に限定されます。
複数のアプリを同時に復元できます。 (アプリごとに個別に復元を構成する必要があります。)	古い環境、新しい環境、サポートリソース (アプリ、データベース、ストレージアカウント、コンテナーなど) のすべてが、同じサブスクリプション内に存在する必要があります。
アプリ内 MySQL データベースは、構成しなくても自動的にバックアップされます。	最大 10 GB のアプリとデータベースのコンテンツをバックアップできます。そのコンテンツの最大 4 GB を、データベースのバックアップにできます。バックアップのサイズがこの制限を超えた場合、エラーが発生します。
以前の状態のスナップショットにアプリを復元できます。	バックアップ先としてファイアウォールが有効なストレージアカウントの使用は、サポートされていません。
Azure Traffic Manager および Azure Application Gateway と統合して、古い環境と新しい環境にトラフィックを分散させることができます。	プライベートエンドポイントを使っているストレージアカウントをバックアップと復元に使うことは、サポートされていません。
復元を始める前に、新しい環境に復元先となる空の Web アプリを作成して、プロセスを高速化できます。	カスタムバックアップのみがサポートされます。

アプリを App Service Environment v3 に複製する

アプリの複製は、Windows アプリを App Service Environment v3 に移行するために使用できるもう 1 つの機能です。アプリの複製に関する制限事項は、App Service のバックアップ機能の場合と同じです。詳しくは、Azure App Service でのアプリのバックアップに関する記事をご覧ください。

Note

アプリの複製は、Windows 上の App Service プランでのみサポートされています。

Windows で App Service を使っていて、移行機能を使って移行することができないユーザーには、このソリューションをお勧めします。アプリを複製する前に、新しい App Service Environment v3 リソースを設定する必要があります。アプリの複製は、完了するまで最大で 30 分かかる場合があります。

PowerShell を使ってアプリを複製するには、こちらの手順を参照してください。

Azure portal を使ってアプリを複製するには:

Azure portal で、既存の App Service プランに移動します。 [開発ツール] で、[アプリの複製] を選びます。
新しい App Service Environment v3 リソースの詳細を使って、必要なフィールドに入力します。
1. [リソースグループ] では、既存のリソースグループを選ぶか、新しいリソースグループを作成します。
2. [名前] では、アプリの名前を指定します。この名前は古いアプリと同じでもかまいませんが、サイトの既定の URL は新しい環境では異なります。新しい URL を指すカスタム DNS または接続されたリソースを更新する必要があります。
3. [リージョン] には、App Service Environment v3 の名前を使います。
4. デプロイソースを複製する場合は、[デプロイソースのクローン] チェックボックスをオンにします。
5. [Windows プラン] では、既に作成してある場合は新しい環境から既存の App Service プランを使用でき、新しいプランを作成することもできます。ドロップダウンリストには、新しい App Service Environment v3 リソースで利用できる App Service プランが表示されます。
6. [SKU とサイズ] では、新しい App Service プランを作成している場合は、必要に応じて、Isolated v2 オプションのいずれかを使ってメモリと CPU を変更します。 App Service Environment v3 で使われる Isolated v2 プランでは、対応するインスタンスサイズごとに、Isolated プランより多くのメモリと CPU を利用できます。詳しくは、App Service Environment v3 の価格の詳細に関する記事をご覧ください。

Screenshot that shows options for cloning an app to App Service Environment v3 by using the portal.

メリット	制限事項
PowerShell を使って複製を自動化できます。	Windows 上の App Service プランでのみサポートされます。
同時に複数のアプリを複製できます。 (複製は、アプリごとに個別に構成するか、スクリプトを通して行う必要があります。)	サポートは特定のデータベースの種類に限定されます。
Azure Traffic Manager および Azure Application Gateway と統合して、古い環境と新しい環境にトラフィックを分散させることができます。	古い環境、新しい環境、サポートリソース (アプリ、データベース、ストレージアカウント、コンテナーなど) のすべてが、同じサブスクリプション内に存在する必要があります。

App Service Environment v3 でアプリを手動で作成する

お使いのアプリが移行機能でサポートされていない場合、またはもっと手作業で行いたい場合は、既存の App Service Environment で使ったのと同じプロセスに従ってアプリをデプロイできます。

既存のアプリ、App Service プラン、その他のサポートされているリソースの Azure Resource Manager テンプレート (ARM テンプレート) をエクスポートし、それらを新しい環境にデプロイできます。アプリだけのテンプレートをエクスポートするには、App Service プランに移動します。 [オートメーション] で、 [テンプレートのエクスポート] を選択します。

Screenshot of the option to export a template on the left pane of the Azure portal.

リソースグループから複数のリソースのテンプレートを直接エクスポートすることもできます。リソースグループに移動し、テンプレートが必要なリソースを選んでから、[テンプレートのエクスポート] を選びます。

Screenshot of the option for exporting a template for resources from a resource group.

アプリを App Service Environment v3 に移行するには、ARM テンプレートに対する次の初期変更が必要です。

App Service プランの sku パラメータを Isolated v2 プランに更新します。

"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-02-01",
"name": "[parameters('serverfarm_name')]",
"location": "East US",
"sku": {
    "name": "I1v2",
    "tier": "IsolatedV2",
    "size": "I1v2",
    "family": "Iv2",
    "capacity": 1
},

アプリをデプロイする App Service プラン (serverfarm) パラメータを、App Service Environment v3 に関連付けられているプランに更新します。
ホスティング環境プロファイル (hostingEnvironmentProfile) パラメータを、新しい App Service Environment v3 リソース ID に更新します。

ARM テンプレートのエクスポートには、リソースプロバイダーが特定のリソースについて公開するすべてのプロパティが含まれます。古いアプリのドメインを指すプロパティなど、必要のないプロパティをすべて削除します。たとえば、sites リソースは次のサンプルのように簡略化できます。

"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"name": "[parameters('site_name')]",
"location": "East US",
"dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]"
],
"properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]",
    "siteConfig": {
        "linuxFxVersion": "NODE|14-lts"
     },
    "hostingEnvironmentProfile": {
        "id": "[parameters('hostingEnvironments_externalid')]"
    }
}

アプリの構成方法によっては、他の変更が必要になる場合があります。たとえば、システム割り当てマネージド ID と、古い環境と新しい環境に同じアプリケーション名を使用すると、競合が発生する可能性があります。この競合を解決し、ダウンタイムを回避するために、ユーザー割り当てマネージド ID を使用できます。

Azure portal、Azure CLI、または PowerShell を使って、ARM テンプレートをデプロイできます。

手動で移行する

インプレース移行機能では、App Service Environment v3 への移行が自動化され、すべてのアプリが新しい環境に転送されます。この移行中には、約 1 時間のダウンタイムがあります。アプリのダウンタイムが許されない場合は、サイドバイサイド移行機能を使うことをお勧めします。これは、新しい環境が別のサブネットに作成されるため、ダウンタイムがない移行オプションです。また、サイドバイサイド移行機能を使わないことを選んだ場合は、手動オプションの 1 つを使って App Service Environment v3 でアプリを再作成できます。

Application Gateway を使うと、古い環境と新しい環境の間にトラフィックを分散できます。内部ロードバランサー (ILB) App Service Environment を使っている場合、環境間にトラフィックを分散させるには、余分なバックエンドプールを含む Azure Application Gateway インスタンスを作成します。 ILB App Service Environment とインターネットに接続する App Service Environment について詳しくは、「Application Gateway の統合」をご覧ください。

また、Azure Front Door、Azure Content Delivery Network、Azure Traffic Manager などのサービスを使って、環境間にトラフィックを分散させることもできます。これらのサービスを使うと、制御された方法で新しい環境をテストでき、自分のペースで新しい環境に移行できます。

移行と新しい環境でのテストが完了したら、古い App Service Environment、その上にあるアプリ、不要になったサポートリソースを削除します。削除しないリソースに対しては引き続き課金されます。

よく寄せられる質問

手動オプションのいずれかを使って App Service Environment v3 に移行する必要があるかどうかを確認するにはどうすればよいですか?
どの移行オプションが適切であるかを判断するには、「移行パスのデシジョンツリー」を参照してください。お使いの環境が、「移行パスのデシジョンツリー」に記載されている条件を満たしている場合は、App Service Environment v3 へのより迅速なパスとして、自動移行機能の 1 つを使うことを検討してください。アプリを新しい環境にゆっくりと移行し、プロセス全体を通して検証する必要がある場合は、手動移行をお勧めします。
移行中にダウンタイムが発生しますか?
ダウンタイムは、移行処理によって異なります。移行中にトラフィックを転送できる別の App Service Environment がある場合、または別のサブネットを使って新しい環境を作成できる場合、ダウンタイムは発生しません。同じサブネットを使う必要がある場合は、古い環境の削除、App Service Environment v3 リソースの作成、新しい App Service プランの作成、アプリの再作成、新しい IP アドレスを使うすべてのリソースの更新を行っている間、ダウンタイムが発生します。
App Service Environment v3 で実行するために、アプリに関する何かを変更する必要がありますか?
いいえ。 App Service Environment v1 と v2 で実行されるアプリは、App Service Environment v3 で実行するために何も変更する必要はありません。 IP SSL を使用している場合は、移行する前に IP SSL バインドを削除する必要があります。
App Service Environment にカスタムドメインサフィックスが設定されている場合はどうなりますか?
移行機能では、この移行シナリオがサポートされています。移行機能を使いたくない場合は、手動の方法を使って移行できます。 App Service Environment v3 リソースを作成するとき、またはその後いつでも、カスタムドメインサフィックスを構成できます。
App Service Environment v2 リソースがゾーンに固定されている場合はどうなりますか?
ゾーン固定は App Service Environment v3 でサポートされている機能ではありません。 App Service Environment v3 リソースの作成時に、ゾーン冗長の有効化を選択できます。
App Service Environment のどのプロパティが変更されますか?
App Service Environment v3 と以前のバージョンの間の機能の違いを確認してください。 ILB App Service Environment の場合は、同じ ILB IP アドレスを維持します。インターネットに接続している App Service Environment の場合は、パブリック IP アドレスとアウトバウンド IP アドレスが変更されます。

インターネットに接続している App Service Environment では、以前はインバウンドとアウトバウンドの両方に対して 1 つの IP が使われていました。 App Service Environment v3 では、これらは別々になります。詳細については、App Service Environment v3 ネットワークに関するページを参照してください。
App Service Environment v2 から v3 へのアプリの移行では、バックアップと復元はサポートされていますか? バックアップと復元機能では、復元にカスタムバックアップを使う限り、App Service Environment のバージョン間でのアプリの復元がサポートされます。自動バックアップでは、異なる App Service Environment バージョンへの復元はサポートされていません。
App Service Environment v1 および v2 リソースは、2024 年 8 月 31 日を過ぎるとどうなりますか?
App Service Environment v3 に移行しないまま 2024 年 8 月 31 日を過ぎると、App Service Environment v1 および v2 リソースとそこにデプロイされているアプリは使用できなくなります。

App Service Environment v1 と v2 は、Azure Cloud Services (クラシック) アーキテクチャで動作する App Service スケールユニットでホストされます。このアーキテクチャは 2024 年 8 月 31 日に廃止されるため、App Service Environment v1 と v2 はその日以降使用できなくなります。アプリが実行し続けるように App Service Environment v3 に移行するか、保持する必要があるリソースまたはデータを保存またはバックアップしてください。