定期的なメンテナンスには、Azure App Service のバックグラウンド更新が含まれます。 これらの更新プログラムには、パフォーマンスの向上、バグ修正、新機能、またはセキュリティ更新プログラムが含まれる場合があります。 メンテナンスは、App Service プラットフォームまたは基になるオペレーティング システムに適用できます。
重要
機能の破壊的変更や非推奨化は、通常のメンテナンスには含まれません。 詳しくは、「Modern Lifecycle ポリシー」をご覧ください。
Microsoft のサービス品質とアップタイムの保証は、メンテナンス期間中も引き続き適用されます。 通知は、お客様がプラットフォームの変更を可視化できるようにするために提供されます。
予期される事柄
パーソナル コンピューター、携帯電話、その他のデバイスと同様に、クラウド内のマシンには定期的な更新が必要です。 物理デバイスとは異なり、Azure App Service は中断を最小限に抑えながら日常的なメンテナンスを処理します。 ワークロードを更新されたハードウェアに数秒で移行できるため、ダウンタイムなしで更新を続行できます。
通常、メンテナンスは毎月行われますが、組織のニーズやその他の要因によって異なる場合があります。
一般的なクラウド ソリューションは複数のアプリケーション、データベース、ストレージ アカウント、関数、およびその他のリソースで構成されるため、ソリューションの一部は異なる時期にメンテナンスを受ける可能性があります。 このバリエーションは、地域、リージョン、データセンター、および可用性ゾーンが原因である可能性があります。 詳しくは、「安全なデプロイ プラクティス」をご覧ください。
メンテナンス イベントを見つけるには、Azure portal で Service Health を検索します。 [ アクティブなイベント] で、[ 計画メンテナンス] を選択します。
上から下に、例は次を示しています。
- メンテナンス イベントのわかりやすいタイトル。
- 影響を受けるリージョンとサブスクリプション。
- 予想されるメンテナンス期間。
次のスクリーンショットは、[ 影響を受けたリソース ] タブから入手できる追加情報を示しています。
![Azure portal の [影響を受けたリソース] セクションのスクリーンショット。](media/routine-maintenance/routine-maintenance-first-page.png#lightbox)
この例では、左から右に次を示します。
- [影響を 受けたリソース ] タブを選択します。
- [ 詳細情報] オプション。
注
App Service プランでは、メンテナンスの手動開始はサポートされていません。 ただし、App Service Environment (ASE) では手動メンテナンス設定がサポートされています。
この例は、次を示しています。
- メンテナンスの状態 (保留、開始、または完了)。
- メンテナンスが開始されると、[ 詳細情報] の下にタイムスタンプを表示できます。
よく寄せられる質問
メンテナンスにこれほど時間がかかるのはなぜですか?
定期的なメンテナンスでは、プラットフォームとサービスに最新の更新プログラムが提供されます。 メンテナンスが個々のアプリに与える影響を予測することは困難であるため、通知には一般的な時間範囲が提供されます。 これらの範囲は、特定のアプリ レベルのエクスペリエンスではなく、すべてのリソース全体の操作を反映します。 更新したばかりのマシンでメンテナンスが再開され、動作を続けるアプリ。 要求やトラフィックが提供されないときは、ダウンタイムは発生しません。
大量の通知が届くのはなぜですか?
多くの場合、お客様には、異なる時間にアップグレードされる複数のアプリケーションがあります。 それぞれについて個別に通知が送られるのを避けるため、複数のリソースを対象とする 1 つの通知が送られます。 通知は、メンテナンス期間の最初と全体を通じて送られます。 時間枠が長い場合、同じロールアウトに対して複数のリマインダーを受け取る可能性があるため、再起動、中断、またはその他の問題をより簡単に関連付けることができます。
定期的なメンテナンスは SLA とどのように関連していますか?
プラットフォームのメンテナンスが、アプリケーションのアップタイムや可用性に影響を与えることはないはずです。 プラットフォームのメンテナンスが行われる間、アプリケーションは引き続きオンラインのままです。
プラットフォームのメンテナンスが原因で、アプリケーションが新しい仮想マシンでコールド スタートし、遅延が発生する可能性があります。 コールド スタートの間も、アプリケーションはやはりオンラインであると見なされます。 コールド スタートを最小限に抑えるか避けるため、Windows アプリのローカル キャッシュと正常性チェックを使うことを検討してください。
メンテナンス期間中にサイトでサービス レベル アグリーメント (SLA) 違反が発生することは想定されていません。
アップグレードではアプリの円滑な動作がどのように保証されますか?
Azure App Service は、Web アプリケーションとソリューションのホスティングをお客様に提供するスケール ユニットのフリートを表します。 各スケール ユニットは、アップグレード ドメインと可用性ゾーンに分割されます。 この部門では、大規模な App Service プランの配置が最適化され、各スケール ユニット内のすべてのマシンが一度に更新されるわけではないため、スムーズなデプロイが可能になります。
メンテナンス操作では、App Service によってフリートの正常性が監視されながら、マシンのアップグレードが繰り返されます。 問題が発生した場合、システムはロールアウトを停止できます。 このプロセスについて詳しくは、ブログ記事「App Service OS の更新の背後にある魔法の謎を解き明かす」をご覧ください。
営業時間は反映されますか?
はい。営業時間はリージョンのタイム ゾーンに反映されます。 メンテナンス操作は、午前 9 時から午後 5 時までの標準の営業時間外に始まるように最適化されています。 統計上、そうすれば (お客様のアプリケーションでも、推移的にプラットフォーム自体でも) システムに対するストレスが少ないため、これはワークロードの中断と再起動に最適なタイミングです。 App Service のメンテナンスは、営業時間中の中断を最小限に抑えるように設計されています。 特定のリージョンで午前 9 時までにアップグレードが進行中の場合、重要なフェーズに達する前に一時停止が試みられます。 一部の基になるインスタンスの移動は続行される可能性がありますが、安全に重なり合い、サイトの可用性を維持するように調整されます。
定期的なメンテナンスを制御するにはどのようなオプションがありますか?
App Service Environment v3 を使って分離された製品でワークロードを実行している場合は、必要に応じてアップグレードをスケジュールできます。 この機能について詳しくは、ブログ記事「App Service Environment v3 の計画メンテナンスの制御と自動化」をご覧ください。
再起動に備えてアプリをどのように準備できますか?
再起動の際にアプリケーションがオンラインになるために時間を延長する必要がある場合は、正常性チェックを使うことを検討してください。 時間の延長が必要になる一般的なパターンは、アプリケーションのウォームアップまたは起動中に外部リソースに大きく依存している場合です。
正常性チェックを使って、アプリケーションがまだ要求を受信できる状態でないことをプラットフォームに通知できます。 システムはその情報を使って、App Service プラン内の他のインスタンスに要求をルーティングできます。 このような場合は、プランに少なくとも 2 つのインスタンスを用意することをお勧めします。
アプリケーションはオンラインになりましたが、通知が表示されるようになって煩わしくなりました。 何が変更されましたか?
開始以降、更新とメンテナンス イベントがプラットフォームで発生しています。 更新の頻度は時間の経過とともに減少しているため、中断の数も減り、アップタイムも増加しています。 ただし、すべての変更をより詳しく把握できるようになっています。 可視性が向上すると、行われる変更が増えたように感じられる可能性があります。