ワークロードに関する正常性のモデリング
クラウド アプリケーションでは大量のオペレーション データが生成されるため、問題を迅速に特定して解決することが困難です。 この課題の理由としては一般的に、ワークロードの機能に合わせてカスタマイズされた正常性ベースラインが存在しないこと、およびそのベースラインからのドリフトを検出できないことが挙げられます。
正常性モデリングは、ビジネス コンテキストと生の監視データを組み合わせてワークロードの全体的な正常性を定量化する監視演習です。 ワークロード監視のベースラインを設定するのに役立ちます。 インフラストラクチャ、アプリケーション コンポーネントから、テレメトリなどのデータを考慮する必要があります。 正常性モデリングには、ワークロードの品質目標の達成に必要なその他の情報が組み込まれている場合もあります。
パフォーマンスの問題や操作性の低下により、期待される動作状態からのドリフトが発生する可能性があります。 ワークロードの正常性をモデル化することで、ドリフトを特定し、ビジネスへの影響を考慮したうえで、情報に基づいた運用上の意思決定を行うことができます。
正常性モデリングは、組織固有の操作に関する知識と実用的な分析情報のギャップを解消します。 これは重大な問題を効果的に管理するのに役立ちます。 その概念は、信頼性と運用効率を最大化するうえで欠かせません。
このガイドでは、ワークロードとそのサブシステムすべてのランタイム正常性の評価モデルを構築する方法など、正常性モデリングに関する実用的なガイダンスを紹介します。
| 用語 | Definition |
|---|---|
| 正常性のモデリング | ビジネス コンテキストを使用して監視データを正常性状態として解釈する監視演習。 |
| 正常性モデル | 特定のスコープに対する論理エンティティとそのリレーションシップのグラフィカル表現。 モデル全体の監視データを有理化する正常性状態の定義が各ノードにあります。 |
| 正常性エンティティ | 個々のシステム ユニット、複数の関連エンティティの論理的な組み合わせ、またはシステム全体を表す論理コンポーネント。 |
| 正常性の状態 | エンティティの正常性に関する有意義な運用上の分析情報を提供する、定義済みの測定可能な状態。 |
| 正常性シグナル | エンティティの運用動作に関する分析情報を提供する個々のデータ ストリーム。 |
| モデルのモデル | コンポーネント システムの個別の正常性モデリングを表すエンティティの集計済みモデリングのスコープ。 |
このビデオを見て、正常性モデリングの概要を把握することをお勧めします。
正常性、正常性モデリング、および正常性モデルとは
"正常性" という用語は、エンティティとその依存関係の動作状態を指します。 エンティティは、個々のシステム ユニット、複数の関連エンティティの論理的な組み合わせ、システム全体のいずれかです。
正常性は次の 3 つの状態のいずれかで表すことをお勧めします。
正常: 最適に動作し、品質の期待を満たしています
機能低下: 正常とはいえない動作です。潜在的な問題を示します
異常: 重大な状態です。直ちに対応する必要があります
Note
データの細分性を高めるために、状態ではなくスコアで正常性を表すことができます。
正常性状態は、監視データとドメイン情報を組み合わせることで派生します。 それぞれの状態が定義され、測定可能でなければなりません。 正常性状態は、エンティティの実行動作に関する分析情報を提供する個々のデータ ストリームである "正常性シグナル" を使用して計算されます。 シグナルには、メトリック、ログ、トレース、またはその他の品質の特性を含めることができます。 たとえば、仮想マシン (VM) エンティティの正常性シグナルの場合は、CPU 使用率のメトリックが追跡されることがあります。 このエンティティのその他のシグナルには、メモリ使用量、ネットワーク待機時間、エラー率が含めることができます。
正常性シグナルを定義するときは、ワークロードの非機能要件を考慮します。 CPU 使用率の例では、想定されるしきい値を正常性状態ごとに含めます。 使用率がワークロード要件で許容されるしきい値を超えた場合、システムの状態は "正常" から "機能低下" または "異常" に移行します。 このように状態が変更されると、それに従ってアラートまたはアクションがトリガーされます。
正常性モデリングでは、エンティティに、複数の正常性シグナルから派生し、ワークロードに合わせてコンテキスト化された明確な状態が必要です。 たとえば、VM の正常性の定義は次のようになります。
正常: 応答時間、リソース使用率、システム全体のパフォーマンスなど、主な非機能要件とターゲットが完全に満たされています。 たとえば、95% の要求が 500 ミリ秒以内に処理されます。 CPU、メモリ、ストレージなどの VM リソースがワークロードによって最適に使用され、ワークロードの需要と使用可能な容量のバランスが保たれています。 ユーザー エクスペリエンスは想定内のレベルにあります。
機能低下: リソースは最適ではありませんが、まだ動作しています。 たとえば、ストレージ ディスクで調整の問題が発生しています。 ユーザーは応答が遅いと感じる可能性があります。
異常: 機能低下が許容範囲を超えています。 リソースが応答しない、使用できないなど、システムが許容できるパフォーマンス レベルを満たしていません。 ユーザー エクスペリエンスは深刻な影響を受けます。
正常性モデリングの結果が "モデル"、つまり、ワークロード アーキテクチャの論理エンティティとそのリレーションシップをグラフィカルに表現したものです。 各ノードに正常性状態の定義があります。
重要
"正常性モデリング" は抽象的な概念であり、さまざまなスコープで実装および適用するには、ビジネス シナリオを十分に理解する必要があります。
この画像の説明を次に示します。
"エンティティ" は、システムの側面を表すワークロードの論理コンポーネントです。 これはサーバー、データベース、ネットワークなどのインフラストラクチャ コンポーネントである場合があります。 特定のアプリケーション モジュール、ポッド、サービス、マイクロサービスであることもあります。 エンティティで、ワークロード内のユーザー操作とシステム フローをキャプチャすることもできます。
Note
ユーザー フローとシステム フローは、アプリケーションおよびインフラストラクチャ コンポーネントを含むビジネス シナリオ全体の非機能要件をまとめたものです。 このサマリーには、アプリケーションのビジネス価値が反映されています。
エンティティ間の "リレーションシップ" には、システム内の依存関係チェーンが反映されています。 たとえば、アプリケーション モジュールでは、"リレーションシップ" を形成する特定のインフラストラクチャ コンポーネントが呼び出される場合があります。
eコマース ワークロードにおいて、Azure Service Bus キュー上のメッセージの失敗が急増し、支払いが失敗するシナリオを考えてみましょう。 この問題は、潜在的な収益損失につながるため組織にとっては重要です。 このメトリックの急増が支払いにどのように影響するか、アプリケーション開発者は理解しているかもしれません。しかし、こうした組織固有の知識が運用チーム全体で共有されることはあまりありません。
正常性モデルにより、問題とその影響を、オペレーターがすぐに把握できるようになります。 支払いフローは、ワークロード コンポーネントの 1 つである Service Bus によって異なります。 ビジュアル表現により、Service Bus インスタンスの機能が低下した状態と、支払いフローへのその影響が明らかになります。 オペレーターは問題の重要性を理解したうえで、その特定のコンポーネントの修復作業に重点的に取り組むことができます。
前述のシナリオの正常性モデリングは、以下の点で重要でした。
問題をより迅速に切り分けられるようになり、検出時間 (TTD) と軽減時間 (TTM) が短縮しました。これが問題と潜在的な修正プログラムの早期検出につながりました。
オペレーターが、正常性状態に基づいてアラートを受信しました。これにより不要なノイズが減りました。 オペレーターが、ビジネスの支払い業務への影響に関する具体的なコンテキストが示された通知を受け取りました。
依存関係チェーンは、オペレーターが運用上の問題の範囲を完全に把握するのに役立ちました。 この知識により影響評価を促進され、これが優先順位に基づく対応につながりました。 また、オペレーターは連鎖的な問題や相関的な問題を容易に特定しました。
正常性モデルにより、異常の根本原因と、関連する特定の正常性シグナルについての分析情報が提供されたことで、オペレーターがインシデント後のアクティビティを正確に実行しました。
すべてのチーム メンバーにとって監視データが有意義なものになりました。 これが組織固有の知識と共有分析情報のギャップを解消しました。
組織は、正常性モデルを、AI 駆動型運用に対する将来の投資のベースラインとして使用して、インテリジェントな分析情報を引き出しました。
正常性モデルのスキーマ
正常性モデルは、監視のユース ケース用に最適化された個別のデータ スキーマを提供します。 このスキーマは、正常性モデリングを、抽象的な概念を測定可能なソリューションへと導きます。 特定の要件、目的、アーキテクチャ コンテキストをモデル化することで、正常性データを独自のシナリオに合わせて調整することができます。
正常性は、相対的なデータの概念です。 モデルで同じエンティティ セットを使用されている場合でも、モデルそれぞれが表す正常性データは一意であり、そのコンテキスト スコープに対して優先順位が付けられています。 特定のシナリオで "正常" を構成しているものでも、他のコンテキストでは大きく異なることがあります。
たとえば、ワークロード内の同じ種類の Azure リソースを考えてみましょう。
- VM A は、CPU センシティブなアプリケーションを実行します。
- VM B は、メモリを多く消費するサービスを処理します。
これらのマシンの正常性定義は異なります。 VM A の正常性状態は、CPU 使用率メトリックの影響を受ける可能性が高く、VM B ではメモリ関連のメトリックが優先される場合があります。
重要
正常性モデルでは、すべての障害を同じように処理することはできません。 予期される、または一時的な障害で回復可能なものと、本当の災害状態を明確に区別する必要があります。
正常性モデルを構築する
正常性モデル構築の第一歩は論理設計演習です。これには通常、次のセクションで説明するアクティビティが含まれます。
ワークロード設計を評価する
まずはワークロード設計の次のコンポーネントを評価して、この論理設計演習を開始します。
コンピューティング クラスターやデータベースなどのインフラストラクチャ コンポーネント
コンピューティング上で実行されるアプリケーション コンポーネントとその関連コンポーネント
コンポーネント間の論理的または物理的な依存関係
たとえば、eコマース アプリケーションの正常性モデルは、ユーザーのサインイン、チェックアウト、支払いなど、重要なプロセスの現在の状態を表す必要があります。
ビジネス要件を使用してコンテキスト化する
組織における各フローの相対的な重要度と全体的な影響を評価します。 ユーザー エクスペリエンス、セキュリティ、運用効率などの要因を考慮してください。 たとえば、ほとんどのシナリオで、支払いプロセスの失敗は、レポート プロセスの失敗よりも重大である可能性が高くなります。
各フローに関連する問題を処理するためのエスカレーション パスを特定します。 詳細については、フローを使用したワークロード設計の最適化に関するページを参照してください。
Note
正常性モデリングの価値は、ビジネス シナリオとコンテキストを組み込むことによってのみ実現します。 その後、運用上の問題によるビジネスへの影響を有理化できます。
信頼性メトリックにマップする
アプリケーション設計全体で、関連する信頼性メトリックを探します。
アプリケーション全体とその個々のビジネス プロセスに対して、サービス レベル インジケーター (SLI) とサービス レベル目標 (SLO) を定義することを検討してください。 これらの SLI と SLO は、正常性モデルで考慮される特定の正常性シグナルと一致する必要があります。 これを行うことで、許容されるアプリケーション サービス レベルのアチーブメントが正確に反映された、正常性の包括的な定義を作成します。
重要
SLI と SLO は重要な正常性シグナルです。 これにより、必要なサービス レベルと他の品質属性が反映された、有意義な正常性定義が作成されます。 また、サービス正常性目標 (SHO) を定義して、集計時間範囲で達成したい正常性をキャプチャすることもできます。
正常性シグナルを特定する
包括的な正常性モデルを構築するには、メトリック、ログ、トレースなど、さまざまな種類の監視データを関連付けます。 これを行うことで、正常性の概念に、特定のエンティティまたはワークロード全体のランタイム状態を確実かつ正確に反映させます。
プラットフォームのメトリックとログを使用する
正常性モデリングのコンテキストでは、基盤となる Azure リソースからプラットフォーム レベルのメトリックとログを収集することが不可欠です。 これらのメトリックには、CPU 使用率、ネットワーク受信とネットワーク送信、1 秒あたりのディスク操作が含まれます。 正常性モデルでこのデータを使用して、信頼性の高い環境を維持しながら潜在的な問題を検出し、予測することができます。
さらに、このアプローチは、一時的な障害、一時的な中断、一時的でない障害、または永続的な問題を区別するのに役立ちます。
Note
ベスト プラクティスとして、診断ログとメトリックが、選択済みログ集計テクノロジに直接送信されるように、すべてのアプリケーション リソースを構成してください。 Azure Policy を使用してガードレールを構築し、アプリケーション全体で一貫した診断設定を確保し、各 Azure サービスに対して選択された構成が適用されるようにします。
アプリケーション ログを追加する
アプリケーション ログは、正常性モデルに対する診断データの重要なソースです。 ここでは、アプリケーションのログ記録に関するベスト プラクティスをいくつか紹介します。
セマンティックまたは構造化されたログ記録を使用する。 構造化されたログにより、ログ データの自動消費と分析を大規模に支援します。
ストレージ アカウントではなく、Azure Monitor Loop ワークスペースに Azure リソース メトリックと診断データを保存することを検討してください。 この方法を使用すると、効率的な評価のために Kusto クエリを使用して正常性シグナルを作成できます。
運用環境のデータのログを記録します。 アプリケーションが運用環境で実行されている間、包括的なデータをキャプチャします。 正常性評価と検出された運用の問題の診断には十分な情報が不可欠です。
サービスの境界でイベントのログを記録します。 サービス境界をまたがる関連付け ID を含めます。 トランザクションが複数のサービスに関わり、そのいずれかが失敗した場合、関連付け ID は、アプリケーション全体で要求を追跡し、失敗の原因を特定するのに役立ちます。
非同期のログ記録を使用します。 アプリケーション コードをブロックする可能性のある非同期ログ記録操作を避けます。 非同期ログ記録では、ログ書き込み中の要求バックログを防ぐことで可用性が確保されます。
アプリケーションのログと監査を分けます。 診断ログとは別に監査ログを維持します。 監査レコードはコンプライアンスまたは規制の要件に対応しますが、それらを個別に維持することで、トランザクションが破棄されるのを防ぎます。
分散トレースを実装する
重要なシステム フロー間でテレメトリを関連付けることで、分散トレースを実装します。 相関テレメトリは、エンドツーエンドのトランザクションに関する分析情報を提供し、障害が発生した場合の効果的な根本原因分析 (RCA) に不可欠です。
正常性プローブを使用する
アプリケーションの外部で正常性プローブを実装して実行し、アプリケーションの正常性と応答性を明示的に確認します。 正常性モデル内のシグナルとしてプローブ応答を使用します。
正常性プローブを実装するには、アプリケーション全体または個々のコンポーネントからの応答時間を測定します。 プローブはプロセスを実行して待機時間を測定し、可用性を確認したり、アプリケーションから情報を抽出したりできます。 詳細については、「正常性エンドポイントの監視パターン」を参照してください。
ほとんどのロード バランサーでは、設定された間隔でアプリケーション エンドポイントに ping を行う正常性プローブの実行がサポートされています。 または、外部ウォッチドッグ サービスを使用できます。 ウォッチドッグ サービスは、ワークロード内の複数のコンポーネントから正常性チェックを集計します。 ウォッチドッグによって、既知の正常性状態に対して直ちに修復を行うコードをホストすることもできます。
構造と機能の監視手法を採用する
構造の監視には、アプリケーションがセマンティック ログとメトリックを備えている必要があります。 これらのメトリックには、現在のメモリ消費量、要求の待機時間、およびその他の関連するアプリケーション レベルのデータが含まれており、アプリケーションはこれを直接収集します。
監視プロセスは、機能監視を使用して強化します。 このアプローチでは、プラットフォーム サービスと全体的なユーザー エクスペリエンスへのその影響を測定することに重点を置いています。 構造監視とは異なり、機能監視にはシステムに関する詳細な知識は必要ありません。 これはアプリケーションの外部から見える動作をテストします。 このアプローチは、SLO と SLI の評価に役立ちます。
設計をモデル化する
特定されたアプリケーション設計をエンティティとリレーションシップとして表します。 正常性シグナルを特定のコンポーネントにマップし、正常性状態をエンティティ レベルで定量化します。 正常性状態がモデル全体にどのように反映されるかを判断する場合は、コンポーネントの重要度を考慮してください。 たとえば、レポート コンポーネントは他のコンポーネントほど重要ではない可能性があります。その結果、ワークロード全体の正常性に異なる影響を及ぼします。
実用的なアラートを設定する
アラートと自動アクションは、評価済みの正常性状態を使用してトリガーします。 正常性は、コア監視データの中核となる原則として、既存の運用 Runbook 内に統合する必要があります。
通常、監視データとアラート ルールは 1 対 1 でマッピングされ、これがアラート ストームやアンビエント アラート ノイズなどの望ましくない結果につながる可能性があります。 たとえば、コンピューティング クラスターで CPU 使用率とエラー数に基づく VM レベルのアラートが大量に発生すると、障害発生時にオペレーターに大きな負荷をかけ、解決が遅延する可能性があります。 同様に、設定されてアラート数が多い場合、アンビエント アラート ノイズが原因で、アラートが見落とされたり無視されたりすることがよくあります。
正常性モデルでは、監視データとアラート ルールが切り離されています。 正常性の定義では、多くのシグナルが 1 つの正常性状態に集約されています。これによりアラート数が減るため、オペレーターは、組織にとって重要な価値の高いアラートのみに集中することができます。 eコマースのシナリオを考えてみましょう。 Service Bus キューなどの基になるリソースの変更ではなく、プロセス支払いフローの正常性の変更に関する通知を送信するように、アラートを設定できます。
Note
正常性モデルのすべてのレイヤーでアラートを生成できるため、さまざまなワークロード ペルソナに対して柔軟性が実現します。 アプリケーションの所有者と製品マネージャーは、主要なビジネス シナリオまたはワークロード全体の正常性状態の変化についてアラートを受け取ることができます。 オペレーターは、インフラストラクチャまたはアプリケーション コンポーネントの正常性に基づくアラートを受け取ることができます。
モデルを視覚化する
テーブルやグラフなどのビジュアル表現を作成して、正常性モデルの現在の状態や履歴を効果的に伝えます。 視覚化とビジネス コンテキストが一致し、実用的な分析情報が提供されていることを確認します。
正常性モデルを視覚化するときは、依存関係チェーン全体で正常性状態の分析情報をすぐに得られるように、"信号機" アプローチを採用することを検討してください。
正常には緑、機能低下には黄色、異常には赤を割り当てます。 色分けされた状態をすばやく特定することで、アプリケーションの機能低下の根本原因を効率的に特定できます。
Note
正常性モデルのダッシュボードを作成するときは、視覚障碍のあるユーザーのアクセシビリティ要件を考慮することをお勧めします。 ダイアグラム作成のベスト プラクティスについては、「アーキテクチャ設計のダイアグラム」を参照してください。
正常性モデルを採用する
正常性モデルを構築したら、障害または運用上の問題の検出と解釈を促進するために、次のユース ケースを検討してください。
さまざまなロールへの適用性
正常性モデリングでは、同じワークロード コンテキスト内の職務またはロールに固有の情報を提供できます。 たとえば、DevOps ロールには運用上の正常性情報が必要な場合があります。 セキュリティ責任者は、侵入信号とセキュリティ露出に関する懸念が大きい可能性があります。 データベース管理者は、高い可能性で、データベース リソース全体のアプリケーション モデルのサブセットにのみ関心があります。
さまざまな利害関係者に合わせて正常性の分析情報を調整してください。 重複するデータ セットとは別のモデルを作成することを検討してください。
継続的な検証
正常性モデルを使用して、ロード テストやカオス テストなどのテストおよび検証プロセスを最適化します。 エンジニアリング ライフサイクルに正常性モデルを組み込むことで、テスト中にランタイムの運用状態を検証し、スケールおよび障害シナリオにおけるモデルの有効性を評価できます。
組織の正常性
正常性モデリングは通常、個々のアプリケーションにおける正常性状態の定量化と関連付けられていますが、その適用性はその範囲にとどまりません。
個々のワークロード レベルでは、正常性モデルによって、アプリケーションの監視と運用の分析情報の基盤が提供されます。 各正常性状態がそのコンテキスト内で何を意味するのかをキャプチャする独自の正常性モデルを、各アプリケーションが持つことができます。
複数の正常性モデルを高レベルのコンストラクトと組み合わせるには、"モデルのモデル" を構築します。 たとえば、事業単位またはクラウド資産全体の占有領域を構築するには、大規模なモデル内で正常性モデルをコンポーネントとして使用します。 正常性モデルは、資産内のワークロードを、最上位のグラフ内のノードとして表します。 このモデルのリレーションシップを使用して、データ フロー、サービス操作、共有インフラストラクチャなど、アプリケーション間の依存関係をキャプチャします。
eコマース、支払い、注文処理のさまざまなアプリケーションを持つ小売企業を考えてみましょう。 これらの各アプリケーションを独立した正常性モデルとして定義すると、そのワークロードに対して正常性が何を意味するのかを定量化できます。 その後、親モデルを使用して、そのすべてのコンポーネント正常性モデルをエンティティとしてマップし、依存関係チェーンを通じてアプリケーション間の運用上の影響をキャプチャできます。 たとえば、eコマース アプリケーションが異常状態になると、それは支払いアプリケーションに連鎖的な影響を与えます。
正常性の傾向と IT 運用のための人工知能
正常性モデリングは、特定のビジネス コンテキストに合わせて調整された、定量化された運用ベースラインを提供します。 IT 運用のための人工知能 (AIOps) は、運用効率を向上させる一般的な方法です。 正常性データは、正常性の傾向を分析するための機械学習モデルの基本的な入力です。 たとえば、Azure 機械学習モデルでは以下のことが可能です。
状態の変更から詳しい分析情報を抽出し、アクションを推奨する。
時間の経過に伴う正常性の傾向を分析して、問題の予測とモデルの微調整を促進する。
正常性モデルを維持する
正常性モデルの維持は、アプリケーションの開発と運用に合わせて継続的に行うエンジニアリング アクティビティです。 アプリケーションの進化に伴い、正常性モデルが並行して進化していることを確認します。
また、正常性モデルは、開発ライフサイクルに統合する必要があるワークロード成果物のように扱ってください。 正常性モデルで一貫性のあるバージョン管理を実現するために、コードとしてのインフラストラクチャ (IaC) を採用します。 自動化を使用して、ワークロードのインフラストラクチャやアプリケーション コンポーネントを追加または削除してもモデルが最新の状態に維持されるようにしましょう。
正常性データは、時間の経過に伴い少しずつ価値が下がります。 運用効率を最適化し、コストを最小限に抑えるには、30 日を超えて正常性データを保持しないようにしてください。 必要に応じて、監査要件に対応するため、または IT 運用のための人工知能に長期的パターン分析を伴うシナリオで、データをアーカイブすることができます。
Note
正常性データをアーカイブする場合は必ず、そのデータと、モデルの構成状態を組み合わせてください。 このコンテキストがないと、状態の変化を解釈するのが難しくなることがあります。
関連リンク
- ASP.NET での正常性プローブの実装については、「ASP.NET Core の正常性チェック」を参照してください。
- メトリックの監視の詳細については、「Azure Monitor メトリックの概要」を参照してください。
- Application Insights については、Application Insights に関するページをご覧ください。
- ミッション クリティカルなワークロードに関連する設計上の考慮事項と推奨事項については、「Azure でのミッション クリティカルなワークロードの正常性モデリングと監視」を参照してください。
- 実際に体験してみるには、「ミッション クリティカルなワークロード用の正常性モデルを設計する」を参照してください。