Log Analytics のアーキテクチャのベスト プラクティス

Log Analytics ワークスペースのサービス制限を確認します。サービスの制限に関するセクションでは、データ収集、データ保持、およびサービスのその他の側面に関する制限について説明します。 これらの制限は、効果的なワークロード監視戦略を設計するのに役立ちます。 クエリなどの多くの関数が Log Analytics ワークスペースと連携して動作するため、 Azure Monitor サービスの制限 を確認してください。

ワークスペースの回復性と回復を計画します。 Log Analytics ワークスペースはリージョンであり、リージョン間の冗長性やレプリケーションのサポートが組み込まれていない。 可用性ゾーンの冗長性オプションは制限されています。 これらの制限により、ワークスペースの信頼性要件を決定し、それらの目標を満たすように戦略を立ててください。

要件では、ワークスペースがデータセンターの障害やリージョンの障害に対する回復性を持つ必要があることを規定している場合があります。 または、フェールオーバー リージョン内の新しいワークスペースにデータを回復できる必要があることを規定している場合もあります。

これらの各シナリオでは、追加のリソースとプロセスを成功させる必要があるため、信頼性の目標とコストと複雑さのバランスを取る方法を慎重に検討してください。

信頼性の要件を満たす適切なデプロイ リージョンを選択します 。運用データを出力するワークロード コンポーネントと併置された Log Analytics ワークスペースとデータ収集エンドポイント (DCE) をデプロイします。 ワークロードをデプロイする場所は、ワークスペースと DCEs をデプロイする適切なリージョンの選択を通知する必要があります。

特定の Log Analytics 機能 (専用クラスターなど) のリージョンごとの可用性を、ワークロードの信頼性、コスト、パフォーマンスの要件の中心となるその他の要因と比較することが必要になる場合があります。

クリティカル パスの依存関係からワークスペースを除外します。 Log Analytics ワークスペースは監視システムの重要なコンポーネントとして機能しますが、 ワークロードのクリティカル パスに含めることはできません。 これらのワークスペースは、監視とトラブルシューティングに不可欠な運用データを収集して格納します。 ただし、ワークロードのコア機能は、ワークスペースの可用性に依存しない必要があります。 このアーキテクチャの分離により、監視システムの停止がワークロード ランタイムの障害に連鎖しないようにします。

監視システムが正常であることを確認します。 ワークロードの他のコンポーネントと同様に、監視システムとログ システムが正常に機能していることを確認します。 信頼性の高い可観測性を実現するには、運用チームに正常性データ信号を送信する機能を有効にします。 Log Analytics ワークスペースおよび関連リソースに固有の正常性データ シグナルを設定します。

セキュリティのベスト プラクティスを確認します。 セキュリティのベスト プラクティスについては、 Azure Monitor のセキュリティ ベースライン と Log Analytics ワークスペースへのアクセスの管理に 関する記事を参照してください。

セグメント化を基本原則としてワークスペースをデプロイします 。ネットワーク、データ、アクセス レベルでセグメント化を実装します。 セグメント化は、ワークスペースが適切な程度に分離されるようにするのに役立ちます。 また、信頼性、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率に関するビジネス要件を満たしながら、可能な限り高いレベルの不正アクセスからワークスペースを保護するのにも役立ちます。

ワークスペースの読み取りと書き込みのアクティビティと関連する ID を監査できることを確認します 。攻撃者は、操作ログを表示することでメリットを得ることができます。 ID が侵害されると、ログインジェクション攻撃につながる可能性があります。 Azure portal から、または API の操作と関連付けられているユーザーを介して実行される操作の監査を有効にします。

ワークスペースを監査するように設定されていない場合は、組織がコンプライアンス要件に違反するリスクにさらされる可能性があります。

堅牢なネットワーク制御を実装します。 ネットワークの分離とファイアウォール機能を使用して、ワークスペースとログへのネットワーク アクセスをセキュリティで保護します。 ネットワーク制御が不十分に構成されると、承認されていないアクセスや悪意のあるアクセスのリスクが高まります。

不変性または長期保有が必要なデータの種類を決定します 。ログ データは、運用システム内のワークロード データと同じ厳密で扱う必要があります。 データ分類プラクティスにログ データを含め、コンプライアンス要件に従って機密ログ データを正常に格納できるようにします。

暗号化を使用して保存中のログ データを保護する: セグメント化だけでは、ログ データの機密性は完全には保護されません。 未承認の生アクセスが発生した場合、保存中のログ データを暗号化すると、不適切なアクターがワークスペースの外部でそのデータを使用するのを防ぐことができます。

難読化によって機密ログ データを保護する: 運用システムに存在するワークロード データと同様に、運用ログに意図的または意図せずに存在する可能性のある機密情報に対して機密性が保持されるように、追加の対策を講える必要があります。 難読化方法を使用すると、機密性の高いログ データを未承認のアクセスから隠すのに役立ちます。

コスト モデリングの演習を実行します。 これらの演習は、現在のワークスペース のコストを理解し、ワークスペースの増加に対するコストを予測するのに役立ちます。 ワークロードの成長傾向を分析し、ワークロードの拡張計画を理解して、将来の運用ログコストを適切に予測できるようにします。

適切な課金モデルを選択します。 コスト モデルを使用して、シナリオに最適な 課金モデル を決定します。 ワークスペースの現在の使用方法と、ワークロードの進化に合わせてワークスペースを使用する方法によって、従量課金制またはコミットメントレベル モデルがシナリオに最適かどうかが決まります。

ワークスペースごとに異なる課金モデルを選択できることに注意してください。 特定のケースでワークスペース のコストを組み合わせることもできます。そのため、分析と意思決定を細かく行うことができます。

適切な量のログ データを収集します。 不要なログ データを収集しないように、リソース、データ収集規則の構成、カスタム アプリケーション コードのログ記録に関する診断設定の定期的なスケジュールされた分析を実行します。

非運用環境を運用環境とは異なる方法で処理します 。非運用環境を確認して、診断設定とアイテム保持ポリシーが適切に構成されていることを確認します。 これらの設定とポリシーは、多くの場合、運用環境 (特に開発/テスト環境またはサンドボックス環境の場合) よりも大幅に堅牢度が低い場合があります。

ワークロードの Log Analytics ワークスペースに関連するすべての関数に対して、コードとしてのインフラストラクチャ (IaC) を使用します 。ログ収集、インジェスト、ストレージ、および保存されたクエリやクエリ パックを含むクエリ関数を手動で管理および操作することによって発生する可能性がある人為的エラーのリスクを最小限に抑えます。これには、コードを使用してできるだけ多くの関数が自動化されます。

また、正常性状態の変化を報告するアラートと、IaC コードでワークスペースにログを送信するリソースの診断設定の構成を含めます。 ワークスペースの管理のために安全なデプロイ プラクティスが維持されるように、他のワークロード関連のコードと共にコードを含めます。

ワークスペースが正常であり、問題が発生したときに通知を受け取っていることを確認します 。ワークロードの他のコンポーネントと同様に、ワークスペースで問題が発生する可能性があります。 これらの問題は、診断と修正に貴重な時間とリソースを消費する可能性があり、運用ワークロードの状態がチームに認識されなくなることがあります。 ワークスペースの予防的な監視と早期の問題の軽減により、運用チームはトラブルシューティングと修復に費やす時間を短縮できます。

運用環境と非運用環境のワークロードを分離します 。運用環境用に異なるワークスペースを使用することで、運用チームに余分な作業を引き起こす可能性のある不要な複雑さを回避します。これは、非運用環境で使用されるワークスペースとは異なります。 また、テスト アクティビティは運用環境のイベントと見なされる可能性があるため、今後のデータは混乱を招く可能性があります。

Microsoft 以外のソリューションよりも組み込みのツールと関数を優先します。 組み込みのツールを使用して、監視およびログ システムの機能を拡張します。 Log Analytics ワークスペースではすぐに使用できない回復可能性やデータ主権などの要件をサポートするために、追加の構成を用意する必要がある場合があります。 このような場合、実用的な場合は、ネイティブの Azure または Microsoft ツールを使用して、組織でサポートする必要があるツールの数を最小限に抑えます。

一時的なコンポーネントではなく、ワークスペースを静的として扱います。 他の種類のデータ ストアと同様に、ワークスペースはワークロードの一時的なコンポーネントの中で考慮しないでください。 Well-Architected Framework では、一般に、不変のインフラストラクチャと、デプロイの一部としてワークロード内のリソースをすばやく簡単に置き換える機能が優先されます。 ただし、ワークスペース データの損失は致命的で元に戻せない可能性があります。

このため、更新中にインフラストラクチャを置き換える展開パッケージからワークスペースを除外し、ワークスペースに対してインプレース アップグレードのみを実行します。

運用スタッフが Kusto クエリ言語でトレーニングされていることを確認 します。必要に応じて、スタッフをトレーニングしてクエリを作成または変更します。 演算子がクエリを記述または変更できない場合、重要なトラブルシューティングやその他の関数が遅くなる可能性があります。これは、オペレーターが他のチームに依存して作業を行う必要があるためです。

Azure Monitor でのログ データ インジェスト待機時間の基礎について理解します。ワークスペースにログを取り込む際の待機時間には、いくつかの要因があります。 これらの要因の多くは、Azure Monitor プラットフォームに固有です。

要因と通常の待機時間の動作を理解することは、ワークロード運用チーム内で適切な期待値を設定するのに役立ちます。

非運用ワークロードと運用ワークロードを分離します 。運用固有のワークスペースは、非運用システムによって生じる可能性のあるオーバーヘッドを軽減します。 分離により、ログ データ処理を処理するために必要なリソースが少なくなり、ワークスペースの全体的なフットプリントが削減されます。

パフォーマンス要件を満たす適切なデプロイ リージョンを選択します 。Log Analytics ワークスペースと DCEs をワークロードの近くにデプロイします。 ワークロードをデプロイする場所は、ワークスペースと DCEs をデプロイする適切なリージョンの選択を通知する必要があります。

ログ データの要件をサポートできないリージョンにワークロードを既にデプロイしている場合は、ワークロードと同じリージョンにワークスペースと DCEs をデプロイすることのパフォーマンス上の利点を、信頼性の要件と比較することが必要になる場合があります。