Log Analytics に関する Azure Well-Architected Framework のパースペクティブ
Well-Architected Framework ワークロードの機能とパフォーマンスは、さまざまな方法で、さまざまな理由で監視する必要があります。 Azure Monitor Log Analytics ワークスペースは、監視データの大部分のプライマリ ログとメトリック シンクです。 ワークスペースでは、アドホック クエリ、視覚化、アラートなど、Azure Monitor の複数の機能がサポートされています。 一般的な監視の原則については、「監視と診断ガイダンス」を参照してください。 このガイダンスでは、一般的な監視原則を示します。 さまざまな種類のデータを識別します。 これは、Azure Monitor でサポートされている必要な分析を識別し、分析を可能にするワークスペースに格納されているデータも識別します。
この記事では、システム設計の原則を理解していることを前提としています。 また、運用ワークロード データを設定する Azure Monitor の Log Analytics ワークスペースと機能に関する実用的な知識も必要です。 詳細については、「Log Analytics ワークスペースの概要」を参照してください。
重要
このガイドを使用する方法
各セクションには、 アーキテクチャ の関心領域と、テクノロジスコープにローカライズされた設計戦略を示す設計チェックリストがあります。
また、これらの戦略を具体化するのに役立つテクノロジ機能またはデプロイ トポロジに関する 推奨事項 も含まれています。 推奨事項は、Log Analytics ワークスペースとその関連する Azure Monitor リソースで使用できるすべての構成の完全な一覧を表しているわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項を一覧表示します。 推奨事項を使用して、概念実証の構築、ワークロード監視環境の設計、既存のワークロード監視ソリューションの最適化を行います。
テクノロジスコープ
このガイドでは、次の Azure リソースに関する相互に関連する決定に焦点を当てます。
- Log Analytics ワークスペース
- ワークロードの運用ログ データ
- ワークロード内の Azure リソースの診断設定
[信頼性]
信頼性の柱の目的は、 十分な回復性と障害から迅速に回復する機能を構築することで、継続的な機能を提供することです。
信頼性設計の原則は、個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
Log Analytics ワークスペースで考慮すべき信頼性の状況は次のとおりです。
- ワークスペースの可用性。
- Azure データセンターまたはリージョンの障害が発生したまれなケースで収集されたデータの保護。
現在、異なるリージョン内のワークスペース間のフェールオーバーに関する標準機能はありませんが、可用性またはコンプライアンスに関する特定の要件がある場合は、使用する方法があります。
信頼性の設計チェックリスト
信頼性の設計レビュー チェックリストに基づいて設計戦略を開始し、仮想マシン (VM) の SKU と機能とその依存関係を念頭に置きながら、ビジネス要件との関連性を判断します。 戦略を拡張して、必要に応じてより多くのアプローチを含めます。
- Log Analytics ワークスペースのサービス制限を確認します。 [サービスの制限] セクションは、データの収集と保持に関する制限、およびサービスのその他の側面を理解するのに役立ちます。 これらの制限は、ワークロード監視戦略を適切に設計する方法を決定するのに役立ちます。 クエリなど、Azure Monitor サービスの制限 については、その中で説明されている機能の多くが Log Analytics ワークスペースと連携しているため、必ず確認してください。
- ワークスペースの回復性と回復を計画します。 Log Analytics ワークスペースはリージョンであり、リージョン間の冗長性やレプリケーションに対する組み込みのサポートはありません。 また、可用性ゾーンの冗長性オプションは制限されています。 そのため、ワークスペースの信頼性要件を決定し、それらの目標を満たすように戦略を立てておく必要があります。 要件では、ワークスペースがデータセンターの障害やリージョンの障害に対して回復性を持つ必要があることを規定している場合や、フェールオーバー リージョンの新しいワークスペースにデータを回復できる必要があることを規定している場合があります。 これらの各シナリオでは、成功するために追加のリソースとプロセスを配置する必要があるため、信頼性目標とコストと複雑さのバランスを慎重に検討する必要があります。
- 信頼性の要件を満たす適切なデプロイ リージョンを選択します。 運用データを出力するワークロード コンポーネントと併置された Log Analytics ワークスペースとデータ収集エンドポイント (DCEs) をデプロイします。 ワークスペースと DCEs をデプロイする適切なリージョンの選択は、 ワークロードをデプロイする場所によって通知する必要があります。 専用クラスターなどの特定の Log Analytics 機能のリージョン別の可用性を、ワークロードの信頼性、コスト、パフォーマンスの要件の中心となる他の要因と比較することが必要になる場合があります。
- 監視システムが正常であることを確認します。 ワークロードの他のコンポーネントと同様に、監視システムとログ システムが正しく機能していることを確認します。 これを実現するには、運用チームに正常性データ信号を送信する機能を有効にします。 Log Analytics ワークスペースおよび関連リソースに固有の正常性データシグナルを設定します。
信頼性の構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ワークロードのクリティカル パスに Log Analytics ワークスペースを含めないでください。 ワークスペースは機能する監視システムにとって重要ですが、ワークロードの機能はそれらに依存しないでください。 | ワークスペースと関連する関数をワークロードのクリティカル パスから除外すると、監視システムがワークロードのランタイム実行に影響を与える問題のリスクを最小限に抑えることができます。 |
| ワークスペース データの高い持続性をサポートするには、データの回復性をサポートする リージョン に Log Analytics ワークスペースをデプロイします。 データの回復性は、ワークスペースを同じリージョン内の 専用クラスター にリンクする場合にのみ可能です。 | 専用クラスターを使用すると、関連するワークスペースを可用性ゾーンに分散させることができます。これにより、データセンターの停止に対する保護が提供されます。 専用クラスターを正当化するのに十分なデータを今すぐ収集しない場合、この先入観的なリージョン選択によって、将来の成長がサポートされます。 |
| ワークロードへの近接性に基づいてワークスペースのデプロイを選択します。 Log Analytics ワークスペースと同じリージョンでデータ収集エンドポイント (DCE) を使用します。 |
ワークロードのインスタンスと同じリージョンにワークスペースをデプロイします。 ワークスペースと DCEs をワークロードと同じリージョンに置くことで、他のリージョンでの停止による影響のリスクが軽減されます。 DCEs は、ワークロードの運用データを Log Analytics ワークスペースに送信するために、Azure Monitor エージェントとログ インジェスト API によって使用されます。 デプロイにワークスペースが 1 つだけある場合でも、複数の DCEs が必要になる場合があります。 特定の環境の DCEs を構成する方法の詳細については、「 デプロイに基づいてデータ収集エンドポイントを設定する方法」を参照してください。<Br ワークロードがアクティブ/アクティブな設計でデプロイされている場合は、ワークロードがデプロイされているリージョン全体に分散した複数のワークスペースと DCEs を使用することを検討してください。 複数のリージョンにワークスペースをデプロイすると、環境が複雑になります。 Log Analytics ワークスペース アーキテクチャの設計に関するページで詳しく説明されている条件と、可用性の要件のバランスを取ります。 |
| リージョンの障害で ワークスペースを使用できるようにする必要がある 場合、または専用クラスターに対して十分なデータを収集しない場合は、異なるリージョンの複数のワークスペースに重要なデータを送信するようにデータ収集を構成します。 この方法は、ログ マルチキャストとも呼ばれます。 たとえば、VM で実行されている Azure Monitor エージェント用に複数のワークスペースの DCR を構成します。 Azure リソースからリソース ログを収集し、複数のワークスペースにログを送信するように、複数の診断設定を構成します。 |
|
| このようにして、リージョンの障害が発生した場合は、代替ワークスペースでワークロード運用データを使用できます。 ただし、アラートやブックなどのデータに依存するリソースは、他のリージョンに自動的にはレプリケートされません。 代替ワークスペースの構成を使用して重要なアラート リソース用の Azure Resource Manager (ARM) テンプレートを格納するか、すべてのリージョンにデプロイしますが、冗長なアラートを防ぐために無効にすることを検討してください。 どちらのオプションでも、リージョン障害の迅速な有効化がサポートされます。 トレードオフ: この構成では、インジェストとリテンション期間の料金が重複するため、重要なデータにのみ使用します。 |
|
| データセンターまたはリージョンの障害で データを保護する必要がある場合は 、別の場所にデータを保存するようにワークスペースからのデータ エクスポート を構成します。 このオプションは、データを異なるワークスペースにマルチキャストする前のオプションと似ています。 ただし、追加のデータがストレージに書き込まれるため、このオプションのコストは低くなります。 このデータをさらに他のリージョンにレプリケートするには、geo 冗長ストレージ (GRS) や geo ゾーン冗長ストレージ (GZRS) などの Azure Storage 冗長オプションを使用します。 データ エクスポートでは、リージョン インジェスト パイプラインに影響を与えるインシデントに対する回復性は提供されません。 |
履歴の運用ログ データはエクスポートされた状態では簡単にクエリを実行できない場合があります。これにより、データが長期にわたるリージョンの停止から存続し、アクセスして長期間保持できるようになります。 データエクスポートでサポートされていないテーブルのエクスポートが必要な場合は、Logic Apps を含む他のデータエクスポート方法を使用してデータを保護できます。 この戦略を実行可能な復旧計画として機能させるには、Azure 内のリソースと、データを提供するすべてのエージェントに対して診断設定を再構成するプロセスが必要です。 また、エクスポートしたデータを新しいワークスペースに手動でリハイドレートする計画も必要です。 前述のオプションと同様に、アラートやブックなどのデータに依存するリソースのプロセスを定義する必要もあります。 |
| 高可用性を必要とするミッション クリティカルなワークロードの場合は、複数のワークスペースを使用してリージョンの障害が発生した場合に高可用性を提供するフェデレーション ワークスペース モデルの実装を検討してください。 |
ミッション クリティカルでは 、Azure で信頼性の高いアプリケーションを設計するための規範的なベスト プラクティス ガイダンスが提供されます。 設計手法には、複数の Log Analytics ワークスペースを備えたフェデレーション ワークスペース モデルが含まれています。Azure リージョンの障害など、複数の障害が発生した場合に 高可用性 を実現します。 この戦略により、リージョン間のエグレス コストが不要になり、リージョンの障害が発生しても引き続き運用できます。 ただし、「 Azure でのミッション クリティカルなワークロードの正常性モデリングと監視」で説明されている構成とプロセスを使用して管理する必要がある複雑さが必要です。 |
| コードとしてのインフラストラクチャ (IaC) を使用して、ワークスペースと関連する関数をデプロイおよび管理します。 | デプロイと回復性と回復のメカニズムを実用的なだけ自動化すると、これらの操作が確実に信頼性が確保されます。 運用プロセスの重要な時間を節約し、人的エラーのリスクを最小限に抑えます。 保存されたログ クエリなどの関数も IaC を通じて定義されていることを確認し、回復が必要な場合は新しいリージョンに復旧します。 |
| DCR ルールをシンプルに保つために、1 つの責任原則を使用して DCR を設計します。 ソース システムのすべての入力、ルール、宛先を含む 1 つの DCR を読み込むことができますが、少数のデータ ソースに依存する狭い焦点を絞ったルールを設計することをお勧めします。 ルール割り当ての構成を使用して、論理ターゲットの目的の監視スコープに到達します。 また、DCR の変換を最小限に抑える |
狭い焦点を絞った DCR を使用すると、ルールの構成ミスがより広範な影響を与えるリスクが最小限に抑えられます。 これにより、DCR がビルドされたスコープのみに効果が制限されます。 詳細については、「 Azure Monitor でのデータ収集ルールの作成と管理のベスト プラクティス」を参照してください。 変換は強力で、状況によっては必要ですが、キーワード (keyword) クエリ言語 (KQL) の作業をテストしてトラブルシューティングするのは困難な場合があります。 可能な場合は、データを生で取り込み、クエリ時にダウンストリームで変換を処理することで、データ損失のリスクを最小限に抑えます。 |
| 日単位の上限またはアイテム保持ポリシーを設定する場合は、必要なログを取り込んで保持することで、信頼性の要件を維持していることを確認してください。 | 日単位の上限は、指定した量に達するとワークスペースのデータの収集を停止します。これにより、インジェスト ボリュームの制御を維持するのに役立ちます。 ただし、この機能は慎重に計画した後にのみ使用してください。 日単位の上限が規則性に達していないことを確認します。 その場合、上限は制限が厳しすぎます。 ワークロードからの重要なシグナルを見逃さないように、日単位の上限を再構成する必要があります。 同様に、重要なデータを誤って失わないよう、データ保持ポリシーの下げに慎重かつ慎重に取り組んでください。 |
| Log Analytics ワークスペースの分析情報を使用して、取り込み量、取り込まれたデータとデータの上限、応答しないログ ソース、その他のデータ間の失敗したクエリを追跡します。 データセンターまたはリージョンの障害が原因でワークスペースが利用できなくなった場合に事前に通知する 正常性状態アラート を作成します。 | この戦略により、ワークスペースの正常性を正常に監視し、正常性が低下するリスクがある場合は積極的に行動できるようになります。 ワークロードの他のコンポーネントと同様に、正常性メトリックを認識し、傾向を特定して、時間の経過と同時に信頼性を向上させることができることが重要です。 |
Azure Policy
Azure では、Log Analytics ワークスペースの信頼性に関連するポリシーは提供されません。 ワークスペースが専用クラスターに関連付けられているようにするなど、ワークスペースデプロイの周りにコンプライアンス ガードレールを構築する カスタム ポリシー を作成できます。
Log Analytics ワークスペースの信頼性とは直接関係はありませんが、使用できるほぼすべてのサービスに対する Azure ポリシーがあります。 ポリシーでは、そのサービスに対して診断設定が有効になっていることを確認し、サービスのログ データが Log Analytics ワークスペースに流れ込んでいるかどうかを検証します。 ワークロード アーキテクチャ内のすべてのサービスは、独自の信頼性のニーズに合わせてログ データを Log Analytics ワークスペースに送信する必要があり、ポリシーが適用するのに役立ちます。 同様に、VM や Kubernetes などのエージェント ベースのプラットフォームにエージェントがインストールされるようにするためのポリシーが存在します。
Azure Advisor
Azure では、Log Analytics ワークスペースの信頼性に関連する Azure Advisor の推奨事項は提供されません。
セキュリティ
セキュリティの柱の目的は 、ワークロードに機密性、整合性、可用性 の保証を提供することです。
セキュリティ設計原則は、監視およびログ ソリューションに関する技術設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
セキュリティの設計チェックリスト
セキュリティの設計レビュー チェックリストに基づいて設計戦略を開始し、セキュリティ体制を改善するための脆弱性とコントロールを特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
- Azure Monitor のセキュリティ ベースライン と Log Analytics ワークスペースへのアクセスの管理に関するトピックを 確認します。 これらのトピックでは、セキュリティのベスト プラクティスに関するガイダンスを提供します。
- セグメント化を基礎原則としてワークスペースをデプロイします。 ネットワーク、データ、アクセス レベルでセグメント化を実装します。 セグメント化により、ワークスペースが適切な程度に分離され、可能な限り高いレベルへの不正アクセスからより適切に保護され、信頼性、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率に関するビジネス要件を満たすことができます。
- ワークスペースでアクティビティと関連 ID の読み取りと書き込みを監査できることを確認します。 攻撃者は、操作ログを表示することでメリットを得ることができます。 ID が侵害されると、ログインジェクション攻撃が発生する可能性があります。 Azure Portal から、または API 操作と関連ユーザーを介して実行される操作の監査を有効にします。 ワークスペースを監査するように設定されていない場合は、organizationがコンプライアンス要件に違反するリスクにさらされている可能性があります。
- 堅牢なネットワーク制御を実装します。 ネットワークの分離とファイアウォール機能を使用して、ワークスペースとログへのネットワーク アクセスをセキュリティで保護します。 ネットワーク制御が不十分に構成されていると、承認されていないアクターや悪意のあるアクターによってアクセスされるリスクが生じることがあります。
- 不変性または長期保有が必要なデータの種類を決定します。 ログ データは、運用システム内のワークロード データと同じ厳しさで扱う必要があります。 コンプライアンス要件に従って機密ログ データを正常に格納できるように、データ分類プラクティスにログ データを含めます。
- 暗号化を使用して保存中のログ データを保護します。 セグメント化だけでは、ログ データの機密性を完全に保護することはできません。 未承認の未加工アクセスが発生した場合、ログ データを保存時に暗号化すると、不適切なアクターがワークスペースの外部でそのデータを使用するのを防ぐことができます。
- 難読化を使用して機密ログ データを保護します。 運用システムに存在するワークロード データと同様に、運用ログに意図的または意図せずに存在する可能性のある機密情報に対して機密性が保持されるように、追加の対策を講じなければなりません。 難読化方法を使用すると、機密ログ データを承認されていない目から非表示にするのに役立ちます。
セキュリティの構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。 Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 独自の暗号化キーが必要で、 専用クラスターに対して十分なデータを収集する場合は、 カスタマー マネージド キーを使用します。 Azure Key Vaultで独自のキーを使用してデータを暗号化し、キーのライフサイクルを制御し、データへのアクセスを取り消すことができます。 Microsoft Sentinel を使用する場合は、「 Microsoft Sentinel のカスタマー マネージド キーを設定する」の考慮事項をよく理解していることを確認してください。 |
この戦略では、Azure Key Vault で独自のキーを使用してデータを暗号化し、キーのライフサイクルを制御し、データへのアクセスを取り消すことができます。 |
|
ログ クエリ監査を構成して、クエリを実行しているユーザーを追跡します。 運用データとセキュリティ データを分離する場合は、各ワークスペースの監査ログをローカル ワークスペースに送信するか、専用のセキュリティ ワークスペースに統合するように構成します。 Log Analytics ワークスペースの分析情報を使用して、このデータを定期的に確認します。 承認されていないユーザーがクエリを実行しようとしている場合は、ログ クエリ アラート ルールを作成して事前に通知することを検討してください。 |
ログ クエリ監査では、ワークスペースで実行される各クエリの詳細が記録されます。 この監査データをセキュリティ データとして扱い、LAQueryLogs テーブルを適切にセキュリティで保護します。 この戦略により、承認されていないアクセスが発生した場合にすぐに確実にキャッチされるようにすることで、セキュリティ体制が強化されます。 |
| プライベート ネットワークとセグメント化メジャーを使用してワークスペースをセキュリティで保護します。 プライベート リンク機能を使用して、ログ ソースとワークスペース間の通信をプライベート ネットワークに制限します。 |
プライベート リンクを使用すると、特定のワークスペースにアクセスできる仮想ネットワークを制御し、セグメント化によってセキュリティをさらに強化することもできます。 |
| 使用可能な場合は、ワークスペース API アクセスに API キーの代わりに Microsoft Entra ID を使用します。 | クエリ API への API キーベースのアクセスでは、クライアントごとの監査証跡は残りません。 プログラムによるアクセスを適切に監査できるように、十分なスコープの Entra ID ベース のアクセスを使用します。 |
| 組織内のさまざまなロールに必要な、ワークスペース内のさまざまな種類のデータへのアクセスを構成します。 ワークスペースの アクセス制御モード を [ リソースまたはワークスペースのアクセス許可を使用する] に設定します。 このアクセス制御により、リソース所有者は リソース コンテキスト を使用して、ワークスペースへの明示的なアクセスを許可されることなく、データにアクセスできます。 複数のリソースにまたがる一連のテーブルへのアクセスを必要とするユーザーには、テーブル レベルの RBAC を 使用します。 |
この設定により、ワークスペースの構成が簡略化され、ユーザーがアクセスすべきでない運用データにアクセスできないようにすることができます。 適切な組み込みロールを割り当てて、管理者の責任範囲に応じて、サブスクリプション、リソース グループ、またはワークスペース レベルで管理者にワークスペースのアクセス許可を付与します。 テーブルのアクセス許可を持つユーザーは、リソースのアクセス許可に関係なく、テーブル内のすべてのデータにアクセスできます。 ワークスペース内のデータへのアクセスを許可するためのさまざまなオプションの詳細については、「Log Analytics ワークスペースへのアクセスを管理する」を参照してください。 |
| 長期保有または不変性を必要とするログをエクスポートします。 データ エクスポートを使用して、不変ポリシーを使用して Azure Storage アカウントにデータを送信し、データの改ざんから保護します。 すべての種類のログがコンプライアンス、監査、またはセキュリティに同じ関連性を持つわけではないため、エクスポートする必要がある特定のデータ型を決定します。 |
長期保有を必要とする規制の対象となる監査データをワークスペースで収集できます。 Log Analytics ワークスペース内のデータは変更できませんが、 消去することはできます。 保持目的で運用データのコピーをエクスポートすると、コンプライアンス要件を満たすソリューションを構築できます。 |
| ワークスペース内の機密データをフィルター処理または難読化する戦略を決定します。 機密情報を含むデータを収集している可能性があります。 特定のデータ ソースの構成を使用して収集すべきでないレコードをフィルター処理します。 データ内の特定の列のみを削除または難読化する必要がある場合は、変換を使用します。 元のデータを変更しない必要がある標準がある場合は、KQL クエリで "h" リテラル を使用して、ブックに表示されるクエリ結果を難読化できます。 |
ワークスペース内の機密データを難読化またはフィルター処理すると、機密情報の機密性を維持するのに役立ちます。 多くの場合、コンプライアンス要件によって機密情報を処理する方法が決まります。 この戦略は、要件を事前に遵守するのに役立ちます。 |
Azure Policy
Azure には、Log Analytics ワークスペースのセキュリティに関連するポリシーが用意されており、目的のセキュリティ体制を適用するのに役立ちます。 このようなポリシーの例を次に示します。
- Azure Monitor ログ クラスターは、カスタマー マネージド キーを使用して暗号化する必要がある
- Azure Monitor 内の保存されたクエリはログ暗号化のためにカスタマー ストレージ アカウントに保存する必要があります
- Log Analytics ワークスペースでは、Azure Active Directory 以外のインジェストをブロックする必要がある
また、Log Analytics ワークスペースでは、パブリック ネットワークからのログ インジェストとクエリをブロックしたり、プライベート DNS ゾーンを使用するように Azure Monitor Private Link スコープを構成するなどの DINE ポリシーを使用してソリューションを構成したりする必要があるなど、プライベート リンク構成を適用するのに役立つ多数のポリシーも用意されています。
Azure Advisor
Azure では、Log Analytics ワークスペースのセキュリティに関連する Azure Advisor の推奨事項は提供されません。
コストの最適化
コストの最適化では、支出パターンの検出、重要な領域への投資の優先順位付け、ビジネス要件を満たしながらorganizationの予算を満たすように他のユーザーの最適化に重点を置いています。
コスト最適化設計原則は、これらのビジネス目標を達成するための高レベルの設計戦略を提供します。 また、監視およびログ ソリューションに関連する技術的な設計で、必要に応じてトレードオフを行うのに役立ちます。
Log Analytics ワークスペースのデータ料金の計算方法の詳細については、「 Azure Monitor ログのコストの計算とオプション」を参照してください。
コスト最適化の設計チェックリスト
投資のための コスト最適化の設計レビュー チェックリスト に基づいて設計戦略を開始し、ワークロードがワークロードに割り当てられた予算と一致するように設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
- コスト モデリングの演習を実行します。 これらは、現在のワークスペースのコストを理解し、ワークスペースの増加に対するコストを予測するのに役立ちます。 ワークロードの成長傾向を分析し、ワークロードの拡張計画を確実に理解して、将来の運用ログのコストを適切に予測します。
- 適切な課金モデルを選択します。 コスト モデルを使用して、シナリオに最適な 課金モデル を決定します。 現在のワークスペースの使用方法と、ワークロードの進化に合わせてワークスペースを使用する方法によって、従量課金制モデルとコミットメントレベル モデルのどちらをシナリオに最適にするかが決まります。
ワークスペースごとに異なる課金モデルを選択できることと、特定のケースでワークスペースのコストを組み合わせることができるので、分析と意思決定をきめ細かく行うことができます。 - 適切な量のログ データを収集します。 不要なログ データを収集しないように、リソース、データ収集ルールの構成、カスタム アプリケーション コード ログに対して診断設定の定期的なスケジュールされた分析を実行します。
- 非運用環境を運用環境とは異なる方法で処理します。 非運用環境を確認して、診断設定と保持ポリシーが適切に構成されていることを確認します。 これらは、多くの場合、特に開発/テスト環境やサンドボックス環境の場合、運用環境よりもかなり堅牢性が低い場合があります。
コスト最適化の構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| 各 Log Analytics ワークスペースで通常収集されるデータの量の価格レベルを構成します。 | 既定では、Log Analytics ワークスペースでは従量課金制の価格が使用され、最小データ 量は使用されません。 十分なデータを収集する場合は、 コミットメント レベルを使用してコストを大幅に削減できます。これにより、より低いレートと引き換えに収集された 1 日の最小データにコミットできます。 1 つのリージョン内のワークスペース間で十分なデータを収集する場合は、 専用クラスター にリンクし、クラスター の価格を使用して収集されたボリュームを組み合わせることができます。 コミットメント レベルの詳細と、使用レベルに最も適した内容の決定に関するガイダンスについては、「 Azure Monitor ログのコストの計算とオプション」を参照してください。 さまざまな価格レベルでの使用量の推定コストを表示するには、「 使用量と推定コスト」を参照してください。 |
| データ保持とアーカイブを構成します。 | Log Analytics ワークスペースにデータを保持する場合は、既定値の 31 日を超える料金が発生します。 ワークスペースで Microsoft Sentinel が有効になっている場合は 90 日、Application Insights データの場合は 90 日です。 ログ クエリでデータをすぐに使用できるようにするための特定の要件を検討してください。 アーカイブされたログを構成することで、コストを大幅に削減できます。 アーカイブされたログを使用すると、最大 7 年間データを保持し、場合によってはアクセスできます。 検索ジョブを使用するか、一連のデータをワークスペースに復元することで、データにアクセスします。 |
| Microsoft Sentinel を使用してセキュリティ ログを分析する場合は、別のワークスペースを使用してそれらのログを格納することを検討してください。 | SIEM で使用するログ データに専用のワークスペースを使用すると、コストを制御するのに役立ちます。 Microsoft Sentinel で使用されるワークスペースには、 Microsoft Sentinel の価格が適用されます。 セキュリティ要件によって、SIEM ソリューションに含める必要があるログの種類が決まります。 操作ログを除外できる場合があります。これは、別のワークスペースにある場合は、標準の Log Analytics 価格で課金されます。 |
| デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。 | 基本ログ用に構成された Log Analytics ワークスペース内のテーブルは、制限された機能とログ クエリの料金と引き換えにインジェスト コストが低くなります。 これらのテーブルに対してクエリを実行する頻度が低い場合、このクエリ コストはインジェスト コストの削減によって相殺することができます。 |
| ワークスペースのデータ ソースからのデータ収集を制限します。 | Azure Monitor のコストの主な要因は、Log Analytics ワークスペースで収集するデータの量です。 サービスとアプリケーションの正常性とパフォーマンスを評価するために必要なデータを収集しないようにしてください。 リソースごとに、構成する診断設定に適したカテゴリを選択して、必要な操作データの量を指定します。 これは、無視されたデータを管理せず、ワークロードを正常に管理するのに役立ちます。 コストと監視要件の間にトレードオフが発生する可能性があります。 たとえば、高いサンプル レートでパフォーマンスの問題をより迅速に検出できますが、コストを節約するためにサンプル レートを低くしたい場合があります。 ほとんどの環境には、コレクションの種類が異なる複数のデータ ソースがあるため、特定の要件とそれぞれのコスト目標のバランスを取る必要があります。 さまざまなデータ ソースの収集の構成に関する推奨事項については、「 Azure Monitor でのコストの最適化 」を参照してください。 |
| ワークスペースの使用状況データを定期的に分析して、傾向と異常を特定します。 Log Analytics ワークスペースの分析情報を使用して、ワークスペースで収集されたデータの量を定期的に確認します。 「 Log Analytics ワークスペースの使用状況を分析 する」の方法を使用してデータ収集をさらに分析し、使用量をさらに減らすことができる他の構成があるかどうかを判断します。 |
さまざまなソースによって収集されるデータの量を理解できるようにすることで、データ収集の異常と上昇傾向を特定し、過剰なコストが発生する可能性があります。 この考慮事項は、ワークロードに新しいデータ ソースのセットを追加する場合に重要です。 たとえば、新しい VM のセットを追加する場合は、サービスで新しい Azure 診断設定を有効にするか、アプリケーションでログ レベルを変更します。 |
| 収集したデータの量が多い場合のアラートを作成します。 | 予期しない請求を避けるため、過剰な使用量が発生した場合は、事前に通知される必要があります。 通知を使用すると、請求期間が終了する前に発生する可能性のある異常に対処できます。 |
| 特定の予算を超えないようにするための予防措置として、日次上限を検討します。 |
日次上限を使用すると、構成した上限に達すると、その日の残りの時間、Log Analytics ワークスペース内のデータ収集が無効になります。 「 日次上限を使用する場合」で説明されているように、コストを削減する方法としてこの方法を使用しないでください。代わりに、構成ミスや不正使用による暴走の取り込みを防止します。 日次上限を設定した場合 は、上限に達したときにアラートを作成します。 また、 何らかの割合に達したときにアラート ルールも作成してください。 たとえば、容量が 90% に達したときにアラート ルールを設定できます。 このアラートを使用すると、上限によってワークロードからの重要なデータ収集が遮断される前に、増加したデータの原因を調査して対処する機会が得られます。 |
Azure Policy
Azure では、Log Analytics ワークスペースのコスト最適化に関連するポリシーは提供されません。 ワークスペースに適切な保持設定が含まれていることを確認するなど、ワークスペースのデプロイに関するコンプライアンス ガードレールを構築するための カスタム ポリシー を作成できます。
Azure Advisor
Azure Advisor では、比較的高いインジェスト ボリュームを受け取るテーブルに対して、ワークスペース内の特定のテーブルを低コストの Basic Log データ プランに移動することをお勧めします。 切り替える前に基本的なログを使用して制限事項を理解します。 詳細については、「 基本的なログを使用する必要がある場合」を参照してください。 Azure Advisor では、全体的な使用量量に基づいてワークスペース全体の 価格コミットメント レベルを変更 することも推奨される場合があります。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、主に 開発プラクティス、可観測性、リリース管理の手順に焦点を当てています。
オペレーショナル エクセレンス設計原則は、ワークロードの運用要件に対してこれらの目標を達成するための高レベルの設計戦略を提供します。
オペレーショナル エクセレンスの設計チェックリスト
Log Analytics ワークスペースに関連する監視、テスト、デプロイのプロセスを定義するための オペレーショナル エクセレンスの設計レビュー チェックリスト に基づいて、設計戦略を開始します。
- ワークロードの Log Analytics ワークスペースに関連するすべての機能に対して、コードとしてのインフラストラクチャ (IaC) を使用します。 ログ収集、インジェスト、ストレージ、クエリ関数 (保存されたクエリやクエリ パックを含む) を手動で管理および操作することで発生する可能性がある人的エラーのリスクを最小限に抑えます。コードを使用して、これらの関数をできるだけ多く自動化します。 また、正常性状態の変更を報告するアラートと、IaC コードでワークスペースにログを送信するリソースの診断設定の構成を含めます。 ワークスペースの管理のために安全なデプロイ プラクティスが維持されるように、他のワークロード関連のコードと共にコードを含めます。
- ワークスペースが正常であることを確認し、問題が発生したときに通知を受け取ります。 ワークロードの他のコンポーネントと同様に、ワークスペースで問題が発生する可能性があります。 この問題は、トラブルシューティングと解決に貴重な時間とリソースを費やし、運用ワークロードの状態をチームに認識させておく可能性があります。 ワークスペースを事前に監視し、潜在的な問題を軽減できるため、運用チームは問題のトラブルシューティングと修正に費やす時間を最小限に抑えることができます。
- 運用環境を非運用環境のワークロードから分離します。 運用環境に対して非運用環境で使用されるワークスペースとは異なるワークスペースを使用することで、運用チームに余分な作業を引き起こす可能性がある不要な複雑さを回避します。 また、テスト アクティビティが運用環境のイベントと見なされる可能性があるため、今後のデータは混乱を招く可能性があります。
- Microsoft 以外のソリューションよりも組み込みのツールと関数を優先 する組み込みのツールを使用して、監視システムとログ システムの機能を拡張します。 回復可能性や、Log Analytics ワークスペースではすぐに使用できないデータ主権などの要件をサポートするために、追加の構成を用意する必要がある場合があります。 このような場合は、実用的な場合は常に、ネイティブの Azure または Microsoft ツールを使用して、organizationでサポートする必要があるツールの数を最小限に抑えます。
- ワークスペースをエフェメラル コンポーネントではなく静的コンポーネントとして扱う 他の種類のデータ ストアと同様に、ワークスペースはワークロードのエフェメラル コンポーネントの中で考慮しないでください。 Well-Architected Framework では、一般に、不変のインフラストラクチャと、デプロイの一部としてワークロード内のリソースをすばやく簡単に置き換える機能が優先されます。 ただし、ワークスペース データの損失は致命的で元に戻せない可能性があります。 このため、更新中にインフラストラクチャを置き換えるデプロイ パッケージからワークスペースを除外し、ワークスペースに対してのみインプレース アップグレードを実行します。
- 運用スタッフがKusto 照会言語必要に応じてクエリを作成または変更するためのスタッフのトレーニングに関するトレーニングを行っていることを確認します。 オペレーターがクエリを記述または変更できない場合は、オペレーターが他のチームに依存して作業を行う必要があるため、重要なトラブルシューティングやその他の機能が遅くなる可能性があります。
オペレーショナル エクセレンスの構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ビジネス要件を満たすためにワークスペース戦略を設計します。 Log Analytics ワークスペースの戦略の設計に関するガイダンスについては、「Log Analytics ワークスペース アーキテクチャの設計」を参照してください。 作成する数と配置場所を含めます。 ワークロードで一元化されたプラットフォーム チーム オファリングを使用する必要がある場合は、必要なすべての運用アクセスを設定してください。 また、ワークロードの監視ニーズが満たされるようにアラートを作成します。 |
1 つまたは少なくとも最小限の数のワークスペースによって、ワークロードの運用効率が最大化されます。 これにより、運用データとセキュリティ データの分散が制限され、潜在的な問題の可視性が向上し、パターンの識別が容易になり、メンテナンス要件が最小限に抑えられます。 複数のテナントなどの複数のワークスペースの要件がある場合や、可用性要件をサポートするために複数のリージョンのワークスペースが必要な場合があります。 そのため、この複雑さの増加を管理するための適切なプロセスが用意されていることを確認します。 |
| コードとしてのインフラストラクチャ (IaC) を使用して、ワークスペースと関連する関数をデプロイおよび管理します。 | コードとしてのインフラストラクチャ (IaC) を使用して、 ARM テンプレート、 Azure BICEP、または Terraform でワークスペースの詳細を定義します。 既存の DevOps プロセスを使用して新しいワークスペースをデプロイし、Azure Policyして構成を適用できます。 すべての IaC コードをアプリケーション コードと併置すると、すべてのデプロイに対して安全なデプロイ プラクティスが確実に維持されます。 |
| Log Analytics ワークスペースの分析情報を使用して、Log Analytics ワークスペースの正常性とパフォーマンスを追跡し、意味のある実用的なアラートを作成して、運用上の問題を事前に通知します。 Log Analytics Workspace Insights は、すべてのワークスペースの使用状況、パフォーマンス、正常性、エージェント、クエリ、および変更ログの統合ビューを提供します。 各ワークスペースには、ワークスペースに影響を与える重要なアクティビティを記録する操作テーブルがあります。 |
Log Analytics の分析情報が定期的に提供する情報を確認して、各ワークスペースの正常性と操作を追跡します。 この情報を使用すると、操作や関係者がワークスペースの正常性を追跡するために使用できるダッシュボードやレポートなどのわかりやすい視覚化を簡単に作成できます。 このテーブルに基づいてアラート ルールを作成し、運用上の問題が発生したときに事前に通知されるようにします。 ワークスペースに推奨されるアラートを使用して、最も重要なアラート ルールを簡単に作成できます。 |
| リソース、データ収集ルール、アプリケーション ログの詳細度に関する Azure 診断設定を頻繁に見直すことで、継続的な改善を実践します。 リソース設定を頻繁に確認して、ログ収集戦略を最適化していることを確認します。 運用上の観点から、リソースの正常性状態に関する有用な情報を提供するログに焦点を当てることで、ログのノイズを減らすようにします。 |
この方法で最適化することで、オペレーターは問題が発生したときに調査およびトラブルシューティングを行ったり、他のルーチン、即席、緊急タスクを実行したりできます。 リソースの種類に対して新しい診断カテゴリが使用可能になった場合は、このカテゴリで出力されるログの種類を確認して、それらを有効にすることがコレクション戦略の最適化に役立つかどうかを理解します。 たとえば、新しいカテゴリは、キャプチャされるアクティビティのより大きなセットのサブセットである可能性があります。 新しいサブセットを使用すると、操作が追跡するために重要なアクティビティに焦点を当てることで、入ってくるログの量を減らすことができます。 |
Azure Policyと Azure Advisor
Azure では、Log Analytics ワークスペースのオペレーショナル エクセレンスに関連するポリシーも Azure Advisor の推奨事項も提供されません。
パフォーマンス効率
パフォーマンス効率は、容量を管理することで 負荷が増加した場合でも、ユーザー エクスペリエンスを維持 することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計原則は、予想される使用に対してこれらの容量目標を達成するための高レベルの設計戦略を提供します。
パフォーマンス効率の設計チェックリスト
Log Analytics ワークスペースと関連する関数のベースラインを定義するための パフォーマンス効率の設計レビュー チェックリスト に基づいて、設計戦略を開始します。
- Azure Monitor でのログ データ インジェスト待機時間の基礎について理解してください。 ワークスペースにログを取り込む際の待機時間には、いくつかの要因があります。 これらの要因の多くは、Azure Monitor プラットフォームに固有です。 要因と通常の待機時間の動作を理解することは、ワークロード運用チーム内で適切な期待値を設定するのに役立ちます。
- 非運用ワークロードと運用ワークロードを分離します。 運用固有のワークスペースは、非運用システムによって発生する可能性のあるオーバーヘッドを軽減します。 これにより、ワークスペースの全体的なフットプリントが削減され、ログ データ処理を処理するために必要なリソースが少なくなります。
- パフォーマンス要件を満たす適切なデプロイ リージョンを選択します。 Log Analytics ワークスペースとデータ収集エンドポイント (DCEs) をワークロードの近くにデプロイします。 ワークスペースと DCEs をデプロイする適切なリージョンの選択は、ワークロードをデプロイする場所によって通知する必要があります。 ログ データの要件をサポートできないリージョンにワークロードを既にデプロイしている場合は、ワークロードと同じリージョンにワークスペースと DCEs をデプロイすることのパフォーマンス上の利点を、信頼性の要件と比較する必要がある場合があります。
パフォーマンス効率の構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ログ クエリの監査を構成し、Log Analytics ワークスペースの分析情報を使用して、低速で非効率的なクエリを特定します。 ログ クエリの監査 には、各クエリの実行に必要なコンピューティング時間と、結果が返されるまでの時間が格納されます。 Log Analytics ワークスペースの分析情報では、このデータを使用して、ワークスペース内の非効率的な可能性のあるクエリを一覧表示します。 これらのクエリを書き直して、パフォーマンスを向上することを検討してください。 ログ クエリの最適化に関するガイダンスについては、「Azure Monitor でログ クエリを最適化する」を参照してください。 |
最適化されたクエリは結果をより速く返し、バックエンドで使用するリソースが少なくなり、これらのクエリに依存するプロセスも効率的になります。 |
| Log Analytics ワークスペースのサービス制限について説明します。 トラフィックの多い特定の実装では、パフォーマンスとワークスペースまたはワークロードの設計に影響を与えるサービス制限が発生する可能性があります。 たとえば、クエリ API では、クエリによって返されるレコードとデータ ボリュームの数が制限されます。 Logs Ingestion API では、各 API 呼び出しのサイズが制限されます。 Azure Monitor と Log Analytics ワークスペース の制限とワークスペース自体に固有の制限の完全な一覧については、「 Azure Monitor サービスの制限」を参照してください。 |
ワークスペースのパフォーマンスに影響を与える可能性のある制限を理解することは、それらを軽減するために適切に設計するのに役立ちます。 複数のワークスペースを使用して、1 つのワークスペースに関連付けられている制限に達しないようにすることができます。 他の柱の要件とターゲットに対してサービスの制限を軽減するための設計上の決定を検討します。 |
| 1 つ以上の定義済みの監視スコープ内に、データ ソースの種類に固有の DCR を作成します。 パフォーマンスとイベント用に個別の DCR を作成して、バックエンド処理のコンピューティング使用率を最適化します。 | パフォーマンスとイベントに個別の DCR を使用すると、バックエンド リソースの枯渇を軽減するのに役立ちます。 パフォーマンス イベントを組み合わせた DCR を使用すると、関連付けられているすべての仮想マシンで、インストールされているソフトウェアに応じて適用できない可能性のある構成の転送、処理、実行が強制されます。 構成の処理中に過剰なコンピューティング リソースの消費とエラーが発生し、Azure Monitor エージェント (AMA) が応答しなくなる可能性があります。 |
Azure Policyと Azure Advisor
Azure では、Log Analytics ワークスペースのパフォーマンスに関連するポリシーも Azure Advisor の推奨事項も提供されません。