はじめに
おはこんばんちわ、ACS事業部の髙井です。
みなさんIgniteですよ、Ignite！
Microsoftの年次イベント、Ignite 2022 が絶賛開催中です。
ちなみに昨日深夜の基調講演については、優秀なチームメンバーがちゃんと見て重要な情報をピックアップしてくれているだろうナ～と思って余裕で寝てました。
すみません、いつか天罰が下るので許してください。
イベント開催に合わせたくさんのアップデート情報が公開されています。 案の定すでにチームメンバーがいくつも記事を公開してくれていますが、個人的に
Azure Monitor LogsのGA
が気になっているので簡単にまとめます。
とくに、Basicログによるインジェスト料金の大幅な圧縮や、 取り回しが悪く不便だったストレージアカウントへのエクスポートなしに最長7年の安価なアーカイブ保存が可能になったことが、 これまでのAzureログ保存のベストプラクティスを変容させるポイントかと思います。
▼他の方々が夜のうちにアップしてくれていたアップデート速報▼
Azure Monitor Logs の General Availability
公式のリリース（英語）はこちらのページです。
また、Azure Observability Blogにも以下のエントリが出ています。
従来のAnalyticsログに加え、今回、新たに4種類の概念がAzure Monitorのログ体系として公開されました（プレビュー開始は今年初頭）。
- Analytics Logs（従来のログ）
- 従来のLog Analyticsで利用していたログです。柔軟なクエリに対応していますが、インジェスト料金が1GBあたり約480円とそれなりに高額です。
- Basic Logs（基本ログ）
- 通常はアラートや詳細分析を行わないことを前提に従来の4分の1程度の価格でログを保持できます。ただし、クエリを発行する際には追加の料金を支払います。
- Archived Logs（アーカイブ）
- これまで保持期間が最長2年だったLog Analyticsのログを、ストレージに移すことなくシームレスにアーカイブとして安価に保管できます。
- Search Job（検索ジョブ）
- 従来クエリの時間制限10分を超える長時間の非同期な検索ジョブを実行し、レコードを新しい永続的なLog Analyticsテーブルにフェッチします。
- Restore logs（復元）
- アーカイブされたログのうち、特定の時間範囲をクエリ可能なログとしてホットキャッシュに復元します。
Basic Planへの変更と保持期間の設定
なにはともあれ、まずはAzure Portalで新機能のインターフェースを確認しましょう。
新しいAzure Monitor Logsを利用するには、Log Analytics WorkspaceのTablesブレードにアクセスします。
（この記事を執筆する時点ではGAアナウンスから時間が経っていないからか、preview表記が消えていません）
ログは、既定では従来のAnalyticsログで保存されるため、Basicに変更したいログは対象となるテーブルの左側にある「…」のマークからTable Planを変更します。
変更画面ではPlanのほかに保持期間の設定ができます（ただし、Basicプランの保持期間は8日間で固定です）。
ログの保持期間の詳細については、以下の公式ページに載っています。
為替レートによっても変動しますが、以下を押さえておけばよいかと思います。
| ログの種類 | 保持期間 | ログの新規保存 | ログの保持 | 検索 |
|---|---|---|---|---|
| Basic | 8日固定 | 約100円/GB | 約20円/GB･月 | 約1円/GB |
| Analytics | 31日-最長2年 | 約480円/GB | 約20円/GB･月 | なし |
| Archive | 最長7年 | なし | 約4円/GB･月 | 検索：約1円/GB 復元：約20円/1日 |
ポイントとしては、アーカイブによって、これまでのように取り回しが悪かったStorage Accountへの移行をせずとも7年間の保管が可能になったことは大きいかと思います。
とくに、最初からストレージアカウントにエクスポートしなくてよいのが大きな変容点です。
これまで長期保存をする場合には、それを見越して最初から診断設定でストレージアカウントにエクスポートを設定しておく必要がありました。 つまりLog Analyticsにも出力しつつ、ストレージアカウントにも出力する、という二重管理が必要でした。
現在はエクスポート機能があるので大丈夫ですが、以前だとLog Analyticsのログ保持は最長2年のため、保持期間をすぎてから長期保存に移行したくても、最初からストレージアカウントに出していないと詰むという問題もありました。
（Log Analyticsからのエクスポート機能については以下の記事が参考になります）
こうしたログ周りの面倒を今回のアーカイブ機能は大いに緩和してくれます。
検索・復元
アーカイブされたログを再びLog Analyticsでクエリできる状態にするのも非常に簡単になりました。
以前ならストレージアカウント内のデータをData Explorer等を用いてこねくり回す必要があったので、これも非常に大きな変化点です。
対応する公式ドキュメントは以下のページです。
検索も復元も、プレビュー時点ではAzure Portal上での操作はサポートされておらず、REST APIエンドポイントもしくはCLI経由での操作のみでした。
ただし、検索に関しては、GAにあたってLog Analyticsのページに「Search job mode」が実装されたようです。
では、検索と復元の違いをまとめておきましょう。
検索
特定の条件に合致するレコードを大量に（最大100万レコード）フェッチできます。非同期で実行され、従来クエリの時間上限10分を超える長時間（最大24時間）のクエリを発行できます。
制約事項として、以下に留意する必要があります（上記の公式ドキュメントより引用）。
- 一度に 1 つのテーブルに対してクエリを実行するように最適化されています。
- 検索の日付範囲は最長で 1 年です。
- 実行時間の長い検索は、最長 24 時間でタイムアウトするまでサポートされます。
- レコード セット内の結果は、100 万レコードに制限されます。
- 同時実行は、ワークスペースごとに 5 つの検索ジョブに制限されます。
- ワークスペースあたり 100 個の検索結果テーブルに制限されます。
- 1 つのワークスペースで 1 日に実行できる検索ジョブは 100 回までに制限されます
ポイントとしては、まだアーカイブ化されていないBasicログから短時間で済むクエリを発行する場合に、通常クエリを有料で発行するのと検索ジョブを利用するのか、コスト最適な選択肢が状況によって変わることが予想されます。
また、検索後のデータは明示的な削除が必要です。削除しないとホットキャッシュ同等の保持料金（20円/GB･月）が発生し続けます。
復元
あるテーブルから特定期間（最低2日以上）のデータをホットキャッシュに復元します。こちらも利用後に不要となった場合は、明示的な削除が必要です。
したがって、原因が絞り込めていて特定のレコードが欲しい場合は「検索」ジョブを一発走らせればよいですが、そうではなく、特定期間のログについてあーだこーだいろんなクエリをかけて原因追及をしたいといった場合は、復元を使うほうがベターなケースが多いでしょう。
こちらも、公式ドキュメントから重要な制限事項を引用しておきます。
- 少なくとも 2 日間のデータを復元します。
- 最大 60 TB 復元します。
- 1 週間あたり 1 つのワークスペースに対して最大 4 回の復元を実行します。
- 1 つのワークスペースで同時に最大 2 つの復元処理を実行します。
- 特定のテーブルに対して、特定の時点でアクティブな復元を 1 つだけ実行します。 アクティブな復元が既に実行されているテーブルに対して 2 個目の復元を実行すると失敗します。
とくに、1つのテーブルに対してアクティブな復元は1つまで、という制約には気を付ける必要がありそうです。
特定の1週間のデータを復元したけど、実は10日分必要だった！みたいなケースでは泣く泣く1回目の復元データは破棄ということになるということかと思われます。
おわりに
Igniteには他にも便利そうなアップデート情報が目白押しですが、こういうログまわりのアップデートみたいなのが地味に一番うれしかったりします。
ついにGAとのことなので、お客様に向けた提供でも自信をもってオススメできるようになり、嬉しい限りです。
他にもイイ感じの情報があったらブログにしていきたいと思います。それでは、髙井先生の次回作にご期待ください。
