次の方法で共有

Azure App Service の定期的な (計画) メンテナンス

  • [アーティクル]

定期的なメンテナンスでは、バックグラウンドで Azure App Service の更新が行われます。 メンテナンスの種類には、パフォーマンスの向上、バグ修正、新機能、セキュリティ更新プログラムなどがあります。 App Service のメンテナンスは、サービス自体または基になるオペレーティング システムで行うことができます。

重要

機能の破壊的変更または非推奨化は、定期的なメンテナンスには含まれません。 詳しくは、「Modern Lifecycle ポリシー」をご覧ください。

Microsoft サービスの品質とアップタイムの保証は、メンテナンス期間中も引き続き適用されます。 お客様がプラットフォームの変更を確認できるよう、お知らせにはメンテナンス期間が記載されています。

予期される事柄

パソコン、携帯電話、その他のデバイスと同様に、クラウド内のマシンにも最新の更新プログラムが必要です。 物理デバイスとは異なり、Azure App Service のようなクラウド ソリューションには、定期的なメンテナンスをより簡単に処理する方法が用意されています。 作業を止めて、パッチがインストールされるまで待つ必要はありません。 更新プログラムがインストールされている間は、任意のワークロードを数秒で異なるハードウェアに移行できます。 更新は毎月行われますが、組織のニーズや他の要因によって変わる場合があります。

一般的なクラウド ソリューションは複数のアプリケーション、データベース、ストレージ アカウント、機能、その他のリソースで構成されているため、ソリューションの部分のメンテナンスは異なるタイミングで行われる可能性があります。 この調整の一部は、地理的地域、リージョン、データセンター、Availability Zones に関連しています。 また、すべてが同時に操作されるわけではないクラウドが原因である場合もあります。 詳しくは、「安全なデプロイ プラクティス」をご覧ください。

次のスクリーンショットは、メンテナンス イベントの例を示したものです。

Azure portal でのメンテナンス イベントのスクリーンショット。

この例では、上から下に順番に次のものが示されています。

  • メンテナンス イベントのわかりやすいタイトル。
  • 影響を受けるリージョンとサブスクリプション。
  • 予想されるメンテナンス期間。

よく寄せられる質問

メンテナンスにこれほど時間がかかるのはなぜですか?

基本的に、定期的なメンテナンスでは、プラットフォームとサービスに最新の更新プログラムが提供されます。 メンテナンスによって個々のアプリが受ける影響を特定の時間まで予測するのは難しいため、通知はより一般的になる傾向があります。 通知の時間範囲には、アプリ レベルでのエクスペリエンスではなく、すべてのリソースについての全体的な操作が反映されます。 メンテナンスの対象になったアプリは、新たに更新されたマシンですぐに再起動して、動作を続けます。 要求やトラフィックが提供されないときは、ダウンタイムは発生しません。

非常に多くの通知を受け取るのはなぜですか?

一般的なシナリオでは、お客様は異なるタイミングでアップグレードされる複数のアプリケーションを使っています。 それぞれについて個別に通知が送られるのを避けるため、複数のリソースを対象とする 1 つの通知が送られます。 通知は、メンテナンス期間の最初と全体を通じて送られます。 時間枠が長い場合、同じロールアウトに対して複数のリマインダーを受け取る可能性があるため、再起動、中断、またはその他の問題をより簡単に関連付けることができます。

プラットフォームのメンテナンスが、アプリケーションのアップタイムや可用性に影響を与えることはないはずです。 プラットフォームのメンテナンスが行われる間、アプリケーションは引き続きオンラインのままです。

プラットフォームのメンテナンスが原因で、アプリケーションが新しい仮想マシンでコールド スタートし、遅延が発生する可能性があります。 コールド スタートの間も、アプリケーションはやはりオンラインであると見なされます。 コールド スタートを最小限に抑えるか避けるため、Windows アプリのローカル キャッシュと正常性チェックを使うことを検討してください。

メンテナンス期間中にサイトでサービス レベル アグリーメント (SLA) 違反が発生することは想定されていません。

アップグレードではアプリの円滑な動作がどのように保証されますか?

Azure App Service は、Web アプリケーションとソリューションのホスティングをお客様に提供するスケール ユニットのフリートを表します。 各スケール ユニットは、アップグレード ドメインと可用性ゾーンに分割されます。 この分割により、各スケール ユニット内のすべてのマシンが一度に更新されることがなくなるため、より大きな App Service プランの配置とスムーズなデプロイが最適化されます。

メンテナンス操作では、App Service によってフリートの正常性が監視されながら、マシンのアップグレードが繰り返されます。 問題が発生した場合、システムはロールアウトを停止できます。 このプロセスについて詳しくは、ブログ記事「 App Service OS の更新の背後にある魔法の謎を解き明かす」をご覧ください。

営業時間は反映されますか?

はい。営業時間はリージョンのタイム ゾーンに反映されます。 メンテナンス操作は、午前 9 時から午後 5 時までの標準の営業時間外に始まるように最適化されています。 統計上、そうすれば (お客様のアプリケーションでも、推移的にプラットフォーム自体でも) システムに対するストレスが少ないため、これはワークロードの中断と再起動に最適なタイミングです。 特定のリージョンで午前 9 時になってもリソースのアップグレードがまだ行われている場合、アップグレードは、次の重要なステップの前で、営業時間の終わりまで安全に一時停止します。

定期的なメンテナンスを制御するにはどのようなオプションがありますか?

App Service Environment v3 を使って分離された製品でワークロードを実行している場合は、必要に応じてアップグレードをスケジュールできます。 この機能について詳しくは、ブログ記事「App Service Environment v3 の計画メンテナンスの制御と自動化」をご覧ください。

再起動に備えてアプリをよりよく準備できますか?

再起動の際にアプリケーションがオンラインになるために時間を延長する必要がある場合は、正常性チェックを使うことを検討してください。 時間の延長が必要になる一般的なパターンは、アプリケーションのウォームアップまたは起動中に外部リソースに大きく依存している場合です。

正常性チェックを使って、アプリケーションがまだ要求を受信できる状態でないことをプラットフォームに通知できます。 システムはその情報を使って、App Service プラン内の他のインスタンスに要求をルーティングできます。 このような場合は、プランに少なくとも 2 つのインスタンスを用意することをお勧めします。

アプリケーションはオンラインになりましたが、これらの通知が表示され始めて以来、事態は悪化しています。 変更箇所

更新とメンテナンス イベントは、開始以来プラットフォームで発生しています。 更新の頻度は時間の経過と共に減るため、中断の数も減り、アップタイムが増えます。 ただし、すべての変更をより詳しく把握できるようになっています。 可視性が向上すると、行われる変更が増えたように感じられる可能性があります。

次のステップ

メンテナンス通知について詳しくは、ブログ記事「Azure App Service に関する定期的な計画メンテナンスの通知」をご覧ください。