Azure App ServiceのOSアップデートの背後にある魔法の神秘性を取り除く (Demystifying the magic behind App Service OS updates)

• Azure App Service Team Blog > Demystifying the magic behind App Service OS updates (2018/01/18)
  • https://blogs.msdn.microsoft.com/appserviceteam/2018/01/18/demystifying-the-magic-behind-app-service-os-updates/

---

さて、含みのあるブログ ポストのタイトルですね! ですが、こういうことなのです。Azure App ServiceがAzure App Serviceアプリをホストしているリソースをアップデートする際に、舞台裏で実際に何が起きているのかについて、我々は何度も質問されています。

まず、Azure App Serviceとは何かについて、手短に触れる必要があります。Azure App Serviceは、お客様が、基になる仮想マシンやほかのリソースの管理 (最新のセキュリティ アップデート、OS修正プログラムなど) を気にするのではなく、自分のコードに集中できるようにする、PaaS (サービスとしてのプラットフォーム) 機能です。

それでも、こういったリソースは、魔法のようにアップデートされるわけではありませんよね? これが、マネージド プラットフォームの利点です。我々が、お客様に代わってアップデートしているのです! Azure App Serviceは、リソースに月次アップデートを適用し、お客様のコードが常に、入手可能な最新のセキュリティ修正プログラム、OSバージョンの上で動作するようにします。一例として、最近、Spectre、Meltdown脆弱性が公開された際に、我々がアップデートしていることがお客様にとって極めて有益でした。サービスが自動的にアップデートされたので、お客様が行動を起こす必要はありませんでした。

さらなる技術的詳細を明らかにし、プロセスの神秘性を取り除く (分かりやすく説明する) ために、Azure App Serviceのアップデートが行われる際に何が起こっているのかを、ここで概説しましょう。ですが、まずは、いくつかの主要な概念を調べましょう。

• アプリ (または、サイト) – ユーザーのためにデプロイされたコードを管理する構造。
• インスタンス – コードをホストする仮想マシン。仮想マシンのメモリ、CPUなどにはバリエーションがあります。
• アップグレード ドメイン – アップデートの際にオフラインになる、特定のスケール ユニット内の一連のVM。
• スケール ユニット/スタンプ – 特定のリージョン内の一連の仮想マシン。
• リージョン (または、データセンター) – Microsoftが管理する一連の仮想マシンがある、世界中の地域。このブログの執筆時点では、Azureは世界中の42リージョンにデプロイされています。
• ペア リージョン – 同じGeo (地域) 内にあり、Azureが同時にアップデートしないことを保証している、2つのAzureリージョン。

Azure App Serviceのアップデート サイクル

何よりもまず、Azure App Serviceが、アップデートの間でさえも常にそのSLAを保証し維持していることに、注意することが重要です。加えて、緊急のセキュリティ問題や優先順位の高い軽減すべき問題がない限り、我々は、ローカルの業務時間内のアップデートを回避するように努めます。

我々は、世界中でアップデートを始める前に、一般にはアクセスできないプライベート リージョンに、最初にデプロイします。そこでテストが検証されて初めて、世界中のデータセンターに展開し始めます。

世界中でアップデートを完了する典型的な時間は、約10営業日です。この間に、我々は、各リージョンの業務時間外にデプロイし、また、同時にペア リージョン (たとえば、東日本と西日本) にデプロイすることを回避します。あなたが自分のアプリのインフラストラクチャの高可用性を計画し、複数リージョンにデプロイしようとしている場合は、常に自分の対象リージョンのペア リージョンにデプロイするのが、いいでしょう。なぜなら、アップデートでプラットフォームの問題が発生した場合、その問題はペア リージョンには影響を与えないからです。問題を回避して初めて、最初のリージョンのアップデートが完了した後に、ペア リージョンのアップデートに進みます。

我々は、マネージド サービスとして、新規リソースのために、既存リソースのスケーリング操作のために、インスタンスが異常になり、アプリを他のインスタンスに移動せざるを得ない場合に、そしてもちろん (ここで詳しく説明している) OSアップデート プロセスのために、キャパシティに常にバッファーを残しています。

• 自分のApp Serviceプランに割り当てられたマシン (リクエストは自動的に負荷分散されます)
• 他のお客様に割り当てられたマシン
• 新規アプリ、スケーリング操作、または (障害時の) 既存マシンの置き換えのためにすぐに使える、割り当てられていないマシン
• 通常運用時の、1つのスケール ユニットの表示

---

特定のリージョンでアップデートを行う際、我々は、アプリが動作していない利用可能なインスタンスをアップデートし、それから、アップデート済みのインスタンスにアプリを移動し、それから、アプリがなくなったインスタンスをアップデートします。

• 他のお客様に割り当てられたマシン
• 自分のApp Serviceプランに割り当てられたマシン (リクエストは自動的に負荷分散されます)
• 内部アップデートが行われているマシン (アプリは自動的にすぐに他の場所に移動されます)
• アップデートは各スケール ユニットで行われ、同時に1つのアップグレード ドメインだけがアップデートされます

---

この移動はコールド スタートを引き起こし、これに関連してパフォーマンスが低下がする場合があります。アプリケーションのバイナリが新しい仮想マシンにロードされ、ライブラリがディスクからロードされます。外部ユーザーに対して、アプリへのリクエストに対するレスポンスで1度限りの遅延が発生し、その後、サイトは正常に動作します。この遅延は多くのもの、主にアプリの複雑性、アプリが構築されているフレームワーク、依存関係に依存しています。このブログで詳しく説明されているように、アプリ初期化モデルを適切に構成することで、自分のアプリケーションのコールド スタートの影響を軽減できます。

お読みいただき、ありがとうございます。自分でAzure App Serviceを試したい場合は、クイックスタートの1つを使って最初のアプリを作成し、いかに簡単にアプリをデプロイできるかを確認し、すぐにコードを変更してください。

Azure App Serviceに関する質問がある場合は、MSDN、Stack Overflow上の開発者フォーラムを通して、我々に連絡してください。