正常性モデリングとは
- 7 分
環境が期待どおりに動作しているかどうかを判断するには、アプリケーションの正常性と、環境の Azure リソースの主要なメトリックを監視することが重要です。 正常性モデリングは、主要なビジネス要件を使用して生データ ログおよびメトリックを拡張する設計演習です。 目標は、アプリケーションの正常性を定量化し、正常性状態の自動評価を推進することです。
正常性モデリングの利点
ワークロードの全体的な正常性を評価するには、すべてのメトリックを包括的に理解する必要があります。 また、信頼性に関する問題をすばやく特定して解決する必要もあります。
正常性モデリングでは、インストルメンテーションと監視の徹底に焦点が当てられますが、アプリケーションの正常性に関する重要な分析情報を得るためにコンテキストのレイヤーも追加されます。 適切に設計された正常性モデルは、生データ メトリックではなく、ワークロードの全体的な正常性を明確に示します。
ミッション クリティカルなアプリケーションは、性質が複雑であるために、大量の運用データを生成することが予想されます。 アプリケーションの正常性状態を評価し、特定された問題を解決するための正しいアクションを見極めるのは困難な場合があります。
正常性モデルでは、セット インジケーターを使用して正常性状態を表します。これにより、発生する可能性のある問題を直感的に理解し、迅速に対応できるようになります。 通常、正常性状態は、緑色、黄色、赤色などの "信号" インジケーターを使用して表されます。 アプリケーションの正常性スコアをトレースして、サービスの低下の根本原因をすばやく見つけることができます。
ファースト ステップ
正常性モデリングの演習を行うには、システムとその予想されるパフォーマンスについて深く理解している必要があります。 "階層化モデル" では、アプリケーションの全体的な正常性 "および" 詳細なレベルを反映することをお勧めします。 レイヤーは、アプリケーションとその依存関係を含む階層的なワークロード構造を表します。
- 最上位レイヤーの正常性は、アプリケーション内のユーザー操作またはフローを表します。 クリティカル パス上にあるフローとそうでないフローについて考えます。
- 下位レイヤーでは、主要な非機能要件を念頭に置いて、個々のアプリケーション コンポーネントの正常性を定義する必要があります。 機能コンポーネントと論理コンポーネント間の依存関係をマップします。 また、アプリケーション コンポーネントで使用される Azure リソース間の依存関係をマップします。
- 基本レイヤーでは、正常性はアプリケーションによって使用される Azure リソースを表します。
正常性をモデル化するプロセスは、トップダウン設計アクティビティです。これは、すべてのユーザー フローを定義し、依存関係をマッピングして、正常性状態をフローに定量化することから始めます。
アプローチに推奨される手順を次に示します。
- 各コンポーネントが正常性スコアを示すように、各コンポーネントの正常性状態を定量化します。 正常性スコアは、主要なビジネス要件を考慮する、さまざまなパフォーマンス メトリックの集計である場合があります。
- 個々のコンポーネントの正常性スコアを組み合わせてフローの正常性を示すことで、各フローの正常性状態を定量化します。 重要度の観点からコンテキストを設定するための非機能要件を考慮します。
- ビジネスの重要度に基づいて、すべてのレイヤーに適切な重みを適用して、全体的な正常性の有意義な定義を構築します。 たとえば、最上位層では、財務的に重要なフローと顧客向けのユーザー フローが他のフローよりも重要です。
この図は、上記のアプローチの結果の例を示しています。 正常性モデルでは、これらの階層化された正常性定義を使用して、すべてのシステム コンポーネントにわたって重要な監視メトリックが通知され、運用サブシステムの構成が検証されます。
次の演習では、プロセスの概要を例に適用し、階層化された正常性モデルを構築します。
階層化された正常性モデルの詳細については、「階層化されたアプリケーションの正常性」を参照してください。 また、階層化された正常性モデルの例も参照してください。