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

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

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

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

定義

主要な設計戦略

ワークロードに合わせた包括的な監視システム設計を実装するには、次の基本原則に従います。

• 可能な限り、プラットフォームが提供する監視ツールを利用してください。通常、この場合は構成がほとんど必要ありません。また、他の方法では困難な場合でも、ワークロードについての詳細な分析情報が得られます。

• ワークロード スタック全体からログとメトリックを収集します。 すべてのインフラストラクチャ リソースとアプリケーション機能は、標準化された意味のあるデータを生成するように構成し、そのデータを収集する必要があります。

• 標準化され、信頼性とセキュリティを備えたストレージ ソリューションに、収集したデータを保存します。

• 分析および視覚化ソリューションで扱うことができるように、保存されたデータを処理します。

• 処理されたデータを分析して、ワークロードの状態を正確に判断します。

• ワークロード チームやその他の関係者にとって意味のあるワークロードの状態をダッシュボードまたはレポートで視覚化します。

• 問題が発生したときにワークロード チームに通知するために、インテリジェントに定義されたしきい値に対する実用的なアラートやその他の自動応答を構成します。

• 全体的なワークロード テストのプラクティスに監視とアラートのシステムを組み込みます。

• 監視とアラートのシステムは、必ず継続的な改善の範囲に含めます。 運用環境でのアプリケーションとインフラストラクチャの動作は、継続的な学習機会として機能します。 このような教訓を監視とアラートの設計に組み込みます。

• 収集して分析した監視データをシステムとユーザーのフローに結び付け、ワークロードの全体的な正常性に加えて、フローの正常性とデータを関連付けます。 フローの観点からそのデータを分析すると、監視戦略を正常性モデルに合わせて調整するのに役立ちます。

監視システムのすべての機能を可能な限り自動化するようにします。また、それらすべてを毎日、終日、継続的に実行するようにします。

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

インストルメンテーション データを収集する

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

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

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

アプリケーション データ

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

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

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

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

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

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

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

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

収集戦略

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

トレードオフ: リージョンと中央のデータ ストアがあると、コストがかかることに注意してください。

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

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

• プル モデル: アプリケーションの各インスタンスについてさまざまなログなどのソースからデータを積極的に取得します。

• プッシュ モデル: アプリケーションの各インスタンスを構成するコンポーネントからデータが送信されるのを受動的に待機します。

監視エージェント

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

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

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

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

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

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

統合戦略

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

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

クエリと分析用のデータを保存する

ストレージ ソリューションを選択するときは、データ型、使用方法、必要な緊急度を考慮してください。

ストレージ テクノロジ

ポリグロットな永続化アプローチを検討します。つまり、さまざまな種類の情報を、それぞれの使用法に最適なテクノロジを使用して保存します。

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

• パフォーマンス カウンター データはアドホック分析ができるように、SQL データベースに格納します。

• トレース ログは、Azure Monitor Logs または Azure Data Explorer に保存することをお勧めします。

• セキュリティ情報は HDFS ソリューションに保存することもできます。

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

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

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

統合サービス

データを共有ストレージから定期的に取得する他のサービスを実装し、目的に合わせてパーティション分割またはフィルター処理して、適切なセットのデータ ストアに書き込むことができます。

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

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

クエリに関する考慮事項

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

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

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

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

長期間の傾向を特定するために、履歴データを格納しておくと便利です。 古いデータをすべて保存するのではなく、データをダウンサンプリングしてデータの密度を下げ、ストレージのコストを節約できる場合があります。 たとえば、パフォーマンス インジケーターを分単位で保存するのではなく、ひと月以上前のデータは統合して時間単位で表示することもできます。

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

法律や規制を確実に順守するために、個人を特定できる情報の保存は最小限に抑えてください。 個人を特定できる情報を保存する必要がある場合は、ソリューションを設計するときに、個人が自分の情報の削除を要求できる要件を必ず考慮に入れます。

データを分析してワークロードの正常性を理解する

さまざまなデータ ソースからデータを収集したら、それを分析してシステムの全体的な健全性を評価します。 この分析にあたって、次のことを明確に理解しておく必要があります。

• 定義した KPI とパフォーマンス メトリックに基づいてデータを構造化する方法。

• さまざまなメトリックとログ ファイルでキャプチャされたデータを関連付ける方法。 この相関関係は、一連のイベントを追跡する場合に重要であり、問題の診断に役立ちます。

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

たとえば、3 層アプリケーションには以下が含まれる場合があります。

• ユーザーが Web サイトに接続できるようにするプレゼンテーション層。

• ビジネス ロジックを処理する一連のマイクロサービスをホストする中間層。

• 操作に関連付けられたデータを保存するデータベース層。

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

推奨事項

• アプリケーションレベルとリソースレベルのログを関連付けます。 両方のレベルでデータを評価して、問題の検出とそれらの問題のトラブルシューティングを最適化します。 データを 1 つのデータ シンクに集計することや、両方のレベルにまたがるイベントのクエリを実行するメソッドを利用することができます。 アプリケーションレベルとリソースレベルでログを集計し、クエリを実行する場合は、Azure Log Analytics などの統合ソリューションを使用することをお勧めします。

• コールド分析用にストレージに明確な保持時間を定義します。 特定の期間にわたる履歴分析を可能にするには、この方法をお勧めします。 また、ストレージ コストの管理にも役立ちます。 安価なストレージにデータを確実にアーカイブするプロセスを実装し、長期的な傾向分析ができるようにデータを集計します。

• 長期的な傾向を分析して運用上の問題を予測します。 長期的なデータを評価して運用戦略を策定し、どのような運用上の問題がいつ発生するかを予測します。 たとえば、平均応答時間が時間の経過と共に徐々に増加し、最大目標に近づいていることに気付く場合があります。

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

ワークロードの正常性レポートを視覚化する

ダッシュボード

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

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

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

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

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

レポート

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

通常、運用レポートには以下が含まれます。

• 指定した期間における、システム全体または指定したサブシステムのリソース使用率を把握するための統計情報を集計します。

• 指定した期間における、システム全体または指定したサブシステムのリソース使用率の傾向を識別します。

• 指定した期間における、システム全体または指定したサブシステムで発生した例外を監視します。

• デプロイされたリソースに対するアプリケーションの効率性を判断し、不必要にパフォーマンスに影響を与えずに、リソースの量および関連するコストを縮小できるかどうかを判断します。

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

• ユーザー操作の監査。 このタスクには、各ユーザーが完了した個々の要求とその日時を記録する必要があります。 データは、指定した期間にユーザーが完了した一連の操作を管理者がすぐに再構築できるように構築されている必要があります。

• ユーザーによるリソース使用率の追跡。 このタスクには、ユーザーの各要求が、システムを構成する各種リソースにどのように、どの程度の時間アクセスしたかを記録する必要があります。 管理者はこのデータを使用して、課金などのために、指定した期間におけるユーザーごとの使用状況のレポートを生成できます。

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

重要なイベントに対してアラートを定義する

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

推奨事項

• 説明責任がある所有者とアクションを識別するアラート応答のプロセスを定義します。

• 十分に定義されたスコープ (リソースの種類とリソース グループ) のアラートを構成し、詳細度を調整してノイズを最小限に抑えます。

• Splunk や Azure Monitor などの自動アラート ソリューションを使用し、ユーザーが積極的に問題を探す必要がないようにします。

• アラートを使用して修復プロセスを運用化します。 たとえば、問題と解決策を追跡するチケットを自動的に作成します。

• リージョン内のクラウド プラットフォーム サービスの正常性、停止に関する通信、計画メンテナンス アクティビティ、その他の正常性の勧告を追跡します。

しきい値

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

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

Azure ファシリテーション

• Azure Monitor は、クラウド環境とオンプレミス環境からの監視データを収集し、分析し、それに対応するための包括的な監視ソリューションです。

• Log Analytics は、Azure portal のツールであり、Log Analytics ワークスペース内のデータに対するログ クエリの編集と実行に使用できます。

  複数のワークスペースを使用している場合のベスト プラクティスについては、Log Analytics ワークスペースのアーキテクチャ ガイドを参照してください。

• Application Insights は、Azure Monitor の拡張機能です。 これには APM 機能があります。

• Azure Monitor Insights は、特定の Azure テクノロジ (VM、アプリ サービス、コンテナーなど) のための高度な分析ツールです。 これらのツールは、Azure Monitor と Log Analytics の一部です。

• Azure Monitor for SAP Solutions は、Azure で実行している SAP ランドスケープ向けの Azure の監視ツールです。

• Azure Policy は、組織の標準を適用してコンプライアンスを大規模に評価するのに役立ちます。

関連リンク

• インストルメンテーション ガイド
• 信頼性の高い監視およびアラート戦略を設計するための推奨事項
• 監視と脅威検出に関する推奨事項
• パフォーマンス データを収集するための推奨事項

コミュニティ リンク

• Azure Monitor Baseline Alerts (AMBA) はアラート定義の中央のリポジトリです。お客様とパートナーはこれを使い、Azure Monitor の導入を通じて監視エクスペリエンスを向上させることができます。

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

レコメンデーションの完全なセットを参照してください。