Project Flash - Azure Resource Health を使用して Azure 仮想マシンの可用性を監視する

[アーティクル]
10/15/2024

Azure Resource Health は、Flash によって提供される 1 つのソリューションです。 Flash は、お客様が仮想マシン (VM) の正常性を監視するための堅牢で信頼性の高い迅速なメカニズムを構築することに特化したプロジェクトの内部名です。

この記事では、Azure Resource Health を使用した Azure 仮想マシンの可用性の監視について説明します。 Flash ソリューションの概要については、Flash の概要に関するページを参照してください。

Flash によって提供される他のソリューションに固有のドキュメントについては、次の記事から選択してください。

Azure Resource Health

これは、ポータルを使用して、個々のリソースの即座でかつわかりやすい正常性チェックを提供します。お客様は、ポータルのリソース正常性ブレードにすばやくアクセスできるほか、正常性チェックの 30 日間の履歴レコードも確認できるため、迅速でかつ簡単なトラブルシューティングのための優れたツールになっています。 Azure Resource Health の既存の機能は、Azure リソースに影響を与えるサービスの問題を診断したり、その件でサポートを受けたりするのに役立ちます。リソースの現在と過去の正常性が報告されるため、各リソースが使用不可になっていたすべての時間範囲が示されます。

ただし、お客様とパートナーは何が基になる技術的な問題の原因であるかを理解することや、すべての問題についてコミュニケーションを受け取る、つまり、監視プロセスに情報を入力し、他の利害関係者に問題点を説明し、最終的にビジネス上の意思決定を通知する方法を改善することに関心があることがわかっています。

Azure Resource Health での VM の問題の根本原因

Microsoft は最近、VM の障害についてお客様と共有する情報を拡張し、問題を発生させた根本原因に関するさらに詳細なコンテキストを提供する、リソース正常性エクスペリエンスの強化を発送しました。お客様は現在、VM の可用性が影響を受けたときに迅速な通知を受け取るだけでなく、自動化された根本原因分析 (RCA) システムで VM の障害を引き起こした失敗している Azure プラットフォームコンポーネントが識別されたら、後で根本原因が追加されることを期待できます。このプロセスが実際にどのように機能するかを確認する例を見てみましょう。

時刻 T1 に、サーバーラックがネットワークの問題のためにオフラインになり、そのラック上の VM が接続を失います。ネットワークアーキテクチャに関連する最近の信頼性向上は、将来の「信頼性の向上」のブログ記事で共有される予定です (しばらくお待ちください)。

時刻 T2 に、Azure の内部監視がラック上の VM に到達できないことを認識し、影響を受けている VM を新しいラックに再デプロイすることによって軽減処理を開始します。この期間中に、VM が現在影響を受けており、使用不可であることを顧客に通知する注釈がリソース正常性に送信されます。

時刻 T3 に、障害の根本原因を導き出すために、トップオブラックスイッチ、ホストマシン、内部監視システムからのプラットフォームテレメトリがまとめて RCA エンジン内で相互に関連付けられます。計算が完了すると、将来の影響の可能性を最小限に抑えるために顧客が実装できる関連するアーキテクチャの回復性に関する推奨事項と共に、RCA がリソース正常性に発行されます。

最初のダウンタイム通知機能は数年前から提供されていますが、根本原因ステートメントの発行は新しい追加です。次に、これらの根本原因を導き出す方法の詳細を調べてみましょう。

根本原因分析エンジン

前の例をさらに詳しく見て、RCA エンジンのしくみとその背後にあるテクノロジの詳細を調べてみましょう。 VM のための RCA エンジンの中心には、大量のログテレメトリ分析用に最適化されたビッグデータサービスである Azure Data Explorer (ADX) があります。 Azure Data Explorer を使用すると、Azure プラットフォームを構成するデバイスやサービスからの数テラバイトのログテレメトリを容易に解析してそれらをまとめて結合し、相互に関連付けられた情報ストリームを解釈して、さまざまな障害シナリオの根本原因を導き出すことができます。これにより、複数ステップのデータエンジニアリングプロセスが生成されます。

フェーズ 1: ダウンタイムの検出

根本原因分析の最初のフェーズは、分析が実行されるトリガーを定義することです。仮想マシンの場合は、VM が予期せず再起動するたびに根本原因を特定する必要があるため、トリガーは稼働状態からダウン状態に遷移している VM です。これらの遷移をプラットフォームテレメトリから識別することは、ほとんどのシナリオでは簡単ですが、デバイス障害または電力損失のためにプラットフォームテレメトリが失われる可能性がある特定の種類のインフラストラクチャ障害に関してはより複雑です。これらのクラスの障害を処理するには、VM の可用性の遷移の考えられる兆候としてのデータ損失の追跡などの他の手法が必要です。 Azure Data Explorer は、現時点の時系列分析より優れています。このプロセスに関する手法の詳細については、Microsoft Tech Community の Azure Data Explorer でのウィンドウ関数と時系列関数を使用したダウンタイムの計算に関する記事を参照してください。

フェーズ 2: 相関関係分析

トリガーイベント (この場合は、VM の異常な状態への遷移) が定義されたら、次のフェーズは相関関係分析です。このステップでは、トリガーイベントの存在を使用して、次のような Azure プラットフォーム全体にわたるポイントからのテレメトリを相互に関連付けます。

Azure ホスト: VM をホストしている物理ブレード。
TOR: トップオブラックネットワークスイッチ。
Azure Storage: Azure Virtual Machines の仮想ディスクをホストするサービス。

これらの各システムには、解析して VM ダウンタイムトリガーイベントに相互に関連付ける必要がある独自のテレメトリフィードがあります。このプロセスは、VM の依存関係グラフと VM の障害の原因となる可能性がある基になるシステムを理解してから、これらのすべての依存システムの正常性テレメトリをまとめて結合し、VM の遷移の時刻の近くで発生したイベントでフィルター処理することによって完了します。 Azure Data Explorer の直感的で強力なクエリ言語は、一時的なテレメトリストリームをまとめて相互に関連付けるための、時間枠内での結合などの文書化されたパターンを提供することで役立ちます。この相関関係プロセスの最後には、VM の障害の原因となったか、または原因の特定に役立つ情報を持っている可能性があるすべての依存システムからの相互に関連付けられたプラットフォームテレメトリによって VM のダウンタイムの遷移を表すデータセットが得られます。

フェーズ 3: 根本原因の帰属

このプロセスの次のステップは帰属です。これで、すべての関連データがまとめて 1 つのデータセットに収集されたので、その情報を解釈し、それを顧客向けの根本原因ステートメントに変換するために帰属規則が適用されます。元の TOR の障害の例に戻ると、相関関係分析の後に、解釈するための興味深い多くの情報が得られている可能性があります。たとえば、Azure ホストを監視しているシステムには、この期間中にホストへの接続が失われたことを示しているログが存在する可能性があります。また、仮想ディスクの接続の問題に関連するシグナルや、障害に関する TOR デバイスからの明示的なシグナルが存在する可能性もあります。これらのすべての情報がここでスキャンされるようになり、TOR の障害の明示的なシグナルは根本原因として他のシグナルより優先されます。この優先順位付けプロセスとその背後にある規則は、特定分野の専門家によって構築され、Azure プラットフォームの発展に伴って変更されます。機械学習や異常検出のメカニズムは、これらの属性付き根本原因の最上位に位置付けられ、これらの分類規則を改善する機会を識別したり、安全なデプロイパイプラインにフィードバックされるこれらの障害の発生頻度のパターンの変化を検出したりするのに役立ちます。

フェーズ 4: RCA の発行

最後のステップは根本原因の Azure Resource Health への発行であり、そこで顧客に表示されます。発行は、Azure Data Explorer で処理された根本原因データ定期的にクエリを実行し、その結果をリソース正常性バックエンドに出力する、単純な Azure Functions アプリケーションによって実行されます。情報ストリームの取得ではさまざまなデータ遅延が発生する可能性があるため、最初に発行されたものより具体的な根本原因につながる到着したばかりのより優れた情報源を反映するために、このプロセスで RCA が更新される場合があります。

今後の手順

すべての問題の根本原因を特定し、お客様やパートナーに伝えることは単なる始まりにすぎません。お客様はこれらの RCA を取得し、それを顧客や仕事仲間と共有することが必要になる場合があります。 Microsoft では、ここでの作業に基づいて、リソースの RCA の特定と追跡を容易にし、それらを簡単に共有できるようにしたいと考えています。それを実現するために、公開可能な一意のリソースまたはダウンタイムごとの追跡 ID を生成するためのバックエンドの変更に取り組み、お客様がダウンタイムをその RCA と容易に照合できるようにしています。また、RCA を電子メールで送信したり、最終的には VM の RCA をサブスクライブしたりすることを容易にする新機能にも取り組んでいます。この機能により、使用不可イベントが発生した後、ユーザーはそれ以上のアクションを実行することなく、受信トレイで RCA に直接サインアップすることが可能になります。

次のステップ

提供されるソリューションの詳細については、次の対応するソリューションの記事に進んでください。

Azure Virtual Machines を監視する方法の概要については、「Azure 仮想マシンの監視」および Azure 仮想マシンの監視のリファレンスに関するページを参照してください。

次の方法で共有