Azure Monitor ログのベスト プラクティス
この記事では、Azure Monitor ログのアーキテクチャに関するベスト プラクティスについて説明します。 このガイダンスは、Azure Well-Architected Framework で説明されているアーキテクチャ エクセレンスの 5 つの柱に基づいています。
[信頼性]
信頼性とは、障害から回復して動作を続行する、システムの能力を指します。 目標は、単一のコンポーネントの障害による影響を最小限に抑えることです。 次の情報を使用して、Log Analytics ワークスペースの障害を最小限に抑え、収集したデータを保護します。
このビデオでは、Log Analytics ワークスペースで使用できる信頼性と回復性のオプションの概要について説明します。
Log Analytics ワークスペースは、高い信頼性を提供します。 ワークスペースへのアクセスが一時的に失われる可能性がある条件は、多くの場合、Azure Monitor エージェントを使用したデータ バッファリングや、インジェスト パイプラインに組み込まれている保護メカニズムなどの機能によって軽減されます。
このセクションで説明する回復性機能は、データ損失とビジネス継続性からの追加の保護を提供できます。 リージョン内ソリューションもあれば、リージョン間の冗長性を提供するものもあります。自動的に適用されるものと、手動トリガーを必要とするものがあります。 次の表は、これらの機能をまとめて比較したものです。
一部の可用性機能には専用クラスターが必要です。現在、このクラスターにリンクされているすべてのワークスペースから 1 日あたり少なくとも 100 GB のコミットメントが必要です (集計)。
設計チェック リスト
- 専用クラスターに対して十分なデータを収集する場合は、可用性ゾーンに専用クラスターを作成します。
- リージョンの障害時にワークスペースを使用できるようにする必要がある場合、または専用クラスターに対して十分なデータを収集しない場合は、重要なデータを異なるリージョンの複数のワークスペースに送信するようにデータ収集を構成します。
- データセンターまたはリージョンで障害が発生した際にデータを保護する必要がある場合は、ワークスペースからのデータ エクスポートを構成して、データを別の場所に保存します。
- 高可用性が必要なミッション クリティカルなワークロードについては、フェデレーション ワークスペース モデルの実装を検討してください。
- Log Analytics ワークスペースの正常性を監視します。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| 十分なデータを収集する場合は、可用性ゾーンをサポートするリージョンに専用クラスターを作成します。 | 可用性ゾーンをサポートするリージョンにある専用クラスターにリンクされたワークスペースは、データセンターに障害が発生した場合でもそのまま使用できます。 専用クラスターでは、同じリージョン内のすべてのワークスペースから 1 日あたり少なくとも 100 GB のコミットメントが必要です。 これほど多くのデータを収集しない場合は、このコミットメントにかかるコストと、ここで提供される信頼性機能を比較検討する必要があります。 |
| リージョンで障害が発生した場合にワークスペース内のデータを使用できるようにする必要がある場合は、重要なデータを異なるリージョンの複数のワークスペースに送信します。 | 異なるリージョン内の複数のワークスペースにデータを送信します。 たとえば、仮想マシンで実行されている Azure Monitor エージェントから複数のワークスペースにデータを送信するように DCR を構成し、Azure リソースから複数のワークスペースにリソース ログを収集するように複数の診断設定を構成します。 障害が発生した場合は、代替ワークスペースでデータを使用できますが、アラートやブックなどのデータに依存するリソースでは、代替ワークスペースを使用する必要はありません。 重要なリソースの ARM テンプレートは、Azure DevOps の代替ワークスペースの構成と一緒に保存するか、フェールオーバー シナリオですぐに有効にできる無効なポリシーとして保存することを検討してください。 トレードオフ: この構成により、インジェストと保持の料金が重複するため、重要なデータにのみ使用してください。 |
| 高可用性が必要なミッション クリティカルなワークロードの場合は、複数のワークスペースを使用してリージョンの障害時に高可用性が提供されるフェデレーション ワークスペース モデルの実装を検討してください。 | ミッション クリティカルでは、Azure 上で信頼性の高いアプリケーションをアーキテクトするための、規定のベスト プラクティス ガイダンスが提供されます。 設計手法には、複数の Log Analytics ワークスペースを持つフェデレーション ワークスペース モデルが含まれ、Azure リージョンの障害などの複数の障害が発生した場合に高可用性を実現します。 この戦略では、リージョン間のエグレス コストを排除し、リージョンで障害が発生しても運用を維持できますが、「Azure でのミッション クリティカルなワークロードの正常性モデリングと監視」で説明した構成とプロセスで管理する必要がある追加の複雑さが必要になります。 |
| データセンターまたはリージョンで障害が発生した際にデータを保護する必要がある場合は、ワークスペースからのデータ エクスポートを構成して、データを別の場所に保存します。 | Azure Monitor のデータ エクスポート機能を使用すると、特定のテーブルに送信されたデータを Azure ストレージに継続的にエクスポートして、長期間保持することができます。 このデータを他のリージョンにレプリケートするには、GRS や GZRS を含む Azure Storage 冗長オプション を使用します。 データエクスポートでサポートされていないテーブルのエクスポートが必要な場合は、ロジック アプリを含む他のデータエクスポート方法を使用してデータを保護できます。 これは主に、データの分析とワークスペースへの復元が困難な場合があるため、データ保持のコンプライアンスを満たすためのソリューションです。 このオプションは、データを異なるワークスペースにマルチキャストする前のオプションと似ていますが、余分なデータがストレージに書き込まれるため、コストが低くなります。 データ エクスポートは、リージョン内の Azure Monitor インジェスト パイプラインの安定性に依存するため、リージョン インシデントの影響を受けやすくなります。 リージョンインジェスト パイプラインに影響を与えるインシデントに対する回復性は提供されません。 |
| Log Analytics ワークスペースの正常性を監視します。 | Log Analytics Workspace Insights を使用して障害が発生したクエリを追跡し、正常性状態アラートを作成してデータセンターまたはリージョンの障害が原因でワークスペースが利用できなくなった場合に事前に通知されます。 |
回復性の特徴と機能を比較する
| 機能 | サービスの回復性 | [データ バックアップ] | 高可用性 | 保護の範囲 | セットアップ | コスト |
|---|---|---|---|---|---|---|
| 可用性ゾーン | ✅ サポートされているリージョンで |
✅ | ✅ | リージョン内 | サポートされているリージョンの専用クラスターで自動的に有効になります。 | 無料 |
| 継続的データ エクスポート | ✅ | 地域障害 1 からの保護 | テーブルごとに有効にします。 | データ エクスポート + ストレージ BLOB または Event Hubs のコスト | ||
| デュアル インジェスト | ✅ | ✅ | ✅ | 地域障害からの保護 | 監視対象のリソースごとに有効にします。 | リテンション期間の最大 2 倍のコスト (デュアル インジェストのデータ量に応じて) + エグレス料金。 |
1 データエクスポートは、ログを別のリージョンにエクスポートする場合にリージョン間の保護を提供します。 インシデントが発生した場合、以前にエクスポートされたデータがバックアップされ、すぐに使用できるようになります。ただし、インシデントの性質によっては、追加のエクスポートが失敗する可能性があります。
セキュリティ
セキュリティは、あらゆるアーキテクチャの最も重要な側面の 1 つです。 Azure Monitor は、最小限の特権の原則と多層防御の両方を採用する機能を提供します。 次の情報を使用して、Log Analytics ワークスペースのセキュリティを最大限に高め、許可されているユーザーのみが収集されたデータにアクセスできるようにします。
設計チェック リスト
- オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。
- 組織内のさまざまなロールに必要な、ワークスペース内のさまざまな種類のデータへのアクセスを構成します。
- Azure プライベート リンクを使用して、パブリック ネットワークからワークスペースへのアクセスを削除することを検討してください。
- ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。
- 長期保有または不変性のために監査データをエクスポートします。
- ログ クエリの監査を構成して、クエリを実行しているユーザーを追跡します。
- ワークスペース内の機密データをフィルター処理または難読化する戦略を決定します。
- 誤って収集された機密データを消去します。
- Microsoft Azure のカスタマー ロックボックスを有効にし、Microsoft データ アクセス要求を承認または拒否します。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。 | このデータを結合するかどうかの決定は、特定のセキュリティ要件によって異なります。 それらを 1 つのワークスペースに結合すると、すべてのデータの可視性が向上しますが、セキュリティ チームには専用のワークスペースが必要になる場合があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース戦略を設計する」を参照してください。 トレードオフ: ワークスペースで Sentinel を有効にするためにコストがかかる可能性があります。 「Log Analytics ワークスペース アーキテクチャを設計する」で詳細をご覧ください。 |
| 組織内のさまざまなロールに必要な、ワークスペース内のさまざまな種類のデータへのアクセスを構成します。 | ワークスペースの [アクセス制御モード] を [リソースまたはワークスペースのアクセス許可を使用] に設定すると、リソース所有者はワークスペースへの明示的なアクセスを許可されなくても、[リソース コンテキスト] を使用してデータにアクセスすることができます。 これにより、ワークスペースの構成が簡素化され、ユーザーがアクセスしてはならないデータにアクセスできないようにすることができます。 適切な組み込みロールを割り当てて、管理者の責任範囲に応じて、サブスクリプション、リソース グループ、またはワークスペース レベルで管理者にワークスペースのアクセス許可を付与します。 複数のリソースにまたがる一連のテーブルにアクセスする必要があるユーザーには、テーブル レベルの RBAC を活用します。 テーブルのアクセス許可を持つユーザーは、リソースのアクセス許可に関係なく、テーブル内のすべてのデータにアクセスできます。 ワークスペース内のデータへのアクセスを許可するためのさまざまなオプションの詳細については、「Log Analytics ワークスペースへのアクセスを管理する」を参照してください。 |
| Azure プライベート リンクを使用して、パブリック ネットワークからワークスペースへのアクセスを削除することを検討してください。 | パブリック エンドポイントへの接続は、エンドツーエンドの暗号化で保護されます。 プライベート エンドポイントが必要な場合は、Azure プライベート リンクを使用して、承認されたプライベート ネットワーク経由でのみ、リソースが Log Analytics ワークスペースに接続できるようにします。 プライベート リンクを使用して、ExpressRoute または VPN 経由でワークスペース データを強制的に取り込むこともできます。 環境に最適なネットワークと DNS トポロジを決定するには、「Azure Private Link の設定を設計する」を参照してください。 |
| ワークスペース内のデータと保存されたクエリを保護するために独自の暗号化キーが必要な場合は、カスタマー マネージド キーを使用します。 | Azure Monitor により、Microsoft マネージド キー (MMK) を使用して、すべてのデータおよび保存されたクエリが保存時に暗号化されるようになります。 独自の暗号化キーを必要とし、専用クラスターに十分なデータを収集する場合は、カスタマー マネージド キーを使用して、柔軟性とキーのライフサイクル制御を強化します。 Microsoft Sentinel を使用している場合は、「Microsoft Sentinel のカスタマー マネージド キーの設定」の考慮事項をよく理解しておいてください。 |
| 長期保有または不変性のために監査データをエクスポートします。 | 長期保有を義務付ける規制の対象となるワークスペースで監査データを収集した可能性があります。 Log Analytics ワークスペース内のデータは変更できませんが、消去することはできます。 データ エクスポートを使用して、データの改ざんから保護するための不変性ポリシーを持つ Azure ストレージ アカウントにデータを送信します。 すべての種類のログがコンプライアンス、監査、またはセキュリティと同じ関連性を持っているわけではないため、エクスポートする必要がある特定のデータ型を決定します。 |
| ログ クエリの監査を構成して、クエリを実行しているユーザーを追跡します。 | ログ クエリの監査では、ワークスペースで実行される各クエリの詳細が記録されます。 この監査データをセキュリティ データとして扱い、LAQueryLogs テーブルを適切にセキュリティで保護します。 各ワークスペースの監査ログがローカル ワークスペースに送信されるように構成するか、オペレーショナル データとセキュリティ データを分離している場合は専用のセキュリティ ワークスペースに統合します。 Log Analytics ワークスペースの分析情報を使用して、このデータを定期的に確認し、認可されていないユーザーがクエリを実行しようとしている場合に事前に通知するログ検索の警告ルールを作成することを検討します。 |
| ワークスペース内の機密データをフィルター処理または難読化する戦略を決定します。 | 機密情報を含むデータを収集している可能性があります。 特定のデータ ソースの構成を使用して、収集すべきでないレコードをフィルター処理します。 データ内の特定の列のみを削除または難読化する必要がある場合は、変換を使用します。 元のデータを変更しないことを要求する標準がある場合、KQL クエリで 'h' リテラルを使用して、ブックに表示されるクエリ結果を難読化できます。 |
| 誤って収集された機密データを消去します。 | ワークスペースで誤って収集された可能性のあるプライベート データを定期的に確認し、データ消去を使用して削除します。 |
| Microsoft Azure のカスタマー ロックボックスを有効にし、Microsoft データ アクセス要求を承認または拒否します。 | Microsoft Azure 用カスタマー ロックボックスには、顧客データへのアクセス要求を確認し、承認または拒否するインターフェイスが用意されています。 顧客が開始したサポート チケットまたは Microsoft によって特定された問題に応答する場合、Microsoft のエンジニアが顧客データにアクセスする必要がある場合に使用されます。 カスタマー ロックボックスを有効にするには、 専用クラスターが必要です。 |
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法のことです。 さまざまな構成オプションと、収集するデータの量を減らす機会を理解することで、Azure Monitor のコストを大幅に削減できます。 「Azure Monitor のコストと使用量」を参照して、Azure Monitor が請求するさまざまな方法と、毎月の請求書を表示する方法を理解しておいてください。
注意
Azure Monitor のすべての機能にわたるコスト最適化の推奨事項については、「Azure Monitor でコストを最適化する」を参照してください。
設計チェック リスト
- オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。
- 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。
- データ保持とアーカイブを構成します。
- デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。
- ワークスペースのデータ ソースからのデータ収集を制限します。
- 収集されたデータを定期的に分析して、傾向や異常を特定します。
- 収集したデータの量が多い場合のアラートを作成します。
- 特定の予算を超えないようにするための予防措置として、日次上限を検討します。
- Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。 | Sentinel が有効になっている場合、Log Analytics ワークスペース内のすべてのデータは Microsoft Sentinel の価格の対象となるため、このデータを組み合わせるとコストがかかる可能性があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース戦略を設計する」を参照してください。 |
| 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。 | 既定では、Log Analytics ワークスペースには最低データ量なしの従量課金制の価格が使用されています。 十分なデータを収集する場合は、コミットメントレベルを使用してコストを大幅に削減できます。これにより、より低い料金と引き換えに収集された 1 日の最小データに専念できます。 1 つのリージョン内のワークスペース間で十分なデータを収集する場合は、専用クラスターにリンクし、クラスターの価格を使用して収集されたボリュームを組み合わせることができます。 コミットメント レベルの詳細と、お客様の使用レベルに最も適したものを決定するためのガイダンスについては、「Azure Monitor ログのコストの計算とオプション」を参照してください。 異なる価格レベルでの使用量に応じた推定コストを表示するには、「使用量と推定コスト」を参照してください。 |
| 対話型のデータ保持期間と長期的なデータ保持期間を構成します。 | 既定の 31 日 (ワークスペースで Sentinel が有効になっている場合は 90 日、Application Insights データの場合は 90 日) を超えて Log Analytics ワークスペースにデータを保持すると、料金がかかります。 ログ クエリでデータをすぐに使用できるようにするための特定の要件を検討してください。 長期保有を構成することで、最長 12 年間データを保持しながら、検索ジョブを使用したり、データ セットをワークスペースに復元したりして時折アクセスすることができ、コストを大幅に削減することができます。 |
| デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。 | 基本ログ用に構成された Log Analytics ワークスペース内のテーブルは、制限された機能とログ クエリの料金と引き換えにインジェスト コストが低くなります。 これらのテーブルに対してクエリを実行する頻度が低い場合、このクエリ コストはインジェスト コストの削減によって相殺することができます。 |
| ワークスペースのデータ ソースからのデータ収集を制限します。 | Azure Monitor のコストの主な要因は、Log Analytics ワークスペースで収集するデータ量であるため、サービスやアプリケーションの正常性とパフォーマンスを評価するために必要なデータ量を超過しないように収集する必要があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。 トレードオフ: コストと監視の要件の間にトレードオフがある場合があります。 たとえば、高サンプル レートの方がパフォーマンスの問題を素早く検出できる可能性がありますが、コスト削減のために低サンプル レートが必要になる場合もあります。 ほとんどの環境では、収集の種類が異なる複数のデータ ソースがあるため、特定の要件とそれぞれのコスト目標のバランスを取る必要があります。 異なるデータ ソースの収集の構成に関する推奨事項については、「Azure Monitor でのコストの最適化」を参照してください。 |
| 収集されたデータを定期的に分析して、傾向や異常を特定します。 | Log Analytics ワークスペースの分析情報を使用して、ワークスペースで収集されたデータの量を定期的に確認します。 さまざまなソースから収集されたデータの量を理解するのに役立つだけでなく、余分なコストにつながる可能性のあるデータ収集の異常や上昇傾向を特定します。 加えて、「Log Analytics ワークスペースでの使用量を分析する」の方法を使用してデータ収集を分析し、使用量をさらに減らすことができる追加の構成があるかどうかを判断します。 これは、一連の新しい仮想マシンや新しいサービスをオンボードするなど、新しく一連のデータ ソースを追加する場合に特に重要です。 |
| 収集したデータの量が多い場合のアラートを作成します。 | 予期しない請求を避けるため、過剰な使用量が発生した場合は、事前に通知される必要があります。 通知により、請求期間が終了する前に、潜在的な異変に対処できます。 |
| 特定の予算を超えないようにするための予防措置として、日次上限を検討します。 | 日次上限を使用すると、構成した上限に達すると、その日の残りの時間、Log Analytics ワークスペース内のデータ収集が無効になります。 これは、日次上限を使用するタイミングに関する記事で説明されているとおり、コストを削減する方法として使用しないでください。 1 日の上限を設定する場合は、上限到達時にアラートを作成するだけでなく、特定の割合 (たとえば 90%) に達したときに通知するアラート ルールも作成してください。 これにより、上限がデータ収集を停止する前に、増加したデータの原因を調査して対処する機会が得まれます。 |
| Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。 | Log Analytics ワークスペースに関する Azure Advisor の推奨事項では、コストを最適化する機会があるときにアラートで事前に通知されます。 これらのコストに関する推奨事項に対する Azure Advisor アラートを作成します。
|
オペレーショナルエクセレンス
オペレーショナル エクセレンスとは、運用環境でサービスを確実に実行するために必要な運用プロセスを指します。 Log Analytics ワークスペースをサポートするための運用要件を最小限に抑えるには、次の情報を使用します。
設計チェック リスト
- ビジネス要件を満たすために、最小限の数のワークスペースでワークスペース アーキテクチャを設計します。
- 複数のワークスペースを管理する場合は、Infrastructure as Code (IaC) を使用します。
- Log Analytics ワークスペースの分析情報を使用して、Log Analytics ワークスペースの正常性とパフォーマンスを追跡します。
- ワークスペース内の運用上の問題を事前に通知するアラート ルールを作成します。
- データの分離のための運用プロセスが明確に定義されていることを確認してください。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ビジネス要件を満たすワークスペース戦略を設計します。 | Log Analytics ワークスペースの作成数や配置場所などの戦略の設計に関するガイダンスについては、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。 1 つまたは少なくとも最小限の数のワークスペースを使用すると、運用データとセキュリティ データの分散が制限され、潜在的な問題の可視性を高め、パターンを特定しやすくし、メンテナンスの必要性を最小限に抑えることができるため、運用効率が最大化されます。 複数のテナントなど、複数のワークスペースが必要な場合や、可用性の要件をサポートするために複数のリージョンにワークスペースが必要な場合があります。 このような場合、増大するこの複雑さを管理するための適切なプロセスがあることを確認してください。 |
| 複数のワークスペースを管理する場合は、Infrastructure as Code (IaC) を使用します。 | Infrastructure as Code (IaC) を使用して、ARM、BICEP、または Terraform でワークスペースの詳細を定義します。 これにより、既存の DevOps プロセスを活用して新しいワークスペースをデプロイし、Azure Policy で構成を適用できます。 |
| Log Analytics ワークスペースの分析情報を使用して、Log Analytics ワークスペースの正常性とパフォーマンスを追跡します。 | Log Analytics Workspace Insights は、すべてのワークスペースの使用状況、パフォーマンス、正常性、エージェント、クエリ、および変更ログの統合ビューを提供します。 この情報を定期的に確認して、各ワークスペースの正常性と操作を追跡します。 |
| ワークスペース内の運用上の問題を事前に通知するアラート ルールを作成します。 | 各ワークスペースには、ワークスペースに影響を与える重要なアクティビティを記録する操作テーブルがあります。 このテーブルに基づいてアラート ルールを作成し、運用上の問題が発生したときに事前に通知されるようにします。 ワークスペースの推奨アラートを使用して、最も重要なアラート ルールの作成を簡素化できます。 |
| データの分離のための運用プロセスが明確に定義されていることを確認してください。 | ワークスペースの格納データの種類によって、要件が異なる場合があります。 ワークスペース戦略を設計し、アクセス許可や長期保有などの設定を構成する場合は、データ保持やセキュリティなどの要件を明確に理解していることを確認してください。 また、誤って収集した個人情報を含むデータを場合によって消去するプロセスを明確に定義しておくことも必要です。 |
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 次の情報を使用して、Log Analytics ワークスペースとログ クエリがパフォーマンスを最大限に高めるために構成されていることを確認します。
設計チェック リスト
- ログ クエリの監査を構成し、Log Analytics ワークスペースの分析情報を使用して、低速で非効率的なクエリを特定します。
構成に関する推奨事項
| 推奨 | 特長 |
|---|---|
| ログ クエリの監査を構成し、Log Analytics ワークスペースの分析情報を使用して、低速で非効率的なクエリを特定します。 | ログ クエリの監査 には、各クエリの実行に必要なコンピューティング時間と、結果が返されるまでの時間が格納されます。 Log Analytics ワークスペースの分析情報では、このデータを使用して、ワークスペース内の非効率的な可能性のあるクエリを一覧表示します。 これらのクエリを書き直して、パフォーマンスを向上することを検討してください。 ログ クエリの最適化に関するガイダンスについては、「Azure Monitor でログ クエリを最適化する」を参照してください。 |