影響がゼロまたは影響の少ないメンテナンス テクノロジの進化の変遷

2020年1月3日 に投稿済み

Chief Technology Officer, Microsoft Azure

「この記事では、7 月のブログ記事 (英語) からスタートした「信頼性」シリーズを引き続きお届けし、信頼できる一連のクラウド サービスの提供を目指す当社の取り組みの一環として、プラットフォームの可用性の継続的な向上を目的とした進行中のイニシアチブをいくつかご紹介します。今回は、ホット パッチや、メモリ保持メンテナンス、ライブ マイグレーションといった、影響ゼロまたは影響の少ない更新テクノロジに対して当社が行った投資について取り上げたいと思います。この 1 年、当社はセキュリティや信頼性に関連する何十件ものパッチをホスト インフラストラクチャに展開してきましたが、その多くはお客様への影響やダウンタイムが生じることなく実施されました。本記事の以降の内容は、当社のコア オペレーティング システムズ チームの John Slack によって執筆されたもので、John は以下で説明されている更新テクノロジのいくつかを担当したプログラム マネージャーでもあります。」- Azure 担当 CTO、Mark Russinovich


この記事は、これらのテクノロジを担当するエンジニアリング チームの Apurva Thanky、Cristina del Amo Casado、Shantanu Srivastava の共著によるものです。

 

当社は Azure のホスト インフラストラクチャの信頼性、パフォーマンス、およびセキュリティを向上させるために、定期的に更新を行っています。それらの "メンテナンス" 更新の目的はさまざまですが、通常はホスティング環境内のソフトウェア コンポーネントの更新やハードウェアの使用停止に関するものです。5 年前に遡ると、それらの更新プログラムの中には、ホスト全体を完全に再起動するしか適用できないものもありました。この方法では、お客様の仮想マシン (VM) を毎回数分間停止しなければなりませんでした。それ以来、当社は仮想マシンの更新時にお客様が受ける影響を最小限に抑えるべく、さまざまなテクノロジに投資してきました。現在、ホスト オペレーティング システムに対する更新の大多数が、ホット パッチよって完全な透明性を確保した、お客様への影響のない方法で展開されています。また、更新プログラムのホット パッチを実行できないまれなケースでは、通常、更新プログラムのロールアウトに、影響の少ないメモリ保持更新テクノロジを利用しています。

これらのテクノロジをもってしても、より影響の大きなメンテナンスを実施する必要のあるケースがまれに発生します (不具合のあるハードウェアの排除や、古いハードウェアの使用停止など)。そのようなケースでは、ライブ マイグレーション、VM 内通知、および計画メンテナンスを組み合わせて使用して、お客様による制御を可能にしています。

この領域に対する継続的な投資により、当社は、ホストのメンテナンス作業の大多数が対象インフラストラクチャ上でホストされている VM に影響を及ぼさないところまでくることができました。本稿では、Azure の更新の影響を最小限に抑えるために当社が使用するさまざまな手法についてわかりやすく説明したいと思います。

プラン A: ホット パッチ

機能レベルの "ホット" パッチでは、お客様の VM に一切ダウンタイムを生じさせることなく、実行中のコードに対して目的の変更を行うことができます。そのためにホスト上の特定の機能の新たな呼び出しはすべてリダイレクトされるので、"影響がゼロ" の更新テクノロジと見なされています。当社ではホストの更新プログラムを適用する際にできる限りホット パッチを使用して、そのホスト上で実行されている VM に影響が及ぶことを完全に回避しています。Azure では 2017 年からホット パッチを使用しています。それ以降、ホット パッチを適用できる範囲を広げるべく取り組んでいます。たとえば 2018 年には、ハイパーバイザーのホット パッチを可能にするためにホスト オペレーティング システムの更新を行いました。将来的にはファームウェアのホット パッチを検討しています。これはまだ業界で一般的に注目されていない領域です。これまでファームウェアは常に "更新にはサーバーの再起動がつきもの" とされてきましたが、当社はそれがカスタマー エクスペリエンスを著しく損なってしまうことを承知しています。そのため、ハードウェア メーカーと連携して、独自のファームウェアをホット パッチ可能な、徐々に更新できるものにすることを検討してきました。

大規模なホスト更新プログラムの中には、機能レベルのホット パッチでは適用できない変更が含まれているものもあります。それらの更新プログラムについては、メモリ保持メンテナンスを使用するようにしています。

プラン B: メモリ保持メンテナンス

メモリ保持メンテナンスには、ゲスト VM を "一時停止" して (そのメモリは RAM で保持)、ホスト サーバーの更新を行ってから、VM を再開し、それらのクロックを自動的に同期する作業が含まれます。Azure で初めてメモリ保持メンテナンスを使用したのは、2018 年のことです。それ以降、3 つの重要な方法でこのテクノロジの向上を図ってきました。1 つ目は、ホストを再起動せずに実施できる、ホスト コンポーネントを対象とした影響の少ないメモリ保持メンテナンスのバリエーションの開発、2 つ目は、お客様で発生する一時停止時間の短縮、3 つ目は、メモリ保持メンテナンスによって更新できる VM の種類の拡充でした。当社ではこの領域での取り組みを続けていますが、さまざまな技術的理由で、今もメモリ保持メンテナンスの一部のバリエーションは、M、N、H シリーズの VM など特定の専用 VM オファリングに対応していません。

このようなまれなケースでは、より影響の大きな (ホストの再起動や、VM の再展開などを伴う) メンテナンスを行う必要があるため、お客様には事前に通知し、それぞれのワークロードに適したタイミングでメンテナンスを実行できるようにしています。

プラン C: セルフサービス メンテナンス

セルフサービス メンテナンスには、お客様とパートナー様に猶予期間を提供して、その期間中に各自が VM で影響の大きなメンテナンスを開始するタイミングを選べるようにする作業が含まれます。通常、この最初のセルフサービス フェーズは 1 か月程度設けられ、ユーザーの混乱を回避する、あるいは最小限に抑えるために組織が各自のスケジュールでメンテナンスを実行できるようにしています。このセルフサービス期間が終わると、予定メンテナンス フェーズが始まります。このフェーズでは、Azure 側でメンテナンスが自動的に実行されます。この 2 つのフェーズ全体を通して、お客様はどの VM が更新されたか、あるいは更新されなかったかを、すべて Azure Service Health 内で、または PowerShell/CLI でクエリを実行して確認できます。Azure では 2018 年に初めてセルフサービス メンテナンスを提供しました。管理者は Azure によって自社の VM に対するメンテナンスが自動的に実行されるのを待つよりも、セルフサービス フェーズを利用することが一般的です。

また、お客様が Azure Dedicated Host分離された仮想マシンのいずれかを使って完全なホスト マシンを保有されている場合のために、当社は最近、あらゆる影響ゼロのプラットフォーム更新プログラムに対するメンテナンス制御機能の提供を開始しました。それには、数秒の一時停止しか発生しない、再起動不要の更新プログラムが含まれます。これは、わずか数秒の中断さえ許容できない極めて要件の厳しいワークロードを実行する VM に役立ちます。お客様は、35 日のローリング ウィンドウで、それらの影響ゼロの更新プログラムを適用するタイミングを選択できます。この機能はパブリック プレビュー中で、詳細についてはこちらの専用ブログ記事 (英語) でご確認いただけます。

ホストでハードウェアの劣化の兆候が見られるなど、場合によってはインプレース更新テクノロジが実行できないことがあります。そのようなケースでの最善策は、計画メンテナンスを利用したお客様による制御か、ライブ マイグレーションのいずれかで、VM を別のホストに移動する作業を開始することです。

プラン D: ライブ マイグレーション

ライブ マイグレーションには、お客様の実行中の VM を "移行元" ホストから別の "移行先" ホストへと移動する作業が含まれます。ライブ マイグレーションではまず、VM を引き続き実行しながら、VM のローカル状態 (RAM やローカル ストレージなど) を移行元から移行先へと移動します。ほとんどのローカル状態を移動すると、ゲスト VM で通常 5 秒以下の短い一時停止が生じます。その一時停止の後、VM の実行が移行先ホストで再開されます。Azure で初めてライブ マイグレーションの使用を開始したのは、2018 年のことです。今では、Azure Machine Learning アルゴリズムによってハードウェア障害の兆候が検出されると、ライブ マイグレーションを使ってゲスト VM を異なるホストに事前に (英語) 移動できるようになっています。

Igal Figlin が最近行った Ignite 2019 のセッション「Building resilient applications in Azure」では、他のトピックの中で、計画メンテナンスと AI オペレーションについて取り上げられました。詳細については、こちら (英語) の録画をご覧ください。また、本質的に回復力の高いアプリケーションをお客様が構築する際に役立つ、Azure が提供する各種の回復サービスを利用する方法についても、詳細をご確認ください。

将来の Azure でのメンテナンス 

まとめると、Azure でメンテナンスを実行する方法は、適用される更新プログラムの種類によって大きく左右されるといえます。詳細にかかわらず、常に Azure のメンテナンスに対するアプローチでは、お客様のワークロードへの影響をできる限り最小限に抑えることを念頭に置いています。本稿では、この目標を達成するために当社が使用しているテクノロジのいくつかについて大まかに説明しましたが、引き続きカスタマー エクスペリエンスの向上に尽力しています。また将来を見据え、可用性と信頼性を確保するために機械学習ベースの洞察と自動化に多大な投資を行っています。ゆくゆくはこの "AI オペレーション" モデルで、予防メンテナンスを実施し、自動マイグレーションを開始して、インシデントの発生時に人間のエンジニアよりも効果的に要因と依存関係を特定できるようにする予定です。学習と進化を続ける中で、これらのトピックについてさらなる情報をお知らせできることを楽しみにしています。