サービスの復旧:仮想マシンの自動復旧のしくみ
このポストは、4 月 7 日に投稿された Service Healing – Auto-recovery of Virtual Machines の翻訳です。
Microsoft Azure は約 7 年前の PDC 2008 で初めて発表され、パブリック プレビュー版のころからプラットフォーム上での仮想マシンの正常性を検出する手段と障害発生時に自動復旧を実行するための手段が提供されてきました。この自動復旧プロセスは、サービス インスタンスを「復旧 (heal)」する手段であることから、「サービスの復旧 (Service Healing)」と呼ばれています。マイクロソフトはサービスの復旧 (自動復旧) を、クラウド上でビジネス クリティカルなワークロードを実行するための不可欠な要素と考えています。そのため、この自動復旧のしくみは VM サイズやサービス、Azure リージョン、データセンターを問わず、すべての仮想マシンで利用することができます。この記事では、障害発生時における Azure 上でのサービスの復旧と自動復旧のしくみについてご説明します。
障害復旧で重要なのは、障害発生の最初の検出時です。障害が発生してから検出するまでの時間が早いほど、仮想マシンのダウンタイムが短くなります。この時間は、MTTD (Mean Time To Detect: 障害検出までの時間) とも呼ばれます。Microsoft Azure クラウド オペレーティング システムのカーネルであるファブリック コントローラーが、実装されている複数のプロトコルに従い、すべての仮想マシンの状態と実行されているコードの状態 (Web ロールまたは Worker ロールの場合) を確認します。
次の図は、障害が発生し得るシステム内のさまざまなレイヤーと、障害を検出する Azure の正常性チェックの概要を示したものです。
Web ロールと Worker ロールの場合、コードは Web ロールまたは Worker ロールのインスタンスで実行されています。Web ロールの場合、ロード バランサーが 15 秒ごとに Web エンドポイントに対して ping を実行して正常性を確認しています。決められた回数連続して ping が失敗すると、エンドポイントは異常と判定され、復旧処理が実行されます。つまり、ロールがローテーションから除外され、問題のあるロールと見なされます。
メモ: これは、一般提供の既定のロード バランサーでのローテーションにのみ該当し、カスタムのロード バランサー プローブには該当しません。
Web ロールと Worker ロールの場合は、仮想マシンにロールを監視するためのゲスト エージェントが追加されます。このゲスト エージェントも、仮想マシン内のロール インスタンスに対して 15 秒ごとに正常性チェックを実行します。決められた回数連続して失敗するか、ロード バランサーからのシグナルによってロールが異常と判断された場合、復旧処理 (ロール インスタンスの再起動) が実行されます。MTTD の向上のため、Azure の正常性チェックは 15 秒以下の間隔で実行されています。障害を初期段階ですばやく検出し復旧することで、関連システムやシステム全体への影響拡大を防ぐことができます。
次のレイヤーは、ロール インスタンスが実行されている仮想マシンの正常性です。仮想マシンは、Azure データセンター内の物理サーバー上でホストされています。物理サーバーでは「ホスト エージェント」というエージェントが実行されます。ホスト エージェントは、ゲスト エージェントに対して 15 秒ごとに ping を実行して仮想マシンの正常性を監視しています。仮想マシンには常にワークロードの負荷がかかっており、CPU 使用率が 100% になることも十分あり得るため、正常性チェックに数回失敗しただけでは復旧処理は実行されません。正常性チェックの応答を最大 10 分待ってから復旧処理を開始します。この場合、Web ロールと Worker ロールで問題のなかった OS ディスクを使用して仮想マシンが再起動されます。また Azure Virtual Machines の場合は、ディスク状態はそのままで再起動が実行されます。
メモ: Azure Virtual Machines では、ロール インスタンスが存在せず、既定ではゲスト エージェントが自動的に追加されることもありません。そのため、ハイパーバイザーから報告される仮想マシンの状態に対して正常性チェックが実行されます。
次のレイヤーは、仮想マシンが実行されている物理サーバーの正常性です。ファブリック コントローラーは、ホスト エージェントを通じて、物理サーバーに対する正常性チェックを定期的に実行しています。一定の回数連続して正常性チェックに失敗した場合、物理サーバーに異常があると見なされ、マシンが正常な状態に戻らなければ復旧処理を開始します。最初に物理サーバーの再起動が実行されます。
決められた時間内に物理サーバーが正常な状態に戻らない場合、物理サーバー上で実行されている仮想マシンを、データセンターの同パーティションにある別の正常なサーバーに復旧します。
その後、物理サーバーはローテーションから除外されて隔離され、障害の原因特定のためさまざまな観点から診断されます。必要な場合は修理のためメーカーに送られます。
障害発生前の予測に基づく予防措置
ここまでご説明してきたのは、障害が既に発生した場合の検出方法と復旧方法でした。Azure は障害に対処するだけでなく、ヒューリスティックに基づき発生する可能性のある障害を予測し、発生前に予防措置を取るため、MTTR (Mean Time To Recovery: 復旧までの時間) をさらに短縮することが可能です。
先ほどご説明した、物理サーバー上に配置されるホスト エージェントは、サーバーおよびアタッチされているその他のデバイス (ディスク、メモリなどのハードウェア) に関する正常性の情報を定期的に収集しています。この情報には、CPU 使用率やディスク IO などのパフォーマンス カウンターだけでなく、その他のメトリックも含まれます。たとえば、ディスク ドライブの不良セクターの情報は、ディスク障害が発生するタイミングの予測に役立ちます。障害発生前でもサーバー上の仮想マシンをできるだけ速やかに復旧させ、物理サーバーがさまざまな観点から診断されます。
ビッグ データを利用した障害の分析
Microsoft Azure では、プラットフォーム上のすべての仮想マシンから、毎日数 TB に及ぶ診断ログや正常性チェックの情報、クラッシュ ダンプが生成されます。マイクロソフトはこのデータを利用して障害のパターンを特定します。MapReduce が実装された「Cosmos (英語)」の自動ビッグ データ分析機能を利用してログやクラッシュを分析します。こうした分析により障害のパターンを特定でき、さらにシステムのバグを発見することが可能になります。また、システム強化のための新機能の発見や既存機能の向上にも分析結果が多く利用されています。皆様の貴重なご意見に加え、このようなデータがプラットフォームの発展に役立っています。
なお、今後の MTTD と MTTR の向上のために、この記事の正常性チェックに関する値が随時変更される可能性があります。記事内の値は Azure のサービス復旧のしくみをご説明するためのものです。