Azure Monitor ログ (Log Analytics) ワークスペースの設計
Azure Monitor では、ログ データが Azure Monitor ログ (Log Analytics) ワークスペースに格納されます。 ワークスペースは、データ ストレージの管理上の境界または地理的な場所として機能する Azure リソースです。 このワークスペースは、データの収集や集計を行うコンテナーでもあります。
1 つまたは複数のワークスペースを Azure サブスクリプションにデプロイできますが、Microsoft のガイドラインに確実に従って初期のデプロイを行うために理解しておく必要がある考慮事項がいくつかあります。 ワークスペースは、組織のニーズを満たし、コスト効率に優れ、管理可能で、スケーラブルなデプロイを提供する必要があります。
Azure Monitor ログ ワークスペースについて知っておくべきこと
以下の Azure Monitor ログ ワークスペースの特性を確認し、それらが Tailwind Traders の監視ソリューションにどのように役立つかを検討します。
ワークスペースでは、Microsoft が推奨する設計戦略に従ってさまざまなユーザーにアクセス権を付与することにより、データを分離できます。
Azure Monitor ログ ワークスペースのデータはテーブルとして編成されます。 各テーブルには、さまざまな種類のデータが格納され、データを生成しているリソースに基づいて独自の固有のプロパティ セットがあります。 ほとんどのデータ ソースは、Azure Monitor ログ ワークスペース内の独自のテーブルに書き込まれます。
ワークスペースを使用すると、管理上の境界または地理的な場所に基づいて、価格レベル、保持期間、データ キャッピングなどの設定を構成できます。
Azure ロールベースのアクセス制御 (Azure RBAC) を使用すると、ユーザーとグループには、ワークスペース内の監視データを操作するために必要な量のアクセス権のみを付与できます。 単一のワークスペースを使用して、すべてのリソースで有効な収集データを格納することにより、ユーザー アクセス制御を IT 組織の運用モデルに合わせることができます。
ワークスペースは、物理クラスターでホストされます。 既定では、これらのクラスターはシステムによって作成され、管理されます。 システムで 1 日あたり 500 GB を超えるデータが取り込まれる場合は、より詳細な制御とより高いインジェスト レートをサポートするために、ワークスペース専用の独自のクラスターを作成します。
Azure Monitor ログ ワークスペースを使用する場合の考慮事項
これで、Tailwind Traders アーキテクチャの Azure Monitor ログ ワークスペースを使用して設計するための考慮事項を確認する準備ができました。
アクセス制御戦略を検討します。 Tailwind Traders 組織で使用するワークスペースの数を計画する際には、次の潜在的な要件を考慮してください。
- 組織はグローバル企業ですか? データ主権またはコンプライアンス上の理由により、特定のリージョンに格納されたログ データが必要ですか?
- アーキテクチャで Azure を使用していますか? 管理対象の Azure リソースと同じリージョンにワークスペースを配置して、送信データの転送料金が発生するのを回避する必要がありますか?
- システムで複数の部門またはビジネス グループがサポートされていますか? 各グループは、そのグループのデータにアクセスする必要がありますが、他のグループのデータにはアクセスできません。 また、統合された部門間ビューやビジネス グループ ビューに関するビジネス要件はありません。
デプロイ モデル オプションを検討します。 ほとんどの IT 企業では、集中型、分散型、またはハイブリッドのアーキテクチャ モデルが使用されます。 次の一般的なワークスペース デプロイ モデルと、それらが Tailwind Traders 組織でどのように機能するかを検討します。
デプロイ 説明 一元化 すべてのログは中央ワークスペースに格納され、単一のチームによって管理されます。 Azure Monitor によって、チームごとに差別化されたアクセスが提供されます。 このシナリオでは、管理、リソース間の検索、ログの相互関連付けを簡単に行うことができます。 サブスクリプション内の複数のリソースから収集されるデータの量によっては、ワークスペースが大幅に増加する可能性があります。 異なるユーザーに対するアクセス制御を維持するための管理オーバーヘッドが増加します。 このモデルは、"ハブ アンド スポーク" と呼ばれます。 分散型 各チームは、所有して管理するリソース グループ内に独自のワークスペースを作成します。 ログ データはリソースごとに分離されます。 このシナリオでは、ワークスペースのセキュリティを維持でき、アクセス制御とリソース アクセスの一貫性を保つことができます。 このモジュールの欠点は、ログを相互に関連付けるのが困難な場合があることです。 多くのリソースを広範囲に表示する必要があるユーザーは、意味のある方法でデータを分析できません。 ハイブリッド ハイブリッド アプローチは、セキュリティ監査コンプライアンス要件によって複雑になる可能性があります。 多くの組織は、両方のデプロイ モデルを並行して実装します。 一般的に、ハイブリッド設計では、複雑でコストが高く、保守が困難な構成になり、ログ カバレッジにギャップが生じます。 アクセス モードについて検討します。 ユーザーが Azure Monitor ログ ワークスペースにアクセスする方法を計画し、ユーザーがアクセスできるデータのスコープを定義します。 Tailwind Traders のユーザーは、データにアクセスするために次の 2 つのオプションのいずれかを選択できます。
アクセス モード 説明 ワークスペース コンテキスト ユーザーは、アクセス許可を持っているワークスペース内のすべてのログを確認できます。 クエリのスコープは、ワークスペース内のすべてのテーブルのすべてのデータに設定されます。 Azure portal で Azure Monitor メニューから [ログ] を選択すると、ワークスペースをスコープとしてログにアクセスできます。 リソース コンテキスト ユーザーは、特定のリソース、リソース グループ、またはサブスクリプションのワークスペースにアクセスします。 ユーザーは、Azure portal でリソースのメニューから [ログ] を選択して、アクセスできるすべてのテーブル内のリソースに関するログのみを表示できます。 クエリのスコープは、そのリソースに関連付けられているデータのみとなります。 このモードでは、きめ細かい Azure RBAC も有効になります。 Azure RBAC とワークスペースについて検討します。 ワークスペースの関連付けに従って、どのユーザーがどのリソースにアクセスできるかを制御します。 Azure Virtual Machines でホストされている Tailwind Traders インフラストラクチャ サービスに対する責任を担うチームにアクセスを付与する場合、 Virtual Machines によって生成されるログへのアクセスのみを付与できます。 このアプローチは、新しいリソースコンテキストのログ モデルに従っています。 このモデルの基礎となるのは、Azure リソースによって生成されるすべてのログ レコードがこのリソースに自動的に関連付けられることです。 ログは、リソースに基づくスコープと Azure RBAC を考慮する中央ワークスペースに転送されます。
スケールとインジェスト ボリューム レートの制限について検討します。 Azure Monitor とは、毎月増加するペタバイト単位のデータを送信する何千もの顧客にサービスを提供する高スケールのデータ サービスです。 ワークスペースは記憶域スペースに制限がなく、ペタバイト単位のデータにまで拡張できます。 スケーリングのためにワークスペースを分割する必要はありません。
推奨事項
監視およびログ ソリューションで Azure Monitor ログ ワークスペースとアクセス制御を実行するためのオプションを検討する際には、以下の推奨事項を確認してください。 このシナリオは、IT 組織のサブスクリプションに単一のワークスペースがある場合の推奨される設計を示しています。
ワークスペースは、データ主権や規制コンプライアンスによって制約されません。 リソースがデプロイされているリージョンにマップする必要はありません。 組織のセキュリティおよび IT 管理者チームは、Azure アクセス管理との強化された統合と、より安全なアクセス制御を活用できます。
すべてのリソース、監視ソリューション、分析情報 (Application Insights や Virtual Machine Insights など) は、収集されたログ データを IT 組織の集中化された共有ワークスペースに転送するように構成されています。 サポートしているインフラストラクチャと、さまざまなチームによって保守されているアプリからのログ データも、集中化された共有ワークスペースに送信されます。
各チームのユーザーには、アクセス権が付与されているリソースに関するログへのアクセスが許可されます。
ワークスペース アーキテクチャをデプロイした後、Azure Policy を使用してこの同じモデルを Azure リソースに適用できます。 ポリシーを定義し、Azure リソースへのコンプライアンスを確保できるため、すべてのリソース ログが特定のワークスペースに送信されます。 たとえば、Azure Virtual Machines または Virtual Machine Scale Sets を使用すると、ワークスペースのコンプライアンスを評価して結果を報告する既存のポリシーを使用したり、準拠していない場合には修復するようにカスタマイズしたりすることができます。