Azure App Service Environment (ASE) v3 移行ガイド
To access the English version of this article, click here.
1. この記事の範囲
この記事では、Azure App Service Environment (ASE) の最新バージョンv3 への移行に関するガイドとして、ASEv3の概要、移行の背景と必要性、影響を受けるリソース、移行パスについて記載します。ASEv3への移行プロセスを理解し、適切な移行方法を選択するための方法を確認します。
2. 背景
速度、スケーラビリティ、VNetサポートを強化した最新バージョンの App Service Environment v3 がリリースされました。これに伴い、App Service Environment v1 および v2のサポート終了が近づいています。
v3への移行は、シームレスな運用効率とコンプライアンスの確保だけでなく、新機能と潜在的なコスト削減を活用することができます。
2021年8月、AzureはAzure Cloud Services (クラシック) が2024年8月31日に廃止されることを発表しました。App Service Environment v1 および v2 は Azure Cloud Services (クラシック) 上で実行されており、同時に廃止されます。そのため、App Service Environment v1 または v2 を使用している場合、今が App Service Environment v3 への移行を検討する最後のタイミングです。
3. 内容
3.1. App Service Environment とは
App Service Environment (ASE) は、Web Apps をホストするための専用環境を提供する App Service の一部です。ASE は、特定のニーズに合わせた高度なセキュリティとスケーラビリティを提供し、企業や大規模なアプリケーションに最適です。
ASE は専用の Virtual Network (VNet) 内にデプロイされるため、他のリソースと物理的に分離された環境で運用されます。この分離により、データ保護とセキュリティが強化されます。また、ネットワークセキュリティグループ(NSG)やユーザー定義ルート(UDR)を使用してトラフィックを詳細に制御することができます。ASE の最大の特徴の一つは、インターネットから完全に隔離することが可能な点です。これにより、特定のネットワークポリシーを適用したり、オンプレミスのネットワークとセキュアに接続することができます。さらに、特定の IP アドレスやサブネットからのアクセスを制限する機能も提供されています。Azure サービスエンドポイントを利用することで、Azure リソースと直接通信することが可能となり、より効率的なネットワークアーキテクチャを構築できます。これにより、ASE を使用するアプリケーションは、パフォーマンスとセキュリティの両方で優れた成果を得ることができます。
このように、App Service Environment は、高度なセキュリティ、柔軟なネットワーク制御、専用のホスティング環境を提供することで、エンタープライズレベルのアプリケーションに最適なソリューションを提供します。
3.2. v3移行で影響を受けるリソース
App Service Environment (ASE) v3 への移行を計画する際、影響を受けるリソースや考慮すべきポイントを確認することが重要です。以下に、移行プロセスで影響を受ける可能性のある主なリソースと要点をまとめました。
リソース | 要点 | 詳細 |
---|---|---|
アプリケーション | Web アプリケーション | ASE v3以外でホストされている全てのWebアプリケーションが移行後も正常に動作することを確認。アプリケーションの設定や構成が変更されていないかを確認。 |
ネットワーク構成 | Virtual Network (VNet) | ASE v3 の VNet 設定が異なる可能性あり。ネットワークの接続性を確認し、必要に応じて VNet の設定を更新。 |
サブネット | ASE v3 では専用のサブネットを使用することが推奨される。既存のサブネット設定を確認し、新しいサブネットを設定する必要があるか判断。 | |
IP アドレス | パブリック IP アドレス | 使用していたパブリック IP アドレスが変更される可能性。DNS 設定やファイアウォールルールの更新が必要か確認。 |
プライベート IP アドレス | 内部アプリケーションやリソース間の通信に影響がないかを確認。 | |
セキュリティ設定 | ネットワークセキュリティグループ (NSG) | NSG ルールが ASE v3 の要件に合致しているか確認。必要に応じてルールを更新。 |
Azure Active Directory (AAD) 統合 | 認証やアクセス管理に影響がないか確認。 | |
スケーリングとパフォーマンス | スケール設定 | ASE v3 ではスケーリングのオプションやパフォーマンス特性が異なる場合あり。スケール設定を確認し、必要に応じて調整。 |
パフォーマンスモニタリング | 移行後のパフォーマンスモニタリングを強化し、問題がないか確認。 | |
デプロイメントおよび CI/CD パイプライン | デプロイメントパイプライン | デプロイメントプロセスに影響がないか確認。特に、ASE v3 で新たに必要な設定や構成がないか確認。 |
CI/CD パイプライン | パイプラインの構成が新しい環境に対応しているかを確認し、必要に応じて更新。 | |
依存リソース | ストレージアカウント | アプリケーションが依存するストレージアカウントやその他の Azure リソースが移行に影響を受けないか確認。 |
データベース | Azure SQL Database やその他のデータベース接続が影響を受けないかを確認。 | |
コスト | コスト評価 | ASE v3 への移行によるコストの変動を評価し、予算内で収まるか確認。 |
このように、ASE v3 への移行においては、さまざまなリソースや設定が影響を受ける可能性があります。事前にこれらの要点を確認し、適切な対策を講じることで、スムーズな移行を実現します。
3.3. 移行パス
3.3.1. ASE v3への移行方法の比較
App Service Environment v3 へのアップグレードには、2つの自動移行機能と手動移行があります。
- インプレース移行機能は、既存の App Service Environment (ASE) を同じサブネット内で新しい App Service Environment v3 に置き換える自動プロセスです。この機能について詳しくは、インプレース移行機能を使用した自動アップグレードに関する記事を参照。
- サイド バイ サイド移行機能は、新しい App Service Environment (ASE) v3 を既存の環境とは別のサブネットに作成し、移行を行うプロセスです。この方法は、移行期間中にダウンタイムを最小限に抑えることができるため、特に重要な特徴があります。この機能の詳細については、サイド バイ サイド移行機能を使用した自動アップグレードに関する記事を参照。
- 手動移行オプションは、自動移行機能が利用できない場合や、カスタム要件に応じた柔軟な移行が必要な場合に選択する方法です。このプロセスには多くの手作業が含まれますが、細部まで制御できる点が特徴です。詳しくは、代わりの移行方法に関する記事を参照。
移行方法 | 特徴 | 適したシナリオ |
---|---|---|
インプレース移行 | - 同一サブネット内での移行 - ダウンタイムの発生 - リージョン変更不可 - カスタムドメインサフィックスの設定が必要 - IPベースのTLS/SSLバインド非サポート |
- 既存のサブネットと同じネットワーク設定を維持したい場合 - アプリケーションの短時間のダウンタイムが許容される場合 - リージョンを変更する必要がない場合 - シンプルで迅速な移行を希望する場合 |
サイドバイサイド移行 | - 別サブネットでの新規デプロイ - ダウンタイムの最小化 - リージョン変更不可 - カスタムドメインサフィックスの設定が必要 - CLIまたはREST APIを使用 |
- ミッションクリティカルなアプリケーションで、ダウンタイムを最小限に抑えたい場合 - 段階的に移行を進めたい場合 - 同一リージョン内で新しい環境を準備する時間がある場合 - 自動化ツールを使用して移行を管理できる場合 |
手動移行 | - 柔軟なカスタマイズが可能 - 詳細な評価と計画が必要 - 新しいサブネットと環境の作成 - 段階的な移行 - ダウンタイムの管理が必要 |
- インプレース移行やサイドバイサイド移行がサポートされていない環境 - 特殊なネットワーク設定やカスタム要件がある場合 - 綿密な移行計画とテストが必要なミッションクリティカルなアプリケーション - 完全な制御とカスタマイズが求められる場合 |
3.3.2. App Service Environment (ASE) v3 への移行パスチェックリスト
# | 確認項目 | 選定事項 |
---|---|---|
1 | ASE v1 or v2である | YES: v3でAllset.移行の必要はない。 NO: v3に移行 |
2 | ASEがクラシック仮想ネットワークのASE v1である | YES: 手動マイグレーションを選択 NO: - |
3 | リージョンでASE v3がサポートされている | YES: - NO: 手動マイグレーションを選択 |
4 | ASE v2は特定のゾーン固定されている | YES: 手動マイグレーションを選択 NO: - |
5 | IP SSL アドレスを使用する ELB App Service Environmentである | YES: ASE 内のすべてのサイトから IP SSL を削除 ※ App Service Environment v3 では IP SSL はサポートされない NO: - |
6 | 同じサブネットを使用する必要がある | 【同じサブネットを使用する場合】 [メリット: 設定の維持] 既存のネットワーク設定やセキュリティポリシー(ネットワークセキュリティグループやユーザー定義ルートなど)をそのまま維持できる。 既存のリソースと新しいリソース間でのネットワーク通信設定を変更する必要が少ない。 [デメリット: 移行リスク] 移行中に既存のリソースに影響を与えるリスクが高くなる。特に、同じサブネット内での設定変更が必要な場合、既存のアプリケーションの動作に影響を与える可能性がある。 【異なるサブネットを使用する場合】 [メリット: 分離] 新しいサブネットを使用することで、旧環境と新環境を明確に分離できる。これにより、テストや移行の際に既存の環境に影響を与えるリスクが低減される。 [デメリット: 設定の複雑化] 新しいサブネットを設定する作業が発生する。新しいネットワークセキュリティグループやルートテーブルを設定する必要がある。既存のリソースと新しいリソース間のネットワーク通信設定を再構成する。 |
7 | アプリケーションのダウンタイムを最大1時間までサポートし、自動化ツールを使用するか | YES : インプレース移行を選択 NO : サイドバイサイド移行 OR 手動移行を選択 |
8 | 仮想ネットワーク内の空サブネットがある | YES: - NO: 新しいサブネットを作成し, 必要に応じて仮想ネットワークのアドレス空間を増やす。 |
3.3.3. チェック項目の確認方法
確認項目 | 確認方法 | |
---|---|---|
1 | ASE v1 または v2 か | ASE構成情報のKindプロパティをチェックする。 |
2 | リージョンがASE v3がサポートされているか | ASE構成情報のLocationプロパティをチェックする。 |
3 | ASE v2 が特定のゾーンに固定されているか | Azure Availability Zones の機能を利用して、特定のゾーンに固定された App Service Environment v2 (ASE v2) を利用しているか確認する。ASE構成情報のZoneRedundantプロパティの値でチェックする。 |
4 | IP SSL アドレスを使用する ELB App Service Environment であるか | App Service Environment (ASE) が、IP SSL アドレスを使用する外部ロードバランサー (ELB) を持つ構成であるかどうかを確認する。ASE構成情報のinternalLoadBalancingModeプロパティがNoneであればELB(外部ロードバランサー)の使用を示す。WebまたはPublishingであれば、ILB(内部ロードバランサー)を示す。また、ASE構成情報のIpsslAddressCountプロパティからIP SSL アドレスは使用状況をチェックする。 |
5 | 仮想ネットワーク内の空サブネットがあるか | 仮想ネットワーク (VNet) 内に、現在リソースがデプロイされていない空のサブネットが存在するかどうか使用状況を確認する。仮想ネットワークのサブネット一覧を取得し、サブネットにipConfigurationsが設定されていないかをチェックする。 |
サブスクリプション内の ASE 一覧
サブスクリプション内のすべての ASE を一覧表示します。以下のコマンドを実行します。
# サブスクリプション内のすべての ASE を一覧
az appservice ase list --output table
出力例
DnsSuffix HasLinuxWorkers InternalLoadBalancingMode IpsslAddressCount Kind Location MaximumNumberOfMachines MultiRoleCount MultiSize Name ProvisioningState ResourceGroup Status Suspended ZoneRedundant
---------------------------------------- ----------------- --------------------------- ------------------- ------ ---------- ------------------------- ---------------- -------------- -------------- ------------------- --------------- -------- ----------- ---------------
examplease1.p.azurewebsites.net False None 2 ASEV2 East US 250 2 Standard_D1_V2 examplease1 Succeeded example-rg Ready False False
examplease2.appserviceenvironment.net False Web, Publishing 0 ASEV2 West US 250 2 Standard_D1_V2 examplease2 Succeeded example-rg Ready False False
ASE の詳細情報取得
特定の ASE の詳細情報を取得します。以下のコマンドを実行します。
# ASE の詳細情報を取得
az appservice ase show --resource-group example-rg --name examplease1 --output json
仮想ネットワーク内のサブネット一覧
仮想ネットワーク内のすべてのサブネットを一覧表示します。以下のコマンドを実行します。
# 仮想ネットワーク内のサブネットを一覧
az network vnet subnet list --resource-group example-rg --vnet-name example-vnet --output table
出力例
AddressPrefix Name PrivateEndpointNetworkPolicies PrivateLinkServiceNetworkPolicies ProvisioningState ResourceGroup
--------------- ------------------------ -------------------------------- ----------------------------------- ------------------- ---------------
10.1.1.0/24 example-sample1-subnet Enabled Enabled Succeeded example-rg
10.1.2.0/24 example-sample2-subnet Enabled Enabled Succeeded example-rg
空のサブネットの確認
仮想ネットワーク内で空のサブネットを確認します。以下のコマンドを実行します。
# 空のサブネットを確認
az network vnet subnet list --resource-group example-rg --vnet-name example-vnet --query "[?ipConfigurations == null]" --output table
出力例
Name AddressPrefix ProvisioningState PrivateEndpointNetworkPolicies PrivateLinkServiceNetworkPolicies ResourceGroup
------------------------ --------------- ------------------- -------------------------------- ----------------------------------- ---------------
example-sample1-subnet 10.1.1.0/24 Succeeded Enabled Enabled example-rg
example-sample2-subnet 10.1.2.0/24 Succeeded Enabled Enabled example-rg
4. まとめ
この記事では、Azure App Service Environment (ASE) v3 への移行について詳細に解説しました。ASE の基本的な機能とその利点について説明し、続いてv3 への移行の背景と必要性を確認しました。移行の際に影響を受けるリソースや考慮すべきポイントをまとめ、インプレース移行、サイドバイサイド移行、手動移行の3つの移行パスを比較しました。移行プロセスの各ステップにおけるチェックリストを提供し、具体的な確認方法とコマンドの例を示しました。これにより、自身の環境に適した移行方法を選択し、スムーズに移行を進めるための実践的なガイドラインを確認できました。
Discussion