Zenn
Microsoft (有志)Publicationへの投稿
🍔

Azureのメンテナンスの進化 (MS Build 2025 : Inside Azure innovations)

Masato Ueda
に公開
Azure
availability
Microsoft
MS Build
VM
tech

はじめに

Azure ホストOS の更新は、セキュリティを確保し、新しいハードウェアの世代をサポートしたり、Azure Confidential Computing などの新機能を提供したりするために必要不可欠なプロセスです。 ホストOS を更新する際に ホスト上で実行されている VM が影響を受けてしまうことがどうしてもありますが、それでも、その影響は年々小さくなるようメンテナンス技術が進歩している、というお話です。

MS Build 2025 のこちらのセッション( Inside Azure innovations with Mark Russinovich | BRK195 )で、Azure のメンテナンスの進化について紹介している箇所があります。

メンテナンスは、Azure の仮想マシンを運用する上で重要なトピックで、ご質問を頂くことも多いので、この Build セッション の内容を踏まえつつ、もう一段深めに、まとめておきます。

紹介されたメンテナンス手法

セッションでは、以下のようにメンテナンス手法が整理されていました。

Build 2025 : Inside Azure innovations with Mark Russinovich | BRK195 で紹介されていたスライド

少し概要もつけて補足すると以下のような感じです。

メンテナンス技術 予想停止時間 概要
Microcode update ほとんど中断なし CPU のマイクロコードアップデート。影響はほぼない。
Hot patch < 20ms セキュリティ更新や軽微な機能を対象に、修正コードを on memory 上に展開して修正し、再起動不要で更新する手法
Driver hot swap < 1 s 新/旧ドライバを並行稼働させ、徐々に旧ドライバから新ドライバに処理を移してから旧ドライバをアンロードすることで、更新影響を抑える手法
Hypervisor Hot Restart < 1 s ハイパーバイザーを同一ホスト上に新/旧並行稼働させ、VM を新ハイパーバイザーへミラーリングしてから切り替える形で更新することで、影響を抑える手法
live migration < 2 s ハードウェア自体のメンテナンス等の際に、別のホストへ VM を移動させることで、メンテナンス影響を抑える手法
VM-PHU UltraLite < 3 s ホストの再起動無しにコンポーネントを更新し、VM のメモリマッピングを保持したまま高速にホストの更新を行う手法
VM-PHU Self < 20 s Kernel soft reboot (KSR) を使用してホストの再起動を行い、旧OSから新OSへメモリを受け渡すことで VM メモリ内容を保持したまま更新する手法
Full reboot Many minutes 全体の再起動を伴うメンテナンス。VM は大きな影響を受ける

それぞれのメンテナンス手法について、もう少し詳しく見てみます。

Microcode update と Full reboot

Azure のサービス開始当初は、"Microcode update" と "Full reboot" のメンテナンスがありました。 CPU の マイクロコードアップデート は影響はほぼありませんでしたが、"Full reboot" すなわちホストの再起動を伴うメンテナンスでは、VM は大きな影響を受けてしまっていました。そのため、以下のような新たなメンテナンス手法が導入をされてきており、現在では、いずれの手法も取れない場合にやむなく、再起動を伴うメンテナンスが実行される形になっています。

なお、計画メンテナンスで VM の再起動が必要な場合には、事前に通知が行われます。Azure Portal の サービスの正常性 で確認したり、の Azure Service Health で通知を受けたりできます。通常は 4 週間程度 "セルフ サービス フェーズ" があるので、期間中に ユーザー ご自身のタイミングでVM を再起動させ、更新済みのホストへ移すことができます。

Live migration

"Live migration" は、メンテナンス対象ホスト上の VM の各種状態を別のホストへとレプリケーションさせ、ある時点で静止点を取って切り替え、メンテナンス対象ホスト 上の VM を無くしていく手法です。
ホストのメンテナンスの際には必ず ライブマイグレーション をしているという勘違いもたまにあるのですが、ライブマイグレーションにはいくつか欠点があり、ハードウェア自体をメンテナンスしたり、BIOS を更新したりなどの場合に利用されているイメージです。欠点としては、 VM は移動中にパフォーマンスが若干影響を受けます。また、移動先の別ホストが必要であることから、VM を大規模に Live migration するときに、それを受け止める同じタイプのホストを用意する困難さも伴っています。G、L、N、H シリーズ のような VM では行われていなかったりします。M シリーズは大規模なメモリを持つ VM シリーズのため 一部 SKU のみ、 制限付きサポート となっています。

2025/06 現在の M シリーズ の Live migration サポート状況

サポートされていない

制限付きサポート

Hot patch


Ignite 2017 : Inside Microsoft Azure datacenter hardware and software architecture with Mark Russinovich で紹介されていたスライド

"Hot patch" は、セキュリティ更新プログラムや、軽微な機能の修正などを適用できます。セキュリティや機能に関係する function の更新版をホストのメモリ上に展開をし、該当機能の新しい呼び出しがあった際には、更新バージョンにリダイレクトをすることで、再起動をせずに機能の更新ができるものです。

かなり古いですが、2017年 Ignite の中で、デモを交えて紹介されています。Bug のあるドライバにより本来のネットワーク性能が発揮できていない状態から、Hot patch 適用による機能のバグ修正によって、瞬時に性能が跳ね上がるというデモです。

ちなみに現在では、 Azure の ホストOS のみならず、普段利用する可能性のある Windows Server/Client OS でも、Hot patch が利用できるようになっています。

Hypervisor Hot Restart


Inside Azure Innovations with Mark Russinovich | BRK214H で紹介されていたスライド

"Hypervisor Hot Restart" は 2022年頃から導入された技術で、ハイパーバイザーの更新の際の VM ダウンタイムを削減します。

古いハイパーバイザーとは別に更新を適用した新規のハイパーバイザーを作成し、VM など各種状態をレプリケーション/ミラーリングしたのちに古いハイパーバイザーを削除する、といった方法で、ハイパーバイザー上の VM への影響を、ハイパーバイザー同士を切り替える ブラックアウトの瞬間 (数百 ms ) のみに抑えるというものです。
これにより、新しい機能を備えた新しいハイパーバイザー バージョンのデプロイが、VM のダウンタイムほぼなしに実現できています。

より詳しくはこちらで紹介されています。

また以下 2022年の Ignite のセッションでは、デモも紹介されています。

Driver hot swap

最近登場した技術として、"Driver hot swap" が紹介されていました。

新しいバージョンのデバイスドライバーを kernel 上に読み込み、プロキシスタブ の背後に 古いドライバー と並んで稼働させます。プロキシスタブは、新たなリクエストを新しいドライバーの方へルーティングしていくので、徐々に古いドライバーを利用するものが減っていきます。古いドライバーを利用しているものがなくなったタイミングで、古いドライバーをアンロードすることで、ほぼ影響なく更新を完了できる、という手法です。

VM-PHU UltraLite と VM-PHU Self

メモリ保持メンテナンス（VM-PHU : Virtual Machine - Preserving Host Update) は、ゲストVMのメモリ内容をディスクに書き出さずにホストのRAM上に保持して、ホストの更新中も VM の状態を維持する(VMは再起動しない)メンテナンスです。


ネットワークやストレージI/O を行っている VM でも無停止で VM-PHU できる、Build 2025 : Inside Azure innovations with Mark Russinovich | BRK195 で紹介されていた、スライド

今回 2025年 Build のセッションでは、 仮想プロセッサの自動サスペンド機能と、仮想機能のキープアライブ機能を利用することで、ネットワークやストレージI/O を行っている VM でも停止することなくメンテナンスが実施できるようになっていることが、説明されました。また、実際に、VM 間の Ping 等が無停止のままアップデートする デモ も披露されました。

VM がハイパーバイザーの仮想スタックを利用している場合にはやはり一時停止を伴うようですが、ますます影響を受けづらくなっているようです。

なお、WM-PHU ultra light では、ホストOS や ハイパーバイザー 自体の再起動はしません。ホスト再起動無しで更新可能なコンポーネントを停止し、更新できます。後述の self よりも狭い範囲を扱うイメージです。Ultra-Lite は、再起動をしないため、VM を一時停止させる場合にもメモリマッピングを保持したまま更新を実施でき、一時停止からもより早く復旧できます。なお、実は VM-PHU Lite もあり、Ultra-Lite よりもさらに広いネットワークスタックとストレージスタック等を含む仮想化スタックの範囲の更新を行うことができます。

VM-PHU Self は、より重い処理を伴うVM-PHU方式で、 kernel soft reboot (KSR) を使用してホストの再起動を行い、更新を適用します。
KSR による再起動は通常の再起動とは異なり、ハードウェアの電源断を伴わず、旧カーネルが新カーネルを起動する際にゲストVMのメモリ内容を含む特定のメモリ領域を新しいOSに引き継ぐことが可能なため、仮想マシンのメモリの内容を保持しながらホストの更新ができます。

今回取り上げていない VM 以外のメンテナンスもある

今回の説明は、下記のような一段階視点をあげた図の中では Server #01 のような個々のホストに関するメンテナンスの話であり、Top of Rack の Switch や、その先にある関連ハードウェア類においても、日々メンテナンスが行われています。


Azure データセンター 内での ホスト の配置のイメージ

また、通常システムを構築する場合には、 Azure VM のみでシステムが構成されていることはありません。
ExpressRoute や Azure Firewall 等のネットワーク周りのサービスであったり、Azure SQL Database などのPaaS のサービスも合わせて利用されているはずです。これらのサービスにおいても、メンテナンスは行われています。

まとめ

今回は MS Build 2025 のセッションを参考に、Azure の ホスト において実施されているメンテナンスの進化についてまとめてみました。

Servicing tool Expected pause 概要
Microcode update Nearly no disruption CPU のマイクロコードアップデート。影響はほぼない。
Hot patch < 20ms セキュリティ更新や軽微な機能を対象に、修正コードを on memory 上に展開して修正し、再起動不要で更新する手法
Driver hot swap < 1 s 新/旧ドライバを並行稼働させ、徐々に旧ドライバから新ドライバに処理を移してから旧ドライバをアンロードすることで、更新影響を抑える手法
Hypervisor Hot Restart < 1 s ハイパーバイザーを同一ホスト上に新/旧並行稼働させ、VM を新ハイパーバイザーへミラーリングしてから切り替える形で更新することで、影響を抑える手法
live migration < 2 s ハードウェア自体のメンテナンス等の際に、別のホストへ VM を移動させることで、メンテナンス影響を抑える手法
VM-PHU UltraLite < 3 s ホストの再起動無しにコンポーネントを更新し、VM のメモリマッピングを保持したまま高速にホストの更新を行う手法
VM-PHU Self < 20 s Kernel soft reboot (KSR) を使用してホストの再起動を行い、旧OSから新OSへメモリを受け渡すことで VM メモリ内容を保持したまま更新する手法
Full reboot Many minutes 全体の再起動を伴うメンテナンス。VM は大きな影響を受ける

様々な改善が行われ、メンテナンスの影響を受けることは減ってきています。
とはいえ、メンテナンスの影響を完全に避けることは、現時点ではまだできません。その他の障害への備えとしても、今回ご紹介したメンテナンスの観点からも、影響を受けないように、アプリケーションを改修したり、可用性セットや可用性ゾーンを利用するなど VM の配置を工夫したりして、システム全体として影響を受けないように構成することが重要です。

また、project flash というAzure 仮想マシンの可用性の監視を進化させる取り組みもあり、メンテナンスの影響を受けたかどうかを確認などもできるようになっています。そちらはサポートチームの blog もあるので、リンクを貼っておきます。また、Support チームで Azure IaaS VM で実施されるメンテナンスについてご紹介している blog もあります。

参考： メンテナンス影響が許容できない・メンテナンスをコントロールしたい場合 → Dedicated Host

メンテナンスの影響が許容できない場合、お客様専用のホストを用意するサービスである Azure Dedicated Host が選択肢の一つです。Dedicated Host は、他のお客様とワークロードを出来ないといったコンプライアンスの要件がある場合や、メンテナンスを制御したいといった場合に利用されるサービスです。

とはいえ、その導入は、通常の共用ホストに比べて遥かにコストがかかり、また独自の考慮（デプロイ可能 VM の制限や、独自のサイジング、可用性の確保の為に複数の Dedicated Host を用意する必要があるなど）も必要となります。そのため、基本的には メンテナンスの影響を許容できるようにアプリケーションの改修等を行う方が、良い選択肢だと思われます。

参考リンク

Microsoft (有志)
Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion