次の方法で共有

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

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

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

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

Important

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

信頼性を最大限に高めるために努力する場合、運用の成熟度には主に 3 つのレベルがあります。

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

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

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

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

Important

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

設計に関する考慮事項

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

  • ヘルスモデルは、それが表すソリューションの文脈に完全に依存しているため、誰にでも合うとは限らず、そのままでは解決できません。

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

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

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

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

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

設計に関する推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

これは、説明のために階層化されたアプリケーション正常性モデルの簡略化された表現です。 包括的でコンテキストに合わせたヘルスモデルは、ミッションクリティカルリファレンス実装で提供されています。

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

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

この正常性の定義は、後で 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 ネイティブ データ シンクとして機能します。

ミッションクリティカルな健康データの収集

設計に関する考慮事項

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 ワークスペースにログとメトリックを送信するようにデプロイされたリソースを確実に構成するために適用できるさまざまな Built-In ポリシー が用意されています。

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

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

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

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

  • 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 ワークスペース データ は、継続的、スケジュール済み、または 1 回限りで Azure Storage または Azure Event Hubs にエクスポートできます。

    • データ エクスポートを使用すると、長期的なデータ アーカイブが可能になり、使用できないことによる運用上のデータ損失から保護できます。
    • 使用可能なエクスポート先は、Azure Storage または Azure Event Hubs です。 Azure Storage は、ゾーンやリージョンなど、さまざまな 冗長性レベル に対して構成できます。 Azure Storage へのデータ エクスポートでは、.json ファイル内にデータが格納されます。
    • データ エクスポート先は、Log Analytics ワークスペースと同じ Azure リージョン内にある必要があります。 Log Analytics ワークスペースと同じリージョン内にあるイベント ハブデータエクスポート先。 Azure Event Hubs ジオディザスターリカバリーは、このシナリオには適用されません。
    • データ エクスポートにはいくつかの制限があります。 データエクスポート では、ワークスペース内の特定のテーブルのみがサポートされます 。
    • アーカイブを 使用すると、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 ワークスペースを指す複数の診断設定を使用してリソースを構成することを検討してください。

  • Application Insights をすべてのアプリケーション コンポーネントで一貫したアプリケーション パフォーマンス監視 (APM) ツールとして使用して、アプリケーション ログ、メトリック、トレースを収集します。

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

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

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

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

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

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

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

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

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

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

注

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 ワークスペースを構成しないでください。これにより、重要な運用データが失われる可能性があるためです。

    • 開発やテストなどの低い環境では、日次上限はオプションのコスト削減メカニズムと見なすことができます。

  • 運用データ取り込みボリュームが最小レベルのしきい値を満たしている場合は、コミットメントレベルベースの価格を使用するように 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 をデプロイする場合は、高可用性で地理的に分散された設計を採用して、重要な運用ダッシュボードが地域のプラットフォームの障害や連鎖的なエラー シナリオに対して回復性を持つようにします。

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

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

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

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

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

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

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

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

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

    • 適切な最大リフレッシュ レートは、ダッシュボード クエリの数と複雑さによって異なります。実装されたクエリの分析が必要です。

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

自動インシデント対応

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

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

Important

重大な悪影響が発生する前に、問題が発生したときに問題を効果的に検出して迅速に対応するには、アラートと自動アクションが重要です。 アラートは、受信信号を解釈し、発生する前に問題を防ぐために対応するメカニズムも提供します。

設計に関する考慮事項

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

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

  • 一部のメトリックは Azure Monitor 内でのみ尋問可能です。Log Analytics 内ですべての診断データ ポイントが使用できるわけではありません。

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

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

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

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

設計に関する推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

Azure Synapse や Azure Databricks など、Azure 内には複数の分析テクノロジがあり、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 ストレージ アカウントから 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 を評価します。 異常 検出 を検討して、観測データ ストリームの予期しない差異に迅速にフラグを設定します。

次のステップ

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

展開とテスト

  • Last updated on