【Azure】ログ保管におけるベストプラクティス

はじめに

以前、Azureのログの収集に関する記事を投稿しました。思いのほか、多くの方に見て頂けて嬉しかったので、続編として次はログの保管方法について記載しました。本記事は、私の知見と独断に基づいたベストプラクティスとなっております。

対象とするログ

なお、本記事で取り扱うログはクラウドインフラのパフォーマンスなどの監視で使用することを想定しているため、以下のログを対象としております。

1. EntraIDのアクティビティログ、監査ログ
2. AzureMonitorAgentで取得した仮想マシンのメトリック
3. 診断設定で取得したAzureリソースのメトリックやリソースログ
4. ApplicationInsightで取得したアプリのログ
5. アプリがローカルへ出力したテキストログファイル

含まれないもの

1. 変更フィードなどで取得したAzureBlobStorageやCosmosDB等の変更履歴
2. MDEやUpdateManagerなどで取得したデバイスの情報

上記ログの収集方式については以下記事をご確認下さい。
【Azure】ログ収集のベストプラクティス（パフォーマンス監視編）

目次

1.ログの保管先のサービス
2.分析するログの保管
3.長期保存するログの保管
4.まとめ

1.ログの保管先のサービス

まず、ログの保管先として考えられる候補は以下があります。
それぞれ、ざっくりとした用途と一緒に記載しておきます。

• AzureStorageAccount：長期的なログの保管向き、安価
• LoganalyticsWorkspace：AzurePortalで分析したいログはここへ保存、割高
• AzureEventHubs：保存というより振り分けと処理をしたい

1.1.AzureEventHubsの利用用途

AzureEventHub自体はログの保管向きではないので、ログ管理のコンポーネントとして使用することかなり稀だと思います。一応事例としては以下のような迅速な処理が伴うパターンとなります。

• 膨大なイベントログを直接保管せず先に処理(振り分け)してから保管したい時
• 受信したイベントログを振り分けして、メール送信やアプリでの処理等を並列でしたい時
• APIを使用して、アプリケーションからイベントログを直接送信してメール送信をしたい時（もはやインフラ監視は関係ない）

AzureEventHubsはPubSubの仕組みなので、受信側が取得してもイベントが削除されることはありません。AzureEventHubsはイベントの保管期間の設定が可能ですが、容量の制限が厳しいため、あくまでイベントログの処理を目的として使用しましょう。ログ保管を目的として使用はしないようにしましょう。

一定期間の保管が必要なログは、並行でStorageAccountへのログ格納も考慮に入れるようにしましょう。

もっと詳しくAzureEventHubsについて知りたい方は、少し情報が古いですが以下シリーズの記事が最も参考になります。

• Azure Eventhubs概要をまとめてみた
• Azure Eventhubs概要をまとめてみた２

2.分析するログの保管

2.1.LogAnalyticsWorkspaceでのログ管理

保管先としては、基本的にはLogAnalyticsWorkspaceへの保管が第一候補になります。以下が構成イメージです。

LogAnalyticsWorkspaceを使用する理由は以下です

• 簡単にログ検索やブック、アラートルールの作成ができる
• AzureMonitorAgent、ApplicationInsight、診断設定を使用して簡単にログを収集できる
• データエクスポート機能でAzureBlobStorageにログを転送できる

2.1.1.保管するログは構造化が必要

LogAnalyticsWorkspaceへ保管するログデータは構造化しておく必要があるので、テキストログ等はTransformationで構造化する必要があります。
「モニター>データ収集ルール>Configuration>データソース」にて設定可能です。

診断設定やApplicationInsightで収集するログはAzureが勝手に構造化して格納してくれるので気にしなくて良いです。

2.1.2.保管したログでできること

LogAnalyticsWorkspaceへ保管されたログはブックの作成やクエリで検索や集計、アラートルールの作成ができます。また、AzureMonitorと接続することでAzureMonitorの画面で一元的にブックやクエリの作成や保存が可能です。

Sentinelを構成することで、LogAnalyticsWorkspaceに保管されたログを使用してセキュリティの観点で分析をすることも可能です。

2.1.3.ログのライフサイクル

2.1.3.1.データ保管の種類

LogAnlalyticsWorkspaceでのデータ保管は以下2層が用意されています。

• AnalyticsLogs：高価、検索や集計が自由にできる
• ArchiveLogs：比較的安価、保管されたログの使用にはジョブで検索するか復元する必要がある

基本的に分析したい期間のログはAnalyticsLogsへ保管し、使わなくなったらArchiveLogsへ移動するといったライフサイクルの設定になります。（ここは、テーブルごとでの設定が可能です。）

2.1.3.2.AnalyticsLogsへ保管する期間

AnalyticsLogsへ保管する期間の設定はシステムのワークロードやログの特性に合わせて設定していく必要があります。もし初めてで何もわからないのであれば、3か月ぐらいで設定をしておいて、運用の中で見直しをしていくのはいかがでしょうか。

2.1.3.3.アーカイブログの保管先としてArchiveLogsは使用しない

基本的にArchiveLogsへの保管は不要と私は考えます。保管のためのログは基本的にAzureBlobStorageへデータエクスポートで送っておく方が望ましいです。LogAnalyticsへの保管は非常に高価なので、保管するログはあくまで今見たいログを置いておくようにしましょう。

アーカイブ保管は、LogAnalyticsWorkspaceはArchiveLogsは使用せずに、AzureBlobStorageに任せましょう。

2.1.4.LogAnalyticsWorkspaceをパブリックネットワークと分離する

「ネットワークと分離機能」を使用して指定したPrivateLinkScope経由以外からのデータインジェストやクエリを拒否することが可能です。
こちらはシステムの要件と合わせて設定をしてください。

参考までに、以下、設定画面です。

3.長期保存するログの保管

3.1.AzureBlobStorageでのログ管理

長期保管するログはAzureBlobStorageへ保管することが望ましいです。その理由は以下です。

• 保管費用が安い
• ライフサイクル設定で保管費用をさらに安くできる
• 不変ストレージを使用してログが改ざんされていないところを保証できる

3.2.不変ストレージを使用する

ログが改ざんされていないことを担保するために、不変ストレージ設定は基本的に構成をするようにしましょう。
不変ストレージについては以下記事をご参照下さい。
Qiita | 不変ストレージ(AzureBlobStorage)に関する手記

3.3.AzureBlovStorageのアクセス層

AzureBlobStorageには以下、5つのアクセス層が用意されています。

• Hot層
• Cool層
• Cold層
• Archive層

デフォルトで設定可能なのは、Hot層とCool層のみになります。あとのCold層とArcive層はライフサイクル設定にて移動可能なアクセス層となります。
各アクセス層の違いについてはDocsが一番わかりやすいので、以下ご確認下さい。

• MS Learn | BLOB データのアクセス層

3.3.1.ライフサイクル設定の検討

まずは「予算」と「想定されるログ容量」、「使用頻度」を推定しましょう。その上で、エクセル表を駆使して、予算内に収まるベストな案を考えることが求められます。
あと、Hot層以外は保存期間が短いとペナルティ(費用)が発生しますので、その点についても注意しましょう。

私のお勧めパターンは、半年に１回程度しか使用しないログであれば、「Hot層(1w)⇒Archive層(法定機関)⇒削除」です。

3.4.ネットワーク設定

ログを保管するだけなので、基本的にプライベート通信以外は許可しない設定が好ましいです。ログとはいえ、外部に漏洩してはいけない情報も含むことが多いので、パブリックアクセス可能なサブネットとは極力分けて構成することをお勧めします。

ただし、データエクスポートには一部設定が必要なのでご注意下さい!!
以下記事の「StorageAccountのネットワーク設定」をご参照下さい。
MSLearn | LogAnalyticsWorkspaceのデータエクスポート設定について

3.5.冗長性の保証

ログの損失の影響度が高い場合は、StorageAccountの冗長化設定が必要となります。リージョン障害を考慮した際に、おそらく候補になってくるのは以下のあたりです。

• GRS：基本はこれ
• RA-GRS：階層型名前空間を有効化している場合はこっち

実はArchive層におけるGRSとRA-GRSの料金は同じ（2024年8月現在）なので、RA-GRSを選んでもあまり費用的には変化はないかと思いますが、一度料金を計算しておくことをお勧めします。

4.まとめ

ここまでつらつらと各保管用途ごとの検討方法を記載してきましたが、結論として私の考えるベストプラクティスは以下です。是非、ご参考にしてください。

本来、システム構成はシステム要件に合わせて設計する必要があります。あくまで、参考までに捉えて下さい。