Share via

Azure でのミッション クリティカルなワークロードの正常性モデリングと監視

  • [アーティクル]

正常性モデリングと可観測性は、信頼性を最大化するために不可欠な概念であり、堅牢でコンテキスト化されたインストルメンテーションと監視に焦点を当てています。 これらの概念は、アプリケーションの正常性に関する重要な洞察を提供し、問題の迅速な識別と解決を促進します。

ほとんどのミッション クリティカルなアプリケーションは、規模と複雑さの両方の点で重要であるため、大量の運用データを生成するため、最適な運用アクションを評価して決定することが困難になります。 正常性モデリングは、最終的には、アプリケーションの正常性を定量化するための主要なビジネス要件を使用して生の監視ログとメトリックを拡張し、正常性状態の自動評価を促進して、一貫性のある迅速な運用を実現することで、可観測性の最大化に努めています。

この設計領域では、堅牢な正常性モデルを定義するプロセスに焦点を当て、可観測性と運用構造を通じて定量化されたアプリケーションの正常性状態をマッピングし、運用の成熟度を実現します。

重要

この記事は、 Azure Well-Architected ミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合は、ミッション クリティカルなワークロードとは何かから始めてお勧めします。

信頼性を最大化するために取り組む場合、運用成熟度には 3 つのメインレベルがあります。

  1. 問題が発生した場合に検出して対応します。
  2. 発生している問題または既に発生している問題を診断します。
  3. 問題が発生する前に、問題を予測して防止します。

ビデオ: ミッション クリティカルなワークロードの正常性モデルを定義する

階層化されたアプリケーションの正常性

正常性モデルを構築するには、まず、階層化された測定可能な形式で "正常" 状態と "異常" 状態を定量化することで、主要なビジネス要件のコンテキストでアプリケーションの正常性を定義します。 次に、アプリケーション コンポーネントごとに、安定した実行状態のコンテキストで定義を絞り込み、アプリケーション ユーザー フローに従って集計します。 パフォーマンスと可用性に関する重要な非機能ビジネス要件と重ね合わせる。 最後に、個々のユーザー フローの正常性状態を集計して、アプリケーションの全体的な正常性を受け入れ可能な表現にします。 確立されたら、これらの階層化された正常性定義を使用して、すべてのシステム コンポーネントにわたって重要な監視メトリックを通知し、運用サブシステムの構成を検証する必要があります。

重要

"異常" 状態を定義する場合は、アプリケーションのすべてのレベルを表します。 一時的な障害状態と非一時的な障害状態を区別して、サービスの低下を使用不可と比較して修飾することが重要です。

設計上の考慮事項

  • 正常性のモデリング プロセスは、アーキテクチャの演習から始まるトップダウンの設計アクティビティであり、すべてのユーザー フローを定義し、機能コンポーネントと論理コンポーネント間の依存関係をマップし、それによって Azure リソース間の依存関係を暗黙的にマッピングします。

  • 正常性モデルは、それが表すソリューションのコンテキストに完全に依存するため、'1 つのサイズがすべてに収まらない' ため、'すぐに使用できない' を解決することはできません。

    • アプリケーションの構成と依存関係が異なります
    • また、リソースのメトリックとメトリックのしきい値は、正常で異常な状態を表す値の観点から微調整する必要があります。これは、包括的なアプリケーション機能とターゲットの非機能要件の影響を大きく受けます。

  • 階層化された正常性モデルを使用すると、アプリケーションの正常性を下位レベルの依存関係にトレースし直し、サービスの低下を迅速に根本原因にすることができます。

  • 個々のコンポーネントの正常性状態をキャプチャするには、そのコンポーネントの個別の運用特性を、運用環境の負荷を反映する安定した状態を理解する必要があります。 そのため、パフォーマンス テストは、アプリケーションの正常性を定義して継続的に評価するための重要な機能です。

  • クラウド ソリューション内のエラーは、単独では発生しない可能性があります。 1 つのコンポーネントで障害が発生すると、複数の機能や追加のコンポーネントが使用できなくなる可能性があります。

    • このようなエラーはすぐには観察できない場合があります。

設計の推奨事項

  • 測定可能な正常性モデルを優先度として定義して、アプリケーション全体の運用上の理解を明確にします。

    • 正常性モデルは、アプリケーション構造を階層化して反映する必要があります。
    • 基本レイヤーでは、Azure リソースなどの個々のアプリケーション コンポーネントを考慮する必要があります。
    • ビジネス コンテキスト化されたレンズをシステム フローの正常性に組み込むには、基本的なコンポーネントを主要な機能以外の要件と共に集計する必要があります。
    • アプリケーションの全体的な正常性の意味のある定義を構築するには、ビジネスの重要度に基づいて、システム フローを適切な重み付きで集計する必要があります。 財務的に重要なユーザー フローまたは顧客向けのユーザー フローに優先順位を付ける必要があります。
    • 正常性モデルの各レイヤーは、"正常" 状態と "異常" 状態が表す内容をキャプチャする必要があります。
    • サービスの低下を利用不可から分離するために、ヒース モデルで一時的な状態と非一時的な異常状態を区別できることを確認します。

  • 重要な非機能要件を係数として考慮して、マップされた依存コンポーネントの正常性スコアを集計することで、個々のアプリケーション コンポーネントとすべてのユーザー フローの詳細な正常性スコアを使用して正常性状態を表します。

    • ユーザー フローの正常性スコアは、マップされたすべてのコンポーネントで最も低いスコアで表し、ユーザー フローの非機能要件に対する相対的な達成率を考慮する必要があります。
    • 正常性スコアの計算に使用されるモデルは、動作中の正常性を一貫して反映する必要があります。そうでない場合は、新しい学習を反映するようにモデルを調整して再デプロイする必要があります。
    • 正常性スコアのしきい値を定義して、正常性状態を反映します。

  • 正常性スコアは、基になるメトリックに基づいて自動的に計算する必要があります。これは、監視パターンを通じて視覚化し、自動化された運用手順を通じて処理できます。

    • 運用チームが運用データを解釈してアプリケーションの正常性にマップする必要がなくなったように、正常性スコアは監視ソリューションの中核となる必要があります。

  • 正常性モデルを使用して、未加工の可用性ではなく可用性サービス レベル目標 (SLO) の達成率を計算し、サービスの低下と使用不能の間の境界が個別の SLO として反映されるようにします。

  • CI/CD パイプライン内の正常性モデルとテスト サイクルを使用して、コードと構成の更新後にアプリケーションの正常性が維持されていることを検証します。

    • 正常性モデルは、CI/CD プロセスの一部として、ロード テストとカオス テスト中に正常性を観察して検証するために使用する必要があります。

  • 正常性モデルの構築と維持は反復的なプロセスであり、継続的な改善を推進するためにエンジニアリング投資を調整する必要があります。

    • モデルの精度を継続的に評価して微調整するプロセスを定義し、機械学習モデルに投資してモデルをさらにトレーニングすることを検討します。

例 - 階層化された正常性モデル

これは、説明のために階層化されたアプリケーション正常性モデルの簡略化された表現です。 包括的でコンテキストに応じた正常性モデルは、Mission-Critical 参照の実装で提供されます。

正常性モデルを実装する場合は、主要なリソース レベル メトリックの集計と解釈を通じて、個々のコンポーネントの正常性を定義することが重要です。 リソース メトリックを使用する方法の例を次に示します。

ミッション クリティカルな正常性定義の例

この正常性の定義は、後で KQL クエリによって表されます。次のクエリ例で示すように、InsightsMetrics (Container insights) と AzureMetrics (AKS クラスターの診断設定) を集計し、モデル化された正常性しきい値と比較 (内部結合) します。

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

その後、結果のテーブル出力を正常性スコアに変換して、より高いレベルの正常性モデルで集計を容易にすることができます。

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

これらの集計されたスコアは、その後、Grafana などの視覚化ツールを使用して正常性モデルを示す依存関係グラフとして表すことができます。

この画像は、Azure Mission-Critical オンライン参照実装の階層化された正常性モデルの例を示しています。また、基本コンポーネントの正常性状態の変化が、ユーザー フローとアプリケーションの全体的な正常性にカスケード的な影響を与える方法を示しています (例の値は、前の図の表に対応しています)。

ミッション クリティカルなサンプル正常性モデルの視覚化

デモ ビデオ: 監視と正常性モデリングのデモ

相関分析のための統合データ シンク

アプリケーション コンポーネントと基になる Azure リソースの両方からのログとメトリックを考慮して、定義されたヒート モデルを正確に表すために、多くの運用データセットをすべてのシステム コンポーネントから収集する必要があります。 この膨大な量のデータは、最終的には、ほぼリアルタイムの解釈を可能にする形式で格納して、迅速な運用アクションを容易にする必要があります。 さらに、効果的な分析が無制限になるように、すべての包含データ セット間の相関関係が必要であり、正常性を階層化して表現できます。

統合データ シンクは、すべての運用データが迅速に格納され、アプリケーションの正常性の "単一ペイン" 表現を構築するための関連する分析で使用できることを確認するために必要です。 Azure では、 Azure Monitor の傘下にいくつかの異なる運用テクノロジが用意されており、Log Analytics ワークスペースは、運用データを格納および分析するためのコア Azure ネイティブ データ シンクとして機能します。

Mission Critical Health Data Collection

設計上の考慮事項

Azure Monitor

  • Azure Monitor はすべての Azure サブスクリプションに対して既定で有効になっていますが、Azure Monitor ログ (Log Analytics ワークスペース) と Application Insights リソースをデプロイして、データ収集とクエリ機能を組み込むように構成する必要があります。

  • Azure Monitor では、ログ、メトリック、分散トレースの 3 種類の監視データがサポートされています。

    • ログは、Azure Data Explorerに基づく Log Analytics ワークスペースに格納されます。 ログ クエリは、サブスクリプション間で共有できるクエリ パックに格納され、ダッシュボード、ブック、その他のレポートや視覚化ツールなどの監視コンポーネントを推進するために使用されます。
    • メトリックは、内部時系列データベースに格納されます。 ほとんどの Azure リソースでは、メトリックが自動的に収集され、93 日間 保持されます 。 メトリック データは、リソースの 診断設定 を使用して Log Analytics ワークスペースに送信することもできます。

  • すべての Azure リソースはログとメトリックを公開しますが、診断データを目的のデータ シンクにルーティングするようにリソースを適切に構成する必要があります。

ヒント

Azure には、Log Analytics ワークスペースにログとメトリックを送信するようにデプロイされたリソースが構成されるように適用できるさまざまな 組み込みポリシー が用意されています。

  • 規制コントロールで運用データが元の地域または国/地域内に残ることを要求することは珍しくありません。 規制要件では、重要なデータ型の保持期間が長期間にわたって規定されている場合があります。 たとえば、規制対象の銀行では、監査データを少なくとも 7 年間保持する必要があります。

  • 運用データ型が異なると、保持期間が異なる場合があります。 たとえば、セキュリティ ログを長期間保持する必要がある一方で、パフォーマンス データが AIOps のコンテキスト外で長期的な保持を必要とする可能性は低い場合があります。

  • 長期保有や監査のために、Log Analytics ワークスペースからデータを アーカイブ または エクスポート できます。

  • 専用クラスターには、サポートされている Azure リージョンのゾーン 障害からの保護をAvailability Zonesできるようにするデプロイ オプションが用意されています。 専用クラスターには、1 日のデータ取り込みコミットメントの最小値が必要です。

  • Log Analytics ワークスペースは、指定された Azure リージョンにデプロイされます。

  • Log Analytics ワークスペースの使用不能からデータが失われるのを防ぎ、複数の診断設定でリソースを構成できます。 各診断設定では、メトリックとログを個別の Log Analytics ワークスペースに送信できます。

    • 追加の Log Analytics ワークスペースに送信されるデータには、追加のコストが発生します。
    • 冗長な Log Analytics ワークスペースは、同じ Azure リージョンにデプロイすることも、リージョンの冗長性を強化するために別の Azure リージョンにデプロイすることもできます。
    • Azure リソースから別のリージョンの Log Analytics ワークスペースにログとメトリックを送信すると、リージョン間のデータエグレス コストが発生します。
    • 一部の Azure リソースでは、リソース自体と同じリージョン内に Log Analytics ワークスペースが必要です。
    • Log Analytics ワークスペースの可用性オプションの詳細については、「 Azure Monitor ログのベスト プラクティス 」を参照してください。

  • Log Analytics ワークスペース データは、Azure Storage にエクスポートすることも、継続的、スケジュールされた、または 1 回限りでAzure Event Hubsすることもできます。

    • データ エクスポートを使用すると、長期的なデータ アーカイブが可能になり、使用できないことによる運用データの損失から保護できます。
    • 使用可能なエクスポート先は、Azure Storage またはAzure Event Hubsです。 Azure Storage は、ゾーンまたはリージョンを含むさまざまな 冗長性レベル に対して構成できます。 Azure Storage へのデータ エクスポートでは、.json ファイル内にデータが格納されます。
    • データ エクスポート先は、Log Analytics ワークスペースと同じ Azure リージョン内にある必要があります。 Log Analytics ワークスペースと同じリージョン内にあるイベント ハブデータエクスポート先。 Azure Event Hubs geo ディザスター リカバリーは、このシナリオには適用できません。
    • データ エクスポートにはいくつかの制限があります。 データ エクスポート では、ワークスペース内の特定のテーブルのみがサポートされます 。
    • アーカイブを 使用すると、Log Analytics ワークスペースにデータを格納し、エクスポートせずにコストを削減して長期保有することができます。

  • Azure Monitor ログには ユーザー クエリの調整制限があり、監視ダッシュボードなど、クライアントの可用性が低下しているように見える場合があります。

    • ユーザーごとに 5 つの同時実行クエリ: 5 つのクエリが既に実行されている場合、実行中のクエリが終了するまで、追加のクエリがユーザーごとのコンカレンシー キューに配置されます。
    • コンカレンシー キューの時間: クエリがコンカレンシー キューに 3 分以上存在する場合、クエリは終了し、429 エラー コードが返されます。
    • コンカレンシー キューの深さの制限: コンカレンシー キューは 200 個のクエリに制限されており、追加のクエリは 429 エラー コードで拒否されます。
    • クエリレートの制限: すべてのワークスペースで 30 秒あたり 200 クエリというユーザーごとの制限があります。

  • クエリ パックは Azure Resource Manager リソースであり、Log Analytics ワークスペースが使用できない場合にログ クエリを保護および回復するために使用できます。

    • クエリ パックには JSON としてクエリが含まれており、他のコードとしてのインフラストラクチャ資産と同様に Azure の外部に格納できます。
      • Microsoft.Insights REST API を使用してデプロイできます。
      • Log Analytics ワークスペースを再作成する必要がある場合は、外部に格納された定義からクエリ パックを再デプロイできます。

  • Application Insights は、すべてのデータが格納されている Log Analytics ワークスペースに基づいて、ワークスペースベースのデプロイ モデルにデプロイできます。

  • Application Insights 内でサンプリングを有効にすると、送信されるテレメトリの量を減らし、データ取り込みコストを最適化できます。

  • Application Insights を含め、Azure Monitor によって収集されたすべてのデータは、取り込まれたデータの量とデータが保持される期間に基づいて 課金 されます。

    • Log Analytics ワークスペースに取り込まれたデータは、最初の 31 日間まで追加料金なしで保持できます (Sentinel が有効な場合は 90 日)
    • ワークスペースベースの Application Insights に取り込まれたデータは、最初の 90 日間は追加料金なしで保持されます。

  • Log Analytics コミットメント レベルの価格モデルでは、コストが削減され、データ取り込み料金に対する予測可能なアプローチが提供されます。

    • 予約レベルを超えた使用量は、現在のレベルと同じ価格で課金されます。

  • Log Analytics、Application Insights、Azure Data Explorer Kusto 照会言語 (KQL) を使用します。

  • Log Analytics クエリは、Log Analytics ワークスペース (savedSearches) 内の関数として保存されます。

設計の推奨事項

  • Log Analytics ワークスペースを統合データ シンクとして使用して、すべての運用データ セットに "単一ペイン" を提供します。

    • 使用されているすべてのデプロイ リージョンにわたって Log Analytics ワークスペースを分散化します。 アプリケーションのデプロイを使用する各 Azure リージョンでは、そのリージョンから送信されたすべての運用データを収集するために Log Analytics ワークスペースを検討する必要があります。 すべてのグローバル リソースでは、個別の専用 Log Analytics ワークスペースを使用する必要があります。これは、プライマリ デプロイ リージョン内にデプロイする必要があります。
      • すべての運用データを 1 つの Log Analytics ワークスペースに送信すると、単一障害点が発生します。
      • データ所在地の要件では、元のリージョンからのデータが禁止される場合があり、フェデレーション ワークスペースは既定でこの要件を解決します。
      • リージョン間でのログとメトリックの転送には、かなりのエグレス コストが伴います。
    • 同じリージョン内のすべてのデプロイ スタンプで、同じリージョンの Log Analytics ワークスペースを使用できます。

  • リージョンデプロイ スタンプが少ないアプリケーションで Azure Monitor を使用できない状態から保護するために、異なる Log Analytics ワークスペースを指す複数の診断設定を使用してリソースを構成することを検討してください。

  • すべてのアプリケーション コンポーネントにわたって一貫性があるアプリケーション パフォーマンス監視 (APM) ツールである Application Insights を使用して、"アプリケーション ログ、メトリック、トレースを収集" してください。

    • Application Insights をワークスペースベースの構成にデプロイして、各リージョンの Log Analytics ワークスペースに、アプリケーション コンポーネントと基になる Azure リソースの両方からのログとメトリックが含まれていることを確認します。

  • クロスワークスペース クエリを使用して、さまざまなワークスペース間で統一された "単一ペイン" を維持します。

  • クエリ パックを使用して、ワークスペースが利用できない場合にログ クエリを保護します。

    • アプリケーション Git リポジトリ内にクエリ パックをコードとしてのインフラストラクチャ資産として格納します。

  • すべての Log Analytics ワークスペースは、リージョンデプロイ スタンプ内のアプリケーション リソースとは異なるライフサイクルを持つ実行時間の長いリソースとして扱う必要があります。

  • 長期的な保持と分析のために Log Analytics ワークスペースから重要な運用データをエクスポートし、AIOps と高度な分析を容易にして、基になる正常性モデルを調整し、予測アクションを通知します。

  • 長期保有に使用するデータ ストアを慎重に評価する。すべてのデータをホットでクエリ可能なデータ ストアに格納する必要はありません。

    • 長期的な運用データ ストレージには、GRS 構成で Azure Storage を使用することを強くお勧めします。
      • Log Analytics ワークスペースのエクスポート機能を使用して、使用可能なすべてのデータ ソースを Azure Storage にエクスポートします。

  • ログ分析内の運用データ型に対して適切な保持期間を選択し、"ホット" 監視要件が存在するワークスペース内で長い保持期間を構成します。

  • Azure Policyを使用して、すべてのリージョン リソースが運用データを適切な Log Analytics ワークスペースにルーティングするようにします。

Note

Azure ランディング ゾーンにデプロイするときに、運用データの一元的なストレージの要件がある場合は、インスタンス化時にデータを フォーク して、アプリケーション専用の一元化されたツールと Log Analytics ワークスペースの両方に取り込むことができます。 または、中央チームがアプリケーション データに対してクエリを実行できるように、アプリケーション Log Analytics ワークスペースへのアクセスを公開します。 最終的には、ソリューションから生成された運用データが、アプリケーション専用の Log Analytics ワークスペース内で使用できるようになることが重要です。

SIEM 統合が必要な場合は、生のログ エントリを送信するのではなく、重要なアラートを送信します。

  • Application Insights 内でサンプリングを構成するのは、パフォーマンスを最適化する必要がある場合、またはサンプリングしない場合に限り、コストが高くなります。

    • 過剰なサンプリングを行うと、操作信号が見逃されたり不正確になったりする可能性があります。

  • すべてのトレース イベントとログ メッセージに関連付け ID を使用して、特定の要求に関連付けます。

    • 失敗した要求だけでなく、すべての呼び出しの関連付け ID を呼び出し元に返します。

  • 正常性モデルを通知し、必要に応じて後続のトラブルシューティングや根本原因分析を容易にするために、アプリケーション コードに適切なインストルメンテーションとログが組み込まれているようにします。

    • アプリケーション コードでは、Application Insights を使用して 分散トレースを容易にする必要があります。呼び出し元に、エラー発生時に関連付け ID を含む包括的なエラー メッセージを提供する必要があります。

  • すべてのログ メッセージ に構造化ログ を使用します。

  • すべてのアプリケーション コンポーネントに意味のある正常性プローブを追加します。

    • AKS を使用する場合は、Kubernetes がポッドが正常であるか異常かを正しく判断できるように、各デプロイ (ポッド) の正常性エンドポイントを構成します。
    • Azure App Serviceを使用する場合は、まだ準備が整っていないインスタンスにトラフィックを送信し、異常なインスタンスが迅速にリサイクルされるようにして、スケールアウト操作でエラーが発生しないように正常性チェックを構成します。

アプリケーションが Microsoft Mission-Critical サポートにサブスクライブされている場合は、Microsoft サポートによってアプリケーションの正常性をより正確にモデル化できるように、主要な正常性プローブをMicrosoft サポートに公開することを検討してください。

  • 正常な正常性チェック要求をログに記録します。データ ボリュームの増加は、分析モデリングのための追加の分析情報を提供するため、アプリケーションのパフォーマンスのコンテキストで許容できない場合を除きます。

  • 運用データの毎日の取り込みを制限する 日次上限を適用するように運用 Log Analytics ワークスペースを構成しないでください。これは、重要な運用データが失われる可能性があるためです。

    • 開発やテストなどの低い環境では、1 日あたりの上限を省略可能なコスト削減メカニズムと見なすことができます。

  • 運用データ取り込みボリュームが最小レベルのしきい値を満たしている場合は、"従量課金制" 価格モデルに対するコスト効率を高めるためにコミットメントレベルベースの価格を使用するように Log Analytics ワークスペースを構成します。

  • ソース管理を使用して Log Analytics クエリを格納し、CI/CD オートメーションを使用して関連する Log Analytics ワークスペース インスタンスにデプロイすることを強くお勧めします。

グラフ

効果的な運用を実現し、信頼性を最大限にするには、重要な運用データを使って正常性モデルを視覚的に表現することが不可欠です。 ダッシュボードは最終的に、DevOps チームのアプリケーションの正常性に関するほぼリアルタイムの分析情報を提供するために利用され、安定した状態からの逸脱の迅速な診断が容易になります。

Microsoft では、Azure ダッシュボード、Power BI、Azure Managed Grafana (現在プレビュー段階) など、いくつかのデータ視覚化テクノロジを提供しています。 Azure ダッシュボードは、Azure Monitor 内の運用データに対して、組み込まれたすぐに使用できる視覚化ソリューションを提供するように配置されています。 そのため、ミッション クリティカルなワークロードの運用データとアプリケーションの正常性を視覚的に表現する際に果たす基本的な役割があります。 ただし、包括的な監視プラットフォームとしての Azure ダッシュボードの位置付けにはいくつかの制限があり、その結果、Azure 内のマネージド ソリューションとしても提供される Grafana などの市場をリードする監視ソリューションの補足的な使用について考慮する必要があります。

このセクションでは、Azure Dashboards と Grafana を使用して、アプリケーションの正常性に技術的およびビジネス レンズを提供し、DevOps チームと効果的な運用を可能にする堅牢なダッシュボード エクスペリエンスを構築します。 堅牢なダッシュボードは、既に発生した問題を診断し、発生した問題を検出して対応する運用チームをサポートするために不可欠です。

設計上の考慮事項

  • ログ クエリを使用して正常性モデルを視覚化する場合は、 同時クエリとキューに登録されたクエリに対する Log Analytics の制限と、後続のクエリがキューに入れ、調整されたクエリの全体的な速度に注意してください。

  • 正常性スコアの計算と表現に使用される運用データを取得するクエリは、Log Analytics または Azure Data Explorerで書き込んで実行できます。

  • Log Analytics にはいくつかの クエリ制限が課されており、運用ダッシュボードを設計する場合に対応するように設計する必要があります。

  • CPU 使用率やネットワーク スループットなど、未加工のリソース メトリックを視覚化するには、運用チームによる手動評価で正常性状態への影響を判断する必要があり、アクティブなインシデント時には困難になる可能性があります。

  • Grafana などのツール内で複数のユーザーがダッシュボードを使用する場合、Log Analytics に送信されるクエリの数はすぐに乗算されます。

    • Log Analytics で同時クエリの制限に達すると、後続のクエリがキューに入り、ダッシュボードのエクスペリエンスが "遅い" と感じます。

設計上の推奨事項

  • すべてのリージョン Log Analytics ワークスペースとグローバル Log Analytics ワークスペースからクエリされた出力を収集して提示し、アプリケーションの正常性の統合ビューを構築します。

注意

Azure ランディング ゾーンにデプロイする場合は、オンプレミス通信用の ExpressRoute など、プラットフォーム リソースに対する主要な依存関係が存在する場合は、 中央プラットフォームの Log Analytics ワークスペース に対してクエリを実行することを検討してください。

  • "交通信号" モデルは、"正常" と "異常" 状態を視覚的に表すために使用する必要があります。緑色は、主要な非機能要件が完全に満たされ、リソースが最適に利用されるタイミングを示すために使用されます。 "正常"、"機能低下"、および "使用不可" 状態を表すには、"Green"、"Amber、および "Red" を使用します。

  • Azure ダッシュボードを使用して、グローバル リソースとリージョンデプロイ スタンプの運用レンズを作成します。これは、Azure Front Door の要求数、Azure Cosmos DB のサーバー側待機時間、Event Hubs の受信/送信メッセージ、AKS の CPU 使用率またはデプロイ状態などの主要なメトリックを表します。 ダッシュボードは、運用効率を高め、障害シナリオからの学習内容を活用して、DevOps チームが確実に主要なメトリックを直接可視化できるように調整する必要があります。

  • 正常性モデルを正確に表し、必要なビジネス要件を Azure ダッシュボードで表現できない場合は、Grafana を代替の視覚化ソリューションとして検討し、市場をリードする機能と広範なオープンソース プラグイン エコシステムを提供することを強くお勧めします。 マネージド Grafana プレビュー オファリングを評価して、Grafana インフラストラクチャの管理の運用上の複雑さを回避します。

  • セルフホステッド Grafana をデプロイする場合は、高可用性と geo 分散設計を採用して、重要な運用ダッシュボードがリージョンのプラットフォーム障害やカスケード エラー シナリオに対する回復性を確保できるようにします。

    • 構成状態を Azure Database for Postgres や MySQL などの外部データストアに分離して、Grafana アプリケーション ノードをステートレスに保ちます。

      • デプロイ リージョン間でデータベース レプリケーションを構成します。

    • コンテナー ベースのデプロイを使用して、リージョン内の高可用性構成で Grafana ノードを App Services にデプロイします。

      • App Serviceインスタンスを、検討されたデプロイ リージョン全体にデプロイします。

      App Services は低摩擦のコンテナー プラットフォームを提供します。これは、運用ダッシュボードなどの低スケールのシナリオに最適であり、AKS から Grafana を分離することで、プライマリ アプリケーション プラットフォームとそのプラットフォームの運用表現の間で懸念事項を明確に分離できます。 詳細な構成の推奨事項については、「アプリケーション プラットフォームの配置解除」領域を参照してください。

    • GRS 構成で Azure Storage を使用して、カスタム ビジュアルとプラグインをホストおよび管理します。

    • App Service とデータベース読み取りレプリカの Grafana コンポーネントを少なくとも 2 つのデプロイ リージョンにデプロイし、Grafana がすべての検討対象デプロイ リージョンにデプロイされるモデルを採用することを検討してください。

= 99.99% SLO を >対象とするシナリオでは、主要な運用ダッシュボードの全体的な信頼性を最大化するために、Grafana を少なくとも 3 つのデプロイ リージョン内にデプロイする必要があります。

  • KQL 'union' 演算子を使用するなど、クエリを 1 つまたは少数のクエリに集計して Log Analytics クエリの制限を軽減し、ダッシュボードで適切な更新レートを設定します。

    • 適切な最大更新速度は、ダッシュボード クエリの数と複雑さに依存します。実装されたクエリの分析が必要です。

  • Log Analytics の同時クエリ制限に達している場合は、ダッシュボードに必要なデータをAzure SQLなどのハイ パフォーマンス データストアに (一時的に) 格納することで、取得パターンを最適化することを検討してください。

自動インシデント対応

アプリケーション正常性の視覚的な表現により、問題の検出と診断をサポートするための貴重な運用およびビジネス分析情報が得られますが、運用チームの準備と解釈、および後続の人によってトリガーされる応答の有効性に依存しています。 そのため、信頼性を最大限に高めるためには、事前に検出してほぼリアルタイムで問題に対応するための広範なアラートを実装する必要があります。

Azure Monitor には、 アクション グループを介して運用シグナルを検出、分類、対応するための広範なアラート フレームワークが用意されています。 したがって、このセクションでは、正常なアプリケーション状態からの現在または潜在的な逸脱に応じて、自動化されたアクションを推進するための Azure Monitor アラートの使用に焦点を当てます。

重要

アラートと自動化されたアクションは、重大な悪影響が発生する前に、問題が発生した場合に効果的に検出し、迅速に対応するために重要です。 アラートは、受信シグナルを解釈し、発生する前に問題を回避するためのメカニズムも提供します。

設計上の考慮事項

  • アラート ルールは、受信シグナルに対して条件付き条件が満たされたときに発生するように定義されます。これには、メトリック、ログ クエリ、可用性テストなど、さまざまな データ ソースを含めることができます。

  • アラートは、特定のリソースの Log Analytics または Azure Monitor 内で定義できます。

  • Log Analytics 内ですべての診断データ ポイントが使用できるわけではないため、一部のメトリックは Azure Monitor 内でのみ調べられます。

  • Azure Monitor Alerts API を使用して、アクティブなアラートと履歴アラートを取得できます。

  • アラートとアクション グループにはサブスクリプションの制限があり、次の目的で設計する必要があります。

    • 構成可能なアラート ルールの数には制限があります。
    • Alerts API には 調整制限があり、極端な使用シナリオでは考慮する必要があります。
    • アクション グループには、構成可能な応答の数に対して いくつかのハード制限 があります。これは、 用に設計する必要があります。
      • 各応答の種類には、電子メールを除いて 10 個のアクションの制限があり、アクション数は 1,000 個に制限されています。

  • アラートは、モデルの "ルート" スコアリング関数から保存されたログ検索クエリのアラート ルールを作成することで、階層化された正常性モデル内に統合できます。 たとえば、'WebsiteHealthScore' を使用し、"異常" 状態を表す数値に対してアラートを生成します。

設計の推奨事項

  • リソース中心のアラートの場合は、Azure Monitor 内にアラート ルールを作成して、アラート ルールの条件に対してすべての診断データを確実に使用できるようにします。

  • DevOps アプローチをサポートするためにサービス チームと連携して、最小限の数のアクション グループ内に自動化されたアクションを統合します。

  • 可能な場合は、Azure ネイティブの自動スケール機能を使用して、自動スケール操作を通じて過剰なリソース使用率シグナルに対応します。 組み込みの自動スケール機能を適用できない場合は、コンポーネントの正常性スコアを使用してシグナルをモデル化し、自動スケール操作で応答するタイミングを決定します。 自動スケール操作が、コンポーネント間のスケール関係を定量化する容量モデルに従って定義されていることを確かめ、スケール応答に、他のコンポーネントとの関係でスケーリングする必要があるコンポーネントが含まれるようにします。

  • 優先順位付けされた順序に対応するためのアクションをモデル化します。これは、ビジネスへの影響によって決定する必要があります。

  • Azure Monitor Alerts API を使用して履歴アラートを収集し、高度な分析のために "コールド" 運用ストレージに組み込みます。

  • 自動応答では満たされない重大な障害シナリオの場合は、手動による解釈とサインアウトが提供されたら、迅速かつ一貫したアクションを推進するために運用 'Runbook オートメーション' がインプレースされていることを確認してください。 アラート通知を使用して、手動による解釈が必要な問題を迅速に特定する

  • エンジニアリング スプリント内に許容量を作成してアラートの段階的な改善を推進し、これまで考慮されていない新しい障害シナリオを新しい自動化されたアクション内で完全に対応できるようにします。

  • CI/CD プロセスの一部として運用準備テストを実施し、デプロイ更新の主要なアラート ルールを検証します。

予測アクションと AI 操作 (AIOps)

機械学習モデルを適用して運用データの関連付けと優先順位付けを行うことができます。これにより、過剰なアラート "ノイズ" のフィルター処理と、影響を引き起こす前の問題の予測に関連する重要な分析情報を収集し、その場合のインシデント対応を加速することができます。

具体的には、AIOps 手法を、システム、ユーザー、DevOps プロセスの動作に関する重要な分析情報に適用できます。 これらの分析情報には、現在発生している問題の特定 (検出)、問題が発生している理由の定量化 (診断)、将来何が起こるかを通知する (予測) などがあります。 このような分析情報を使用して、主要なビジネス メトリック、システム品質メトリック、DevOps 生産性メトリックを使用して、アクティブまたは潜在的な問題を軽減するためにアプリケーションを調整および最適化するアクションを推進し、ビジネスへの影響に応じて優先順位を付けることができます。 実施されたアクションは、基になるモデルをさらにトレーニングし、追加の効率を高めるフィードバック ループを通じてシステムに組み込むことができます。

ミッション クリティカルな AIOps の方法論

Azure 内には、Azure Synapseや Azure Databricks など、複数の分析テクノロジがあり、AIOps の分析モデルの構築とトレーニングに使用できます。 そのため、このセクションでは、AIOps に対応し、予測アクションを推進するためにこれらのテクノロジをアプリケーション設計内でどのように配置できるかに焦点を当て、Azure のデータ サービスのベストと強力な新機能を組み合わせることで摩擦を軽減するAzure Synapseに焦点を当てます。

AIOps は、問題が発生する前により適切に対応して防止するために、予測アクションを推進し、持続的な期間にわたって観察される複雑な運用シグナルを解釈および関連付けるために使用されます。

設計上の考慮事項

  • Azure Synapse Analytics には、複数の Machine Learning (ML) 機能が用意されています。

    • ML モデルは、MLLib、SparkML、MMLSpark などのライブラリと、 Scikit Learn などの一般的なオープンソース ライブラリを使用して、Synapse Spark プールでトレーニングおよび実行できます。
    • ML モデルは、PySpark/Python、Scala、.NET などの一般的なデータ サイエンス ツールを使用してトレーニングできます。

  • Synapse Analytics は、Azure Synapse Notebooks を介して Azure ML と統合されています。これにより、自動 ML を使用して Azure ML ワークスペースで ML モデルをトレーニングできます。

  • Synapse Analytics では、 Azure Cognitive Services を使用して ML 機能を使用して、 異常検出など、さまざまなドメインの一般的な問題を解決することもできます。 Cognitive Services は、Azure Synapse、Azure Databricks、およびクライアント アプリケーションの SDK と REST API を使用して使用できます。

  • Azure Synapseは、オーケストレーション パイプライン内でデータを抽出、変換、読み込み (ETL) または取り込むためのAzure Data Factory ツールとネイティブに統合されます。

  • Azure Synapseを使用すると、Azure Blob Storage またはAzure Data Lake Storageに格納されているデータに対する外部データセットの登録が可能になります。

    • 登録されたデータセットは、Synapse Spark プールのデータ分析タスクで使用できます。

  • Azure Databricks は、追加の Spark 機能のためにAzure Synapse Analytics パイプラインに統合できます。

    • Synapse は、データの読み取りと Databricks クラスターへの送信を調整します。このクラスターは、ML モデルトレーニング用に変換して準備できます。

  • 通常、ソース データは分析と ML 用に準備する必要があります。

    • Synapse には、Apache Spark、Synapse Notebook、T-SQL と組み込みの視覚化を使用したサーバーレス SQL プールなど、データ準備に役立つさまざまなツールが用意されています。

  • トレーニング、運用化、デプロイされた ML モデルは、Synapse での バッチ スコアリングに使用できます。

    • CI/CD パイプラインで回帰予測や劣化予測を実行するなどの AIOps シナリオでは、 リアルタイム スコアリングが必要になる場合があります。

  • Azure Synapseにはサブスクリプションの制限があります。これは、AIOps 手法のコンテキストで完全に理解する必要があります。

  • AIOps を完全に組み込むには、ほぼリアルタイムの監視データをリアルタイムの ML 推論モデルに継続的にフィードする必要があります。

    • 異常検出などの機能は、監視データ ストリーム内で評価する必要があります。

設計の推奨事項

  • AIOps モデルのトレーニングで完全な運用データセットを使用できるように、すべての Azure リソースとアプリケーション コンポーネントが完全にインストルメント化されていることを確認します。

  • Log Analytics の運用データをグローバルおよびリージョンの Azure Storage アカウントからAzure Synapseに取り込んで分析します。

  • Azure Monitor Alerts API を使用して履歴アラートを取得し、運用データを ML モデル内で使用するためにコールド ストレージ内に格納します。 Log Analytics データエクスポートを使用する場合は、エクスポートされた Log Analytics データと同じ Azure Storage アカウントに履歴アラート データを格納します。

  • 取り込まれたデータが ML トレーニング用に準備されたら、Azure Storage に書き戻して、Synapse データ準備コンピューティング リソースの実行を必要とせずに ML モデルのトレーニングに使用できるようにします。

  • ML モデルの運用化でバッチスコアリングとリアルタイム スコアリングの両方がサポートされていることを確認します。

  • AIOps モデルが作成されたら、MLOps を実装し、DevOps プラクティスを適用して、トレーニング、運用化、スコアリング、継続的な改善のための ML ライフサイクルを自動化 します。 AIOps ML モデルの反復 CI/CD プロセスを作成します。

  • 管理と統合のオーバーヘッドが少ないため、特定の予測シナリオについて Azure Cognitive Services を評価します。 異常 検出を 検討して、監視データ ストリームで予期しない差異にすばやくフラグを設定します。

次のステップ

デプロイとテストに関する考慮事項を確認します。

デプロイとテスト