【Microsoft Azure】Log Analyticsワークスペースの設計プラクティスを知る

Contents

Log Analyticsのアーキテクチャ

プラクティスを説明する前に、Log Analyticsのアーキテクチャについて理解しておく必要があります。

ちょっと適切な絵を見つけられなかったので、公式ページにあった以下の絵に言葉で補足します。

Log Analyticsでは、データは大きくLog Analyticsワークスペースと呼ばれるコンテナの単位で管理される。
Log Analyticsワークスペースとリソースは多：多の関係（１つのワークスペースに複数のリソースのログを溜めることができるし、１つのリソースのログを複数のワークスペースに転送することも可能（各リソースの診断設定を複数構成すればできる））
Log Analyticsワークスペースの中には、Syslog, Heart Beatなど、情報の種類毎に異なるテーブルが用意されている。

さて、こちらが今回の記事の主眼になります。今回、これを整理するにあたって以下の公式ドキュメントを読みました。お時間がある方はこちらもしっかり読んでおくことをお勧めします。

これを決めるための質問は、以下です。

法律などの制限で、データが格納できる地域が制限されているか？

法律などでデータを海外に持ち出してはならない、などといった場合は、国内のリージョンに展開する必要があります。

監視するリソースと同じリージョンに展開しようとしているか？

こちらは、コストの観点での質問です。Azureでは、同一リージョン内のAzureサービス間の通信は無料ですが、リージョンをまたぐ通信には課金が発生します。（リージョンをまたぐ通信には、さらに大陸内、大陸間で価格帯が変わります）

そのため、コストをなるべく抑えるためには、極力監視対象のリソースと同一リージョンにデプロイすることが賢明のようです。

２つ目の考慮事項は、Log Analyticsワークスペースの分割方法です。ワークスペース分割の考え方には以下の３つがあります。

一元化：すべてのログが中央ワークスペースに格納され、1 つのチームによって管理されます。
分散：各チームが所有して管理するリソースグループ内に独自のワークスペースが作成され、ログデータはリソースごとに分離されます。
ハイブリッド：一元化モデルと分散モデルが混合された状態。多くの組織が両方のデプロイモデルを並行して実装するため、セキュリティ監査コンプライアンス要件によってこのシナリオがさらに複雑になります。

これを決めるための質問は以下です。それぞれメリット・デメリットがありますので、状況に応じて最適解が異なります。

以下の説明を見た感じ、利用するリソース・ユーザが小〜中規模であれば一元管理、大規模であれば分散の方が良さそうです。

モデル	メリット	デメリット
一元化	・管理コストが低い・リソース間のデータ検索・関連付けが簡単	・収集されるデータ量が多くなるとワークスペースが膨大になる（検索パフォーマンスへの影響）・アクセスを管理するユーザの数が増えると管理オーバーヘッドが増大する（検索パフォーマンスへの影響？）
分散	・アクセス制御とリソースアクセスの一貫性を保つことができる・１つのワークスペースで管理するデータ量が抑えられるので検索パフォーマンスへの影響が少ない	・リソース間でログを相互に紐づけることが難しい（できないわけではない模様） https://docs.microsoft.com/ja-jp/azure/azure-monitor/log-query/cross-workspace-query
ハイブリッド	(ドキュメントを見た限りでは推奨されていない?)	・多くの場合、ログカバレッジにギャップがある、複雑でコストが高く、保守が困難な構成になる

最後にアクセス制御です。Log Analyticsでは、次の４通りの方法でアクセス制御が行えます。

詳細な説明は以下の公式ドキュメントに譲りますが、ワークスペースレベル＞リソースレベル＞テーブルレベルと各階層できめ細かにアクセス制御が可能ですので、必要に応じて設定を行います。