エキスパートに聞く! 未来を実現する IT インフラ

ERP（統合基幹業務システム）をはじめとしたミッション クリティカルなワークロードをクラウド上に移行する事例が増えている。一方でそのようなシステムを移行することは、クラウドサービスの障害が、会社全体のビジネス停止に直結してしまうのではないかという恐れを抱いている企業の声も聞こえてくる。マイクロソフトの米国本社組織に在籍し、「Microsoft Azure」の開発を担っている佐々木明夫氏は、こうした企業に対して次のように助言する。

こうした取り組みの好例が、システムへの電源供給体制だ。2018 年に米国のリージョンの近くで落雷が発生したことで、サービスの一部が停止するという事故が起こった。発電所からの電源供給が異常を来した結果、データセンター規模で障害が発生したためだ。こうした事故が 2 度と起こらないようにするために、現在は単一のリージョン、地域単位で区画されたデータセンター群において複数の電力供給源を使い分けているという。

ハードウエアの障害に対応するために、 サーバーやストレージに代表されるような Azure のシステム基盤そのものの冗長性も高めている。単一のデータセンター内では、ストレージを最低でも3重化しているという。東京と大阪のように、ペアのリージョンでは6重化されることになる。またシングル・ポイントオブ・フェィリヤ― (Single point of Failure) を回避するようHW整備、SW 機能はデータセンター間にまたがり備わっている。リージョン間のネットワーク等、それ以上の多重化が図られている領域もあるという。顧客は特別な要望を行わなくとも、Azure を利用している時点で、この冗長化の恩恵が受けられていると言えるだろう。佐々木氏は「Azure はお客様のデータの保全を最優先に考えており、全てのシステムを  3重化あるいは 6 重化しています。システムの障害に起因してデータが失われる可能性は極めて低くなっています」と解説する。Azure のストレージでは冗長オプションを選択できるが、指定された1年間にわたってオブジェクトの持続性は「ローカル冗長ストレージ  (LRS)」を選択した場合は99.999999999% (イレブンナイン) 以上、「geo ゾーン冗長ストレージ (GZRS)」を選択した場合には 99.99999999999999% (シックスティーンナイン) をそれぞれの構成で提供する。

既存サービスの日常的なアップデートを含めた更新作業についても、「SAFE デプロイメント」と名付けられた多様な検証が行われている。Azure  のサービスに行われる全ての設定やコード変更は、まずは本番用と同一の構成、運用規模を備えたテスト専用のリージョンで検証が行われる。ここで、実際の顧客の使い方と同じ構成で検証が行われる。この構成は、合計で数十万通りにも及ぶという。なかには、実際に障害が報告された環境をソフトウエアでエミュレートする構成も含まれるという。ここで一定時間、安定稼働した後に、最新機能を求める顧客向けの「アーリーリージョン」での提供を開始。ここで不具合が発生しなかった場合に、ようやく Azure 全地域展開に移される。この段階でもただちに全てのリージョンに一気に展開するわけではない。ペアリージョンのどちらかのリージョンでの安定稼働を確認した後に全てのリージョンで提供を開始するというプロセスを経ることになる。このプロセスのいずれかで、不具合が発生すれば、振り出しに戻ることになる。

その他にも、現在は、AI (人工知能) を駆使して、物理ディスクに対する障害の予兆検知も行っている。過去に障害が発生した際のログやデータなどを機械学習で分析。この学習結果から、どのディスクに障害が発生するかの予兆を検知することが可能になった。障害の予兆を検知した場合には、マイクロソフトがデータを別のディスクに移動したりするなどの対応を行っている。障害が予期されたディスクについては顧客データを全て移した後も稼働を継続させ、実際に問題が発生するまでのデータを得て機械学習の学習データに利用する徹底ぶりだ。将来的には予兆検知の情報の一部は、「Azure ヘルスレポート」の機能の一部として情報を取得できるようにすることも計画されているそうだ。

Azure 自体のメンテナンスのインパクトを最小化することにも取り組んでいる。仮想マシンのメンテナンスを行う際には、仮想マシンを一瞬だけ凍結した状態にしてその後に復旧させる「インプレース」と、仮想マシンの稼働を停止せずに別のハードウエアに移動させる「ライブマイグレーション」の2種類がある。インプレースでは標準的には 10 秒程度、最大で 30 秒程度の停止時間があり、クラウドでの稼働を意識したアプリケーションであれば問題にならないことも多い。一方で、バッチジョブのような処理についてはこの停止時間が問題となることもあるという。

Azure では従来、メンテナンス時にはインプレースを採用していた。ライブマイグレーションは、サービスが継続するものの稼働するハードウェアが変わることによる潜在的なリスクが存在するためだ。現在は、リスクを軽減する技術を開発したことで、ライブ マイグレーションの割合が大きく増やしてメンテナンス時のインパクトを最小化している。

2019 年 6 月に開催したイベント「Build」では、将来へ向けた革新的なプロジェクトに取り組んでいることが公表された。不死に近い緩歩動物門である「Tardigrade (クマムシ)」の名を冠した、このプロジェクトではハードウエアの一般的な障害が発生した場合でも、ほぼ無停止で復旧できる技術の開発を目指している。ハードウエアが物理的に壊れた瞬間に、メモリー上に保持されているデータのスナップショットを利用して、別のハードウエアに数秒の内に移動するというしくみだ。

こうした一連の取り組みによって、 Azure の可用性は今後も高まっていくことは確実だ。しかし、ユーザーにとってみると、ここに落とし穴がある。柳瀬氏は、次のように警鐘を鳴らす。

「クラウドの信頼性が飛躍的に高くなったので、最近はシステムを (冗長性を確保せずに) シングル構成で稼働させている企業も散見されるようになってきました。しかし、どれだけ技術が進化しても、クラウドの稼働率が SLA として 100％ が保証されることはありません。可用性セットや可用性ゾーンに代表される機能を理解いただき、アプリケーションの重要度に応じて、適切な冗長構成をとる必要があることを認識することがより重要になっていくでしょう」