App Service Environment の計画メンテナンスのアップグレード設定

Azure App Service は定期的に更新され、新機能、新しいランタイム バージョン、パフォーマンスの向上、バグ修正が提供されます。 これは計画メンテナンスとも呼ばれます。 アップグレードは自動的に行われます。 アップグレードは Azure の安全なデプロイ プラクティスに従って、複数のリージョンで段階的に適用されます。 App Service Environment は、App Service アプリを大規模かつ安全に実行するために完全に分離された専用の環境を提供する、Azure App Service の機能です。 App Service Environment は分離された性質を持つため、アップグレード プロセスに影響を与える機会がユーザーに与えられています。

App Service Environment がない場合は、App Service Environment v3 の作成方法に関するページを参照してください。

App Service Environment v3 では、計画メンテナンスを適用するタイミングと方法の設定を指定できます。 アップグレードは、自動的または手動で適用できます。 設定を自動に設定した場合でも、タイミングに影響を与えるオプションがいくつかあります。

自動アップグレードの設定

自動アップグレードの設定を使用した場合、インスタンスがデプロイされているリージョンでアップグレードが利用可能になると、プラットフォームによって App Service Environment インスタンスがアップグレードされます。 次のいずれかのオプションを選択できます。

• None (なし) が既定のオプションです。 このオプションでは、そのリージョンのアップグレード プロセス中にアップグレードが自動的に適用されます。
• Early (早期) では、アップグレードが自動的に適用されますが、アップグレードするリージョンの最初のインスタンスの 1 つとして優先順位が付けられます。
• Late (遅延) では、アップグレードが自動的に適用されますが、そのインスタンスはアップグレードするリージョンの最後のものの 1 つになります。

小規模なリージョンでは、Early と Late のアップグレード設定は互いに非常に近い場合もあります。

手動アップグレードの設定

手動アップグレードの設定では、アップグレードが利用可能になったときに通知を受け取るオプションが提供されます。 利用可能になったことは Azure portal にも表示されます。 アップグレードが利用可能になると、アップグレード プロセスを開始するまで 15 日間が与えられます。 15 日以内にアップグレードを開始しなかった場合、アップグレードはリージョン内の残りの自動アップグレードで処理されます。

通常、アップグレードはアプリの可用性には影響しません。 アップグレードによってインスタンスが追加され、アップグレード中に同じ容量が確実に使用できるようになります。 修正プログラムが適用され、再起動されたインスタンスはローテーションで再び追加されます。再起動の影響を受けやすいワークロードがある場合は、業務時間外にメンテナンスを開始することを計画する必要があります。 完全なアップグレード プロセスは通常 18 時間以内に完了しますが、それよりも時間がかかる場合もあります。 アップグレードが開始されると、そのアップグレードは完了するまで実行され、通常の業務時間中に一時停止されることはありません。

通知を構成する

アップグレードが利用可能になると、Azure Monitor の [サービス正常性] ダッシュボードに計画メンテナンス イベントが追加されます。 Azure portal で過去の通知を表示するには、[ホーム] > [モニター] > [サービス正常性] > [計画メンテナンス] に移動します。 関連するイベントを簡単に見つけるには、[サービス] ボックスを選択し、App Service の種類のみをオンにします。 サブスクリプションとリージョンでフィルター処理することもできます。

Azure Monitor でイベントが生成されたときに、メール アドレスや SMS の電話番号にメッセージを送信するようにアラートを構成できます。 カスタムの Azure 関数またはロジック アプリのトリガーを設定することもできます。これにより、リソースに対して自動的にアクションを実行できます。 このアクションは、アップグレードされる 1 つのリージョンの App Service Environment から、別のリージョンの App Service Environment に、トラフィックを自動的に転送させる場合もあります。 その後、アップグレードが完了すると、トラフィックを自動的に通常の状態に戻すことができます。

アップグレード通知のアラートを構成するには、ダッシュボードの上部にある [サービス正常性アラートの追加] を選択します。 Azure Monitor アラートの詳細情報を確認してください。 この操作方法に関する記事では、サービス正常性イベントのアラートを構成する方法について説明します。 最後に、この攻略ガイドに従って、アラートに基づいてトリガーされるアクション グループを作成する方法を学習できます。

テスト通知を送信する

自動化と通知ロジックを構築するときは、このアップグレードが 1 か月以上先になる可能性があるため、実際のアップグレードを利用できるようになる前にテストする必要があります。Azure portal には、特殊なテスト アップグレードが利用可能な場合の通知を送信する機能があります。この通知を使用して、自動化ロジックを検証できます。 メッセージは実際の通知に似ていますが、タイトルの先頭に "[Test]" が付き、説明が異なります。 アップグレード設定を [手動] に構成した後、テスト通知を送信できます。

テスト通知を送信するには、App Service Environment の [構成] ページに移動し、[テスト通知の送信] リンクを選択します。 テスト通知は、15 分ごとにバッチで送信されます。

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-Resource-Group>
az resource show --name $ASE_NAME -g $ASE_RG --resource-type "Microsoft.Web/hostingEnvironments" --query properties.upgradePreference

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-Resource-Group>
az resource update --name $ASE_NAME -g $ASE_RG --resource-type "Microsoft.Web/hostingEnvironments" --set properties.upgradePreference=Manual

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-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}/testUpgradeAvailableNotification?api-version=2022-03-01"

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

次のステップ