監視システムの設計と作成に関する推奨事項

[アーティクル]
11/15/2023

この Azure Well-Architected Framework オペレーショナルエクセレンスチェックリストの推奨事項に適用されます。

OE:07	監視システムを設計して実装し、設計の選択を検証し、将来の設計とビジネス上の決定を通知します。このシステムは、ワークロードのインフラストラクチャとコードから出力される運用テレメトリ、メトリック、ログをキャプチャして公開します。

関連ガイド: アプリケーションのインストルメント化に関する推奨事項

このガイドでは、監視システムの設計と作成に関する推奨事項について説明します。ワークロードのセキュリティ、パフォーマンス、信頼性を効果的に監視するには、すべての監視、検出、アラート機能の基盤を提供する独自のスタックを備えた包括的なシステムが必要です。

定義

期間	定義
ログ	記録されたシステムイベント。ログには、構造化テキスト形式または自由形式のテキスト形式のさまざまな種類のデータを含めることができます。タイムスタンプが含まれています。
メトリック	一定の間隔で収集される数値。メトリックは、特定の時点におけるシステムの一部の側面を表します。

主要な設計戦略

ワークロードの包括的な監視システム設計を実装するには、次の主要な教義に従います。

実用的な場合は常に、プラットフォームで提供される監視ツールを利用します。通常は構成が非常に少なく、実現が困難なワークロードに関する深い分析情報を提供できます。
ワークロードスタック全体からログとメトリックを収集します。すべてのインフラストラクチャリソースとアプリケーション関数は、標準化された意味のあるデータを生成するように構成する必要があり、そのデータを収集する必要があります。
収集されたデータを、標準化された信頼性の高いセキュリティで保護されたストレージソリューションに格納します。
保存されたデータを処理して、分析および視覚化ソリューションで処理できるようにします。
処理されたデータを分析して、ワークロードの状態を正確に判断します。
ワークロードチームや他の利害関係者の意味のあるダッシュボードまたはレポートで、ワークロードの状態を視覚化します。
問題が発生したときにワークロードチームに通知するために、インテリジェントに定義されたしきい値に対するアクション可能なアラートとその他の自動応答を構成します。
全体的なワークロードテストプラクティスに監視システムとアラートシステムを含めます。
監視とアラートシステムが継続的な改善の範囲にあることを確認します。運用環境でのアプリケーションとインフラストラクチャの動作は、継続的な学習機会を提供します。これらのレッスンを監視とアラートの設計に組み込みます。
収集して分析した監視データをシステムフローとユーザーフローに関連付けて、ワークロードの全体的な正常性に加えて、フローの正常性とデータを関連付けます。フローの観点からそのデータを分析すると、監視戦略を正常性モデルに合わせて調整するのに役立ちます。

監視システムのすべての機能を可能な限り自動化する必要があり、すべて毎日、継続的に実行する必要があります。

このワークフローパイプラインは、監視システムを示しています。

コレクション

注意

ログ記録を有効にするには、アプリケーションをインストルメント化する必要があります。詳細については、インストルメンテーションガイドを参照してください。

テレメトリやログやメトリックなどのイベントをキャプチャするには、インフラストラクチャリソースでもアプリケーション機能でも、すべてのワークロードコンポーネントを構成する必要があります。

ログは主に、異常の検出と調査に役立ちます。通常、ログはワークロードコンポーネントによって生成され、監視プラットフォームに送信されるか、自動化によって監視プラットフォームによってプルされます。

メトリックは、主に正常性モデルを構築し、ワークロードのパフォーマンスと信頼性の傾向を特定するのに役立ちます。メトリックは、顧客の使用行動の傾向を特定するのにも役立ちます。これらの傾向は、お客様の観点から改善に関する決定を導くのに役立ちます。通常、メトリックは監視プラットフォームで定義され、監視プラットフォームやその他のツールはワークロードをポーリングしてメトリックをキャプチャします。

アプリケーションデータ

アプリケーションの場合、収集サービスは、インストルメンテーションデータを生成するアプリケーションから自律的に実行できるアプリケーションパフォーマンス管理 (APM) ツールです。 APM を有効にすると、重要なメトリックをリアルタイムで履歴的に明確に可視化できます。適切なレベルのログ記録を使用します。ログ記録の量が膨大になると、膨大なコストが発生する可能性があります。環境に応じてログレベルを設定します。たとえば、低い環境では、運用環境と同じレベルの詳細度は必要ありません。

アプリケーションログは、エンドツーエンドのアプリケーションライフサイクルをサポートします。ログ記録は、アプリケーションがさまざまな環境でどのように動作するか、どのイベントが発生するか、および発生する条件を理解するために不可欠です。

すべての主要な環境でアプリケーションログとイベントを収集することをお勧めします。環境ごとに異なるデータストアを使用して、可能な限り環境間でデータを分離します。それが実用的な場合は、フィルターを使用して、重要でない環境が運用ログの解釈を複雑にしないようにします。最後に、アプリケーション全体の対応するログエントリは、それぞれのトランザクションの関連付け ID をキャプチャする必要があります。

構造化データ型では、非構造化文字列型ではなく、マシンが読み取り可能なデータポイントを使用して、アプリケーションイベントをキャプチャする必要があります。既知のスキーマを使用する構造化形式を使用すると、ログの解析と分析が容易になります。また、構造化されたデータは、インデックスの作成や検索が容易なため、レポート作成が大幅に簡素化されます。

データは、コンピューター、オペレーティングシステム、またはネットワークプロトコルに依存しない形式にする必要があります。たとえば、ETL/ETW ではなく、JSON、MessagePack、Protobuf などの自己記述形式で情報を出力します。標準形式を使用すると、システムは処理パイプラインを構築できます。標準形式のデータの読み取り、変換、送信を行うコンポーネントを簡単に統合できます。

インフラストラクチャデータ

ワークロード内のインフラストラクチャリソースの場合は、ログとメトリックの両方を確実に収集してください。サービスとしてのインフラストラクチャ (IaaS) システムの場合は、ワークロードの正常性に関連するメトリックに加えて、OS、アプリケーション層、診断ログをキャプチャします。サービスとしてのプラットフォーム (PaaS) リソースの場合、基になるインフラストラクチャに関連するログをキャプチャする機能が制限される場合がありますが、ワークロードの正常性に関連するメトリックに加えて診断ログをキャプチャできることを確認してください。

可能な限り、クラウドプラットフォームからログを収集します。サブスクリプションのアクティビティログと管理プレーンの診断ログを収集できる場合があります。

収集戦略

各コンポーネントから手動で利用統計情報を収集することは避けてください。データを中央の場所に移動し、そこに統合します。マルチリージョンソリューションの場合は、まずリージョンごとにデータを収集、統合、格納してから、リージョンデータを 1 つの中央システムに集計することをお勧めします。

トレードオフ: リージョンおよび一元化されたデータストアを持つことにはコストの影響があることに注意してください。

帯域幅の使用を最適化するために、データの重要度に応じて優先順位をつけます。緊急性の低いデータは、バッチで転送することが可能です。ただし、このデータに時間の機密情報が含まれている場合は特に、このデータを無期限に遅延してはなりません。

コレクションサービスがインストルメンテーションデータの収集に使用できる主なモデルは 2 つあります。

プルモデル: アプリケーションの各インスタンスのさまざまなログやその他のソースからデータをアクティブに取得します。
プッシュモデル: アプリケーションの各インスタンスを構成するコンポーネントからデータが送信されるのを受動的に待機します。

監視エージェント

プルモデルでは、監視エージェントを使用できます。エージェントは、アプリケーションの各インスタンスを使用して個別のプロセスでローカルに実行され、定期的にデータをプルし、アプリケーションのすべてのインスタンスで共有される共通ストレージに情報を直接書き込みます。

注意

監視エージェントの使用は、データソースから自然に取得されるインストルメンテーションデータをキャプチャするのに最適です。これは、1 つの場所の限られた数のノードで実行される小規模なアプリケーションに適しています。たとえば、動的管理ビュー SQL Serverからの情報や、Azure Service Bus キューの長さなどがあります。

パフォーマンスに関する考慮事項

複雑で拡張性の高いアプリケーションでは、大量のデータが生成される可能性があります。データの量によって、1 つの中央の場所で使用できる I/O 帯域幅が簡単に過負荷になる可能性があります。テレメトリソリューションは、ボトルネックになってはならず、システムの拡張に合わせてスケーラブルである必要があります。理想的には、システムの一部が失敗した場合に重要な監視情報 (監査や課金データなど) を失うリスクを軽減するために、ある程度の冗長性を組み込む必要があります。

インストルメンテーションデータをバッファーに格納する方法の 1 つは、キューを使用することです。

このアーキテクチャでは、カスタムデータコレクションサービスがデータをキューにポストします。メッセージキューは、"少なくとも 1 回" のセマンティクスを提供するため、メッセージキューが適しています。これにより、キューに置かれたデータがポストされた後に失われることはありません。ストレージ書き込みサービスは、別の worker ロールを使用して実装できます。 Priority Queue パターンを使用して、このアーキテクチャを実装できます。

スケーラビリティのために、ストレージ書き込みサービスの複数のインスタンスを実行できます。大量のイベントまたは大量のデータポイントが監視されている場合は、Azure Event Hubsを使用して、処理とストレージのために別のコンピューティングインスタンスにデータをディスパッチできます。

統合戦略

アプリケーションの 1 つのインスタンスから収集されたデータは、そのインスタンスの正常性とパフォーマンスのローカライズされたビューを提供します。システムの全体的な正常性を評価するには、ローカルビューからデータのいくつかの側面を統合する必要があります。これは、データが格納された後に行うことができますが、場合によっては、データの収集時に行うことができます。

インストルメンテーションデータは、データを統合してフィルターやクリーンアッププロセスとして機能する別個のデータ統合サービスに渡すことができます。たとえば、アクティビティ ID など、同じ相関関係情報を含むインストルメンテーションデータを正規化できます。 (ユーザーは、1 つのノードでビジネス操作を開始し、最初のノードで障害が発生した場合、または負荷分散の構成方法により、別のノードに転送される可能性があります)。このプロセスでは、重複したデータを検出して削除することもできます。 (テレメトリサービスがメッセージキューを使用してインストルメンテーションデータをストレージにプッシュする場合、重複が発生する可能性があります)。

ストレージ

ストレージソリューションを選択する場合は、データの種類、データの使用方法、および必要な緊急性を考慮してください。

注意

非運用環境と運用環境に個別のストレージソリューションを使用して、各環境のデータを簡単に識別および管理できるようにします。

ストレージテクノロジ

さまざまな種類の情報が、各型の使用方法に最も適したテクノロジに格納される、ポリグロット永続化アプローチを検討してください。

たとえば、Azure Blob Storageと Azure Table Storage にも同様の方法でアクセスできます。ただし、それらに対して実行できる操作は、保持するデータの粒度と同様に異なります。より多くの分析処理を実行する必要がある場合や、データにフルテキスト検索機能が必要な場合は、特定の種類のクエリ処理やデータアクセス用に最適化された機能が用意されているデータストレージを使用することが適切なことがあります。次に例を示します。

パフォーマンスカウンターデータはアドホック分析ができるように、SQL データベースに格納します。
トレースログは、Azure Monitor ログまたは Azure Data Explorerに格納することをお勧めします。
HDFS ソリューションにセキュリティ情報を格納できます。

同じインストルメンテーションデータを 1 つ以上の目的で使う必要がある場合があります。たとえば、パフォーマンスカウンターを使用して、時間の経過に伴うシステムパフォーマンスの履歴ビューを提供できます。他の使用状況データと組み合わせて、顧客の課金情報を生成することもできます。このような状況では、同じデータが複数の宛先に送信される場合があります。たとえば、課金情報を保持するための長期的なストアとなるドキュメントデータベースや、複雑なパフォーマンス分析を処理するための多次元ストアに送信される場合があります。

リソースロックや論理的な削除など、誤った削除からデータを保護する機能を有効にしてください。

また、ロールベースのアクセス制御を使用してストレージへのアクセスをセキュリティで保護し、データにアクセスする必要がある個人のみがアクセスできるようにしてください。

統合サービス

共有ストレージからデータを定期的に取得し、その目的に応じてデータをパーティション分割してフィルター処理し、適切なデータストアのセットに書き込む別のサービスを実装できます。

別のアプローチでは、統合とクリーンアッププロセスにこの機能を含め、取得したデータを中間の共有ストレージ領域に保存することなく、これらのストアに直接書き込みます。

各アプローチには、それぞれ長所と短所があります。個別のパーティション分割サービスを実装すると、統合およびクリーンアップサービスの負荷が軽減され、必要に応じてパーティション分割されたデータの少なくとも一部を再生成できます (共有ストレージに保持されるデータの量に応じて)。ただし、この方法では追加のリソースが消費されます。また、インストルメンテーションデータを各アプリケーションインスタンスから受信し、このデータを実用的な情報に変換するまでに遅延が発生する可能性があります。

クエリに関する考慮事項

データを利用する際の緊急度を検討します。アラートを発信するデータにはすばやくアクセスできる必要があるため、高速なデータストレージに格納し、アラートシステムによって実行されるクエリを最適化するためにインデックスを作成して構造化する必要があります。場合によっては、アラートシステムのローカルインスタンスが迅速に通知を送信できるように、コレクションサービスでデータをフォーマットしてローカルに保存する必要がある場合があります。同じデータを別の目的にも使う場合は、前のダイアグラムに示されているストレージ書き込みサービスにディスパッチして 1 か所に格納できます。

データの保有期間に関する考慮事項

場合によっては、データの処理と転送後に、ローカルに格納された元の生ソースデータを削除できます。しかし、生の情報を保存することが必要であったり、便利であったりする場合もあります。たとえば、デバッグ用に生成されたデータを生の形式で使用できるようにしておき、バグが解決されたらすぐに破棄することができます。

多くの場合、パフォーマンスデータの寿命が長いため、パフォーマンスの傾向を見つけて容量計画に使用できます。このデータの統合ビューは通常、一定の期間はすぐにアクセスできるようにオンラインで保持されます。その後は、アーカイブまたは破棄することができます。

長期間の傾向を特定するために、履歴データを格納しておくと便利です。古いデータ全体を保存するのではなく、データをダウンサンプリングして解像度を下げ、ストレージコストを節約できる場合があります。たとえば、分単位の業績評価指標を保存するのではなく、1 か月以上前のデータを統合して、時間単位のビューを形成できます。

測定および顧客への課金のために収集されるデータは、無期限に保存する必要がある場合があります。さらに、規制要件では、監査とセキュリティのために収集された情報をアーカイブして保存する必要がある場合があります。また、このデータは機密性が高いため、改ざんを防ぐために暗号化またはその他の方法で保護する必要があります。 ID 詐欺の実行に使用される可能性のあるユーザーパスワードやその他の情報は記録しないでください。保存する前に、これらの詳細をデータからスクラブする必要があります。

法律や規制を確実に遵守するには、特定可能な情報の保存を最小限に抑えます。特定可能な情報を格納する必要がある場合は、ソリューションを設計するときに、個人が情報の削除を要求できるようにする要件を考慮してください。

分析

さまざまなデータソースからデータを収集した後、それを分析して、システムの全体的な幸福を評価します。この分析では、次の内容を明確に理解してください。

定義した KPI とパフォーマンスメトリックに基づいてデータを構造化する方法。
さまざまなメトリックとログファイルでキャプチャされたデータを関連付ける方法。この相関関係は、一連のイベントを追跡する場合に重要であり、問題の診断に役立ちます。

ほとんどの場合、アーキテクチャの各コンポーネントのデータはローカルにキャプチャされ、他のコンポーネントによって生成されるデータと正確に組み合わされます。

たとえば、3 層アプリケーションには次が含まれます。

ユーザーが Web サイトに接続できるようにするプレゼンテーション層。
ビジネスロジックを処理するマイクロサービスのセットをホストする中間層。
操作に関連付けられているデータを格納するデータベース層。

1 つのビジネス操作の使用状況データは、3 つのレベルすべてにまたがることがあります。この処理で使われるリソースやプロセスの全体像を把握するには、この情報を関連付ける必要があります。この関連付けには、データベース層のデータの前処理とフィルター処理が含まれる場合があります。中間層では、集計と書式設定は一般的なタスクです。

Recommendations

アプリケーションレベルのログとリソースレベルのログを関連付けます。 両方のレベルでデータを評価して、問題の検出とそれらの問題のトラブルシューティングを最適化します。 1 つのデータシンク内のデータを集計したり、両方のレベルでイベントを照会するメソッドを利用したりできます。アプリケーションレベルのログとリソースレベルのログを集計してクエリを実行するには、Azure Log Analytics などの統合ソリューションをお勧めします。
コールド分析のためにストレージの保持時間を明確に定義します。 特定の期間にわたって履歴分析を有効にするには、この方法をお勧めします。また、ストレージコストを制御するのにも役立ちます。データをより安価なストレージにアーカイブし、長期的な傾向分析のためにデータを集計するプロセスを実装します。
長期的な傾向を分析して、運用上の問題を予測します。 長期的なデータを評価して運用戦略を形成し、どのような運用上の問題が発生し、いつ発生する可能性があるかを予測します。たとえば、平均応答時間は時間の経過と同時に徐々に増加し、最大目標に近づいていることに注意してください。

これらの推奨事項の詳細なガイダンスについては、「クラウドアプリケーションの監視データを分析する」を参照してください。

グラフ

ダッシュボード

データを視覚化する最も一般的な方法は、一連のグラフやグラフ、またはその他の視覚的な形式で情報を表示できるダッシュボードを使用することです。これらの項目はパラメーター化でき、アナリストは特定の状況に合わせて、期間などの重要なパラメーターを選択できます。

ワークロードのワークロードまたはコンポーネントが正常、低下、または異常である場合を示すように、ダッシュボードを正常性モデルに合わせます。

ダッシュボードシステムを効果的に機能させるには、ワークロードチームにとって意味がある必要があります。ワークロードの正常性に関連し、アクション可能な情報を視覚化します。ワークロードまたはコンポーネントが低下または異常な場合、ワークロードチームのメンバーは、問題が発生したワークロード内の場所を簡単に特定し、是正措置または調査を開始できる必要があります。逆に、操作できない情報やワークロードの正常性に関連しない情報を含めると、ダッシュボードが不必要に複雑になり、実用的なデータからバックグラウンドノイズを識別しようとしているチームメンバーに対してフラストレーションを感じる可能性があります。

利害関係者または開発者向けのダッシュボードがあり、関連するワークロードに関するデータのみを表示するようにカスタマイズされている場合があります。他のチームがダッシュボードの表示とプレビューに関心を持っているデータポイントの種類をワークロードチームが理解していることを確認してから、ダッシュボードをチェックに共有してわかりやすくします。利害関係者にワークロードに関するダッシュボードを提供することは、ワークロードの正常性を把握し続ける良い方法ですが、利害関係者が表示されるデータを明確に理解していない場合は、逆効果になるリスクがあります。

適切なダッシュボードでは、情報が表示されるだけではありません。また、アナリストは、その情報に関する即席の質問を行うこともできます。一部のシステムにはオペレーターがこれらのタスクを完了し、基になるデータを調査できる管理ツールが用意されています。代わりに、情報を保持するために使用されるリポジトリによっては、データに対して直接クエリを実行したり、Excel などのツールにインポートしてさらに分析やレポートを行ったりできる場合があります。

注意

承認された担当者にダッシュボードアクセスを制限します。ダッシュボードの情報は、商業的に機密性が高い場合があります。また、基になるデータを保護して、ユーザーがデータを変更できないようにする必要もあります。

レポーティング

レポートはシステムの全体像を把握するために使用されます。履歴データと現在の情報が組み込まれています。レポートの要件は 2 つの大きなカテゴリに分類されます。運用レポートとセキュリティレポートです。

運用レポートには、通常、次のものが含まれます。

指定した期間における、システム全体または指定したサブシステムのリソース使用率を把握するための統計情報を集計します。
指定した期間における、システム全体または指定したサブシステムのリソース使用率の傾向を識別します。
指定した期間における、システム全体または指定したサブシステムで発生した例外を監視します。
デプロイされたリソースに対するアプリケーションの効率を判断し、リソースの量とそれに関連するコストを、不必要にパフォーマンスに影響を与えることなく削減できるかどうかを理解します。

セキュリティレポートは、システムの顧客の使用を追跡します。次のような情報が含まれます。

ユーザー操作の監査。このタスクでは、各ユーザーが完了した個々の要求を日付と時刻と共に記録する必要があります。データは、管理者が指定した期間中にユーザーが完了する一連の操作をすばやく再構築できるように構造化する必要があります。
ユーザーによるリソース使用率の追跡。このタスクでは、ユーザーからの各要求がシステムを構成するさまざまなリソースにアクセスする方法と、その期間を記録する必要があります。管理者は、このデータを使用して、指定された期間 (請求対象の場合もある) の使用率レポートをユーザー別に生成できます。

多くの場合、レポートは定義されたスケジュールに従ってバッチ処理によって生成されます通常、待機時間は問題になりません。必要に応じて、自発的にレポートを生成できるバッチプロセスも必要です。たとえば、Azure SQL Database などのリレーショナルデータベースにデータを格納する場合は、SQL Server Reporting Servicesなどのツールを使用して、データを抽出して書式設定し、一連のレポートとして表示できます。

アラート

システムが正常で応答性が高く、セキュリティで保護された状態を維持するために、オペレーターがタイムリーに応答できるようにアラートを設定します。アラートには、診断アクティビティをすばやく開始するのに役立つ十分なコンテキスト情報を含めることができます。アラートは、自動スケーリングやその他の自己復旧メカニズムなどの修復関数を呼び出すために使用できます。アラートでは、予算と制限を可視化することで、コスト認識を可能にすることもできます。

Recommendations

説明責任がある所有者とアクションを識別するアラート応答のプロセスを定義します。
十分に定義されたスコープ (リソースの種類とリソースグループ) のアラートを構成し、詳細度を調整してノイズを最小限に抑えます。
ユーザーが積極的に問題を探すように要求するのではなく、Splunk や Azure Monitor などの自動アラートソリューションを使用します。
アラートを使用して修復プロセスを運用化します。たとえば、問題と解決策を追跡するチケットを自動的に作成します。
リージョン内のクラウドプラットフォームサービスの正常性、停止に関する通信、計画メンテナンスアクティビティ、その他の正常性アドバイザリを追跡します。

しきい値

アラートは、監視システムによって検出されたしきい値を超えると生成されます。通常、設定したしきい値によって、ワークロードに必要な変更を実装して、低下や停止を回避するのに十分な時間が与えられます。たとえば、自動スケーリングのしきい値を設定してスケーリングを開始すると、実行中のシステムのいずれかがユーザーエクスペリエンスが低下した時点まで圧倒されます。インフラストラクチャの管理における過去の経験に基づいてしきい値を割り当て、テストプラクティスの一部として実行するテストを通じて検証します。

アラートのユースケースとその他の考慮事項に関する詳細なガイダンスについては、「信頼性の高い監視とアラート戦略の設計」を参照してください。

Azure ファシリテーション

Azure Monitor は、クラウドとオンプレミス環境から監視データを収集、分析、対応するための包括的な監視ソリューションです。
Log Analytics は、Log Analytics ワークスペース内のデータに対するログクエリを編集および実行するために使用できる、Azure portalのツールです。

複数のワークスペースを使用している場合は、ベストプラクティスについては、Log Analytics ワークスペースアーキテクチャガイドを参照してください。
Application Insights は、Azure Monitor の拡張機能です。 APM 機能が提供されます。
Azure Monitor Insights は、特定の Azure テクノロジ (VM、アプリサービス、コンテナーなど) 用の高度な分析ツールです。これらのツールは、Azure Monitor と Log Analytics の一部です。
Azure Monitor for SAP ソリューションは、Azure 上で実行される SAP ランドスケープ用の Azure 監視ツールです。
Azure Policy は、組織の標準を適用してコンプライアンスを大規模に評価するのに役立ちます。

コミュニティリンク

Azure Monitor ベースラインアラート (AMBA) は、お客様とパートナーが Azure Monitor の導入を通じて監視エクスペリエンスを向上させるために使用できるアラート定義の中央リポジトリです。

オペレーショナルエクセレンスチェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナルエクセレンスチェックリスト

監視システムの設計と作成に関する推奨事項