Azure テクニカル サポートチームの鳥越です。
Azure をご利用いただいているお客様の中にはメンテナンスによる影響を経験された方もいらっしゃるかと存じます。
クラウド環境として、新機能の導入や更なる安定稼働を進めていく上で、このメンテナンスは必要不可欠なものです。
しかしながら、このメンテナンスといった言葉の中には、どのようなメンテナンスなのかがよくわからないといったご不安もあるかと推察します。
このような背景もあり、メンテナンスについて、またその影響について可能な限り補足させていただければと、このブログ記事を執筆しました。少しでも本内容がお客様のAzureに対する安心と信頼につながれば幸いでございます。
※ なお、今回は IaaS のメンテナンスを中心に記載しております。
■ そもそもメンテナンスとは何か ?
例えば、オンプレミス環境で言えば、ハードウェア廃止による機材の入れ替えや冗長化などの構成変更、物理的な電気系統の検査、サーバーやネットワーク機器のセキュリティを含む Firmware アップデートなどが該当するかと考えます。
余談ですが、私が以前、オンプレミス環境のサポートを行っていた際には、このような Firmware のアップデートは深夜の業務停止時間帯に数時間確保した上で計画的実施されておりました。しかし、この Firmware のアップデートは必ずうまくいくといった保証もなく、失敗した際のリカバリ対応も多く経験しました。
■ Azure 環境ではどのように考えるべきか ?
Azure 環境は、物理ホスト サーバー群とその上で複雑に制御された機能をつかさどる各プロセスが稼働しています。また、これらをつなぐネットワーク機器や物理ホスト サーバー群を管理するための機能といった様々なコンポーネントが存在します。
Azure では、定期的にこのようなプラットフォームを更新して、仮想マシン (VM) のホスト インフラストラクチャーの信頼性、パフォーマンス、セキュリティの向上に努めています。これらの更新の目的は、ホスティング環境のソフトウェア コンポーネントの新機能追加、修正から、ネットワーク コンポーネントのアップグレード、ハードウェアの使用停止まで、広い範囲に及びます。
■ どのようなメンテナンスがあるか ?
VM における再起動の有無により、大きく分けて、以下の 2 種類が考えられます。
- 再起動を必要とするメンテナンス
- 再起動を必要としないメンテナンス
■ 再起動を必要とするメンテナンスとは ?
再起動を必要とするメンテナンスは、計画メンテナンスとも呼ばれ、VM の再起動を伴うためにお客様に対して事前に通知が行われます。
セルフ サービス フェーズと呼ばれる準備期間内には、お客様の任意のタイミングにてメンテナンスを実施することができるため、メンテナンスに伴う VM 再起動による業務影響の発生を避けることが可能です。詳細については、下記公開情報をご確認ください。
参考文献) 再起動を必要とするメンテナンス
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-and-updates#maintenance-that-requires-a-reboot
参考文献) 計画メンテナンスの通知の処理
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-notifications
メンテナンスの目的としては、ソフトウェアや Firmware 更新、古いハードウェアの更新 (移行) 作業やネットワーク スイッチにおける機器の交換作業などが考えられます。
Note
ネットワーク スイッチにおける機器ついては、現在、ネットワーク スイッチの冗長性を上げて、仮に 1 つのネットワーク スイッチに問題が生じた場合にも、もう 1 つのネットワーク スイッチで問題なく配下の物理ホスト サーバーおよび VM が稼働を続けることができるよう、日々 Azure プラットフォーム側の改善に努めております。
■ 再起動を必要としないメンテナンスとは ?
Azure では、物理ホスト サーバー群とその上で複雑に制御された機能をつかさどる各プロセスが稼働しており、これらは新しいバージョンのリリースと共に更新が必要となります。これらの更新作業が、再起動を必要としないメンテナンスに該当します。
参考文献) 再起動を必要としないメンテナンス
https://learn.microsoft.com/ja-jp/azure/virtual-machines/maintenance-and-updates#maintenance-that-doesnt-require-a-reboot
ほとんどのプラットフォーム更新は、お客様の VM に影響しません。しかしながら影響を及ぼさない更新が不可能な場合、Azure は、お客様の VM への影響が最小となる更新メカニズム を利用して更新を行います。
■ 影響が最小となる更新メカニズムとは ?
Windows Azure から Azure に名前が変更された 2014 年頃には、物理ホスト サーバーのモジュールの更新であったとしても、メンテナンスとして物理ホスト サーバーの再起動が必要となる場合があり、メンテナンスに伴いお客様の VM は毎回数分間の停止が必要でした。
このようなお客様への影響を可能な限り最小限にするため、Azure は投資、開発、改善を行い続けている結果、多くのメンテナンスでほとんどお客様が影響を感じないメンテナンスを実現することが可能となりました。
再起動を必要としないメンテナンスとしては下記のようなものがございます。
参考文献) 影響がゼロまたは影響の少ないメンテナンス テクノロジの進化の変遷
https://azure.microsoft.com/ja-jp/blog/advancing-noimpact-and-lowimpact-maintenance-technologies/
参考文献) Advancing failure prediction and mitigation—introducing Narya
https://azure.microsoft.com/en-us/blog/advancing-failure-prediction-and-mitigation-introducing-narya/
プラン A: ホット パッチ
ホット パッチは、VM に一切ダウンタイムを生じさせることなく、物理ホスト サーバー上の実行中のプロセスに対して変更を行うことができるものであり、Azure では物理ホスト サーバーの更新プログラムを適用する際にできる限り使用しています。これは、物理ホスト サーバー上の機能を新たに呼び出す際、更新されたバージョンにリダイレクトすることで実現しています。
Azure では 2017 年からホット パッチを使用しており、それ以降、ホット パッチを使用できる範囲の拡大に取り組んでいます。たとえば 2018 年には、ハイパーバイザーに対してホット パッチが使用可能となりました。将来的には、さらなるカスタマー エクスペリエンスの向上のため、これまで “更新にはサーバーの再起動がつきもの” とされてきた Firmware への対応のため、ハードウェア メーカーと連携して検討を勧めています。
重要
ホットパッチのデモは、以下のビデオにて公開されています。
仮想化ホスト OS における特定のドライバーの置き換えが、人間には認識できないほどのわずかな時間にて成功しています。
このようなドライバーの更新は、たった 1 つのモジュールの置き換えであっても一般的な OS ではシステム再起動が
必須となっていたものですが、Azure OS ではこの一部についてはシステムを一切停止させずに更新していくことが可能となっています。
[YouTube] Inside Azure Datacenter Architecture with Mark Russinovich : Build 2018
大規模なホスト更新プログラムの中には、機能レベルのホット パッチでは適用できない変更が含まれているものもございます。それらの更新プログラムについては、メモリ保持メンテナンスを使用するようにしています。
プラン B: メモリ保持メンテナンス
メモリ保持メンテナンスでは、RAM 内のメモリを保持して VM を “一時停止 (Freeze)” し、物理ホスト サーバーの更新を実施します。更新完了後には VM を再開し、クロックを自動的に同期する作業を実施します。
Azure では 2018 年からメモリ保持メンテナンスを使用しており、それ以降、3 つの観点で機能の向上を図ってきました。1 つ目は、物理ホスト サーバーを再起動せずに更新が実施できるホスト コンポーネントを対象とした影響の少ないメモリ保持メンテナンスのバリエーションの開発、2 つ目は、VM で発生する一時停止時間の短縮、3 つ目は、メモリ保持メンテナンスによって更新できる VM の種類の拡充です。
重要
メモリ保持メンテナンスのデモは、以下のビデオにて公開されています。
3D グラフィックスによるリアルタイムな映像が表示されていますが、1 秒未満のゲスト VM の停止時間にて、ホスト OS 側のドライバーの更新を行うことに成功しています。
[YouTube] Inside Azure Datacenter Architecture with Mark Russinovich : Build 2018
警告
現状、メモリ保持メンテナンスはさまざまな技術的理由により、M、N、H シリーズなど特定の VM サイズ シリーズに対応できておりません。
このようなまれなケースでは、より影響の大きな (ホストの再起動や、VM の再展開などを伴う) メンテナンスを行う必要があるため、お客様には事前に通知し、それぞれのワークロードに適したタイミングでメンテナンスを実行できるようにしています。
■ メモリ保持メンテナンスについて
上記のように、ホットパッチでの対応が難しいものについてはメモリ保持メンテナンスが実施されます (逆に言うと、多くのメンテナンスがメモリ保持メンテナンスを用いずにホットパッチ機能を利用して更新が行われるように改善が進められました )。
ドキュメントにはこのメンテナンスは通常、最長で 30 秒間といった記載がございます。
この記載がメンテナンスは 30 秒間で必ず完了するものといった誤解を生むことにつながりました。
■ メンテナンス時間 30 秒間について
Azureをご利用いただく上で必要となるこれらのメンテナンスに対して、少しでもお客様に影響を与えないようカスタマー エクスペリエンスの向上を続けております。
その結果、メモリ保持メンテナンスであったとしても、ほとんどのメンテナンスで、99 パーセンタイル (P99) において Azure 基盤側の更新処理が 30 秒以内に完了できるようになりました。
Note
パーセンタイルとは、主に統計で使われる用語であり、最小値から並べてその値がどの位置にいるかを示す単位となります。
つまり P99 の場合、”99/100 番目の位置は 30 秒以内である” => “ほぼ 30 秒以内に終わる” ことを示しています。
しかしながら、100 % 完了とはなっておらず、お客様によっては、どうしても 30 秒以上の影響を受けてしまう状況が発生してしまうことは、現在に至っても避けられてはおりません。
メンテナンス内容によっても影響範囲が大きいもの、小さいものがございます。
例えば、ホスト サーバー上で動作するモジュールの置き換えであれば、ホットパッチまたは軽微なメモリ保持メンテナンスで解決いたしますが、ホスト サーバーのオペレーティングシステムの (カーネルを含むような) 更新を伴うような大きなメンテナンスの場合には、メモリ保持メンテナンスであったとしても、その影響が色濃く表れることもございます。
ご利用いただいている VM のオペレーティングシステムにより、古い Linux OS (カーネル) を利用されている場合には、想定以上にメンテナンスに対する影響の時間が長くなることもございます。
また、OS だけでなく、ネットワーク インフラストラクチャーにおける更新作業についても、OS やお客様の VM 自体を停止するものではありませんが、TCP/IP の自動的なリトライ ロジックを超えて瞬断が発生する可能性がございます。
メンテナンスの影響時間は適用される更新プログラムやその内容により大きく左右されるため、一概にメンテナンス全体で 30 秒間影響を受けるものでは無く、また影響の大きなメンテナンス (メモリ保持メンテナンス) であった場合、多くのお客様で 30 秒以内にメンテナンスが収まっていたとしても、100 % のお客様で 30 秒以内にメンテナンスが完了することをお約束することは叶いません。
Note
Azure Virtual Machine の SLA も、これらのメンテナンスの改善と関連し向上しています。
Azure において、2022 年 10 月現在、過去最後に VM の再起動を伴う大規模なメンテナンスを行ったものは、2018 年 1 月 3 日頃のものとなっております。
※ 一部リージョンのハードウェアの更改に伴い、VM の再起動を伴うメンテナンスが発生することは局所的に存在します。
このような背景から、2018 年 3 月には、Azure Virtual Machine の SLA からメンテナンスに関連するダウンタイムの除外を削除しています。
つまり、たとえ計画されたメンテナンスであったとしても、お客様の VM に分単位のダウンタイムをもたらした場合には、合計 SLA に影響するということとなっています。
参考文献) Virtual Machines の SLA
https://azure.microsoft.com/ja-jp/support/legal/sla/virtual-machines/v1_9/
参照箇所: バージョン履歴
1.7 最終更新: 2018 年 3 月
リリース ノート:単一インスタンス仮想マシンメンテナンスに関連するダウンタイムの除外を削除
Note
SLA ダウンタイムは分単位で計算されます。月間での合計 SLA がお客様の VM の稼働時間に対して 99.9 % (単一インスタンス / Premium SSD または Ultra ディスクの場合) を下回る場合に返金となります。
月間稼働率 (%) = (月内時間 (分) - ダウンタイム) / 月内時間 (分) x 100
■ おわりに
Azure では、引き続きメンテナンスに伴うお客様への影響時間短縮も含めたカスタマー エクスペリエンスの向上に尽力しています。また、将来を見据えて可用性と信頼性を確保するために機械学習ベースの洞察と自動化に多大な投資を行っています。
現時点では 30 秒程度との記載がございますが、このようなメンテナンスへの私たちの取り組みと、今後もより一層お客様が安心、信頼し Azure をご利用いただけるよう改善を続けていく思いを込めた記載であることをご理解いただけますと幸いでございます。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。