CloudWatch Logs に Infrequent Access クラスが追加されたのでユースケースを考える
はじめに
2023/11/26 に CloudWatch Logs の新しいログクラスである Infrequent Access（Logs IA）が追加されました。
Infrequent Access といえば S3 のストレージクラスを連想しますが、Logs IA も同じようにアクセス頻度の低いログのために設計された CloudWatch Logs の新しいログクラスです。今回は Logs IA のユースケースを検討してみました。はじめに結論を述べておくと、個人的には使いどころの難しい機能だなーという印象です。料金の安さだけを理由に採用するとあとで困ったことになりそうなので、備忘も兼ねて検討事項を整理します。
CloudWatch Logs Infrequent Access とは
現状は以下の AWS News Blog のポストが一番わかりやすいです。
従来の Standard クラスと比較してログの取り込み料金を 50% オフ（0.38 USD / GB）する代わりに、多くの機能を制限した新しいログクラスです。機能比較表を以下に引用します。
| Feature | Infrequent Access log class | Standard log class |
|---|---|---|
| Fully managed ingestion and storage | Available | Available |
| Cross-account | Available | Available |
| Encryption with KMS | Available | Available |
| Logs Insights | Available | Available |
| Subscription filters / Export to S3 | Not available | Available |
| GetLogEvents / FilterLogEvents | Not available | Available |
| Contributor, Container, and Lambda Insights | Not available | Available |
| Metric filter and alerting | Not available | Available |
| Data protection | Not available | Available |
| Embedded metric format (EMF) | Not available | Available |
| Live Tail | Not available | Available |
ログ収集の目的
ログ収集の目的はひとつではありません。目的に応じて求められる要件が異なるため、まずはざっと整理してみたいと思います。
操作証跡の保管
ユーザー操作等、システム上で発生したイベントをログとして保管します。このログは頻繁に閲覧されることはありません。いざという時に何らかの手段で閲覧できれば十分というケースも多く、高度な検索性は求められません。
一方で監査に備えて長期間保管する必要があったり、セキュリティ的な考慮からログに対するアクセス権限を厳密に管理することが求められたりします。
トラブルシュート
トラブルシュートには問題発生時のログが不可欠です。この場合、数ヶ月前に発生したトラブルの原因調査を行うことはあまり想定されないため、長期間ログを保管しておく必要はありません。直近 1 ヶ月程度のログがあれば十分だと思います。
また、トラブルシュート時はログをいろんな条件でフィルターしたり、同じ時間帯の異なるログを比較するなど高度な検索性が求められます。
監視
ログに含まれる情報からシステムに問題が発生したことを検知します。
基本的には問題発生を検知したタイミングでログ収集の目的は達成されるため、ログの保管期限に対する考慮は不要です。監視目的で収集したログは人間が閲覧するものではありません。そのため高度な検索機能は不要に思えますが、多くの場合ログ監視の条件は検索機能を用いて実装されるため、監視条件が複雑になる場合はそれなりの検索性が必要です。
用途に応じたログの仕分け
ひとつのログを複数の用途に使い回すこともありますが、その場合は AND 条件になります。
つまり「長期保管できて、複雑な検索もできて、システムが取り扱いしやすい構造で、人間にとっても可読性が高くて〜」みたいな条件になってしまうので、Logs IA のように「機能制限はあるけどコストが安い」というような特殊なクラスを活用することは難しいです。
ランニングコストを度外視できるのであれば、Datadog などのような SaaS にすべてのログを突っ込む、というのがシンプルで良いですが、実際にランニングコストを無視することはできません。高度な検索性を有したサービスはログの取り込みに関する料金が高い傾向にあるため、適切な単位でログの用途を分割してあげるのが現実的です。例えば、要件に共通する部分の多いトラブルシュートと監視には CloudWatch Logs を使用し、操作証跡の保管には S3 を使用する、みたいなケースが一般的です。
ログルーティング
ログ収集に複数のサービスを使い分ける場合はルーティングの考慮が必要です。
CloudWatch Logs はサブスクリプションフィルターという強力なルーティング機能を備えています。
ログのように大量のデータを高速に処理するのは実は結構大変なことですので、マネージドサービスでその辺をうまくやってくれると非常に助かります。ただし Logs IA はサブスクリプションフィルター機能を使用できないため、ログルーティング的には 「行き止まり」 です。
Logs IA のユースケース
前置きが長くなりましたが、ここからは実際に Logs IA のユースケースについて考えてみます。
操作証跡の保管に Logs IA を使用する
操作証跡のように長期保管が必要なログの収集に利用するというのが Logs IA の一般的なユースケースです。一方で、Logs IA をログの長期保管先として考えたときは S3 が競合になります。
S3 に保管したログを検索するには S3 Select や Athena などを使用します。CloudWatch Logs は以下のキャプチャのようにコンソールから直接ログを検索することが可能ですが、Logs IA に保管したログは CloudWatch Logs Insight を使用しないと検索できません。
CloudWatch Logs のログ検索コンソール
どうでもいい話
ところで本記事の執筆にあたり「Standard」という名前のロググループを作成してみたんですが、ページ上部のパンくずリストに「スタンダード」とカタカナで表示されるバグ？を発見しました。もちろんブラウザの翻訳機能は使用してません。AWS は公式ドキュメントの日本語翻訳がおかしいことでも話題になってましたね😂
コストだけで見れば Logs IA と比較してもまだまだ S3 の方が安いですし、あとは検索ツールの使い勝手を鑑みてどちらを選ぶかといった感じです。
個人的にはちょっとした確認であれば CloudWatch Logs のコンソールから検索してしまうことも結構多いので、これが Logs IA で使えないというのはちょっとマイナスです。普段から CloudWatch Logs Insight をがっつり使用している方は困らないかもしれませんね。
ただ、こちらについてもどうせクエリを書くのであれば今後の拡張性も踏まえて Athena で検索できるようにした方がいいんじゃないかと思います。繰り返しにはなりますが Logs IA は現状ログの「行き止まり」になります。Logs IA はサブスクリプションフィルターも S3 へのエクスポートも非対応のため、別のサービスにログを移行する手段が限定されます。CloudWatch Logs Insight で検索した結果をエクスポートする手段がとれそうですが、全てのログを対象にすると結構なコストになるのではないでしょうか。
長期保管に使用するだけだから別にそれでも良い、という判断もアリですが、収集したログをもとに何らかの分析をしてみたくなった時は、まずログの引越し手段の検討が必要となります。また、監査ログは保管期限が定められており簡単に破棄できないケースもあります。将来的にシステム移行が必要となった際に、ログの引越し手段が課題となる可能性があることは認識しておきましょう。
トラブルシュートに Logs IA を使用する
取り込み料金が安く最低限の検索もできるため、現在 CloudWatch Logs を使用していて、さらにログ収集に関するコストを安くしたいといったケースではある程度需要がありそうです。
そのまま Logs IA で長期保管も行う場合は特に考慮不要ですが、別のサービスで長期保管を行いたい場合は CloudWatch Logs へ送信する前に Fluentd などでルーティングすることができます。Logs IA で１ヶ月程度の短期間保管し、長期保管には S3 を利用する、というような構成をとることも可能です。
この構成の注意点は Logs IA に収集したログは監視できないということです。例えばトラブルシュートを行うため Logs IA にログを収集したとして、当該ログの監視が必要となった場合は別途監視サービスにもログを収集しないといけなくなるため、かえってコストがかかります。
監視に Logs IA を使用する
先述の通り Logs IA は監視に使用することができません。
CloudWatch Logs に収集したログに特定の文字列が含まれていた場合は通知する、みたいなことを実装するには、メトリクスフィルターや埋め込みメトリクス形式などの機能を使用してメトリクスを生成する必要がありますが、Logs IA はそのどちらの機能も使用できません。監視が必要なログは Standard クラスのロググループに収集しましょう。
なお、一度作成したロググループのクラスは変更不可です。あとから監視したくなっても手遅れですのでくれぐれも気をつけてください…。
おわりに
ログをクラウド上に保管するとき、実際に運用が始まってみると思ったよりコストが掛かってしまう、みたいなことがよくあります。低コストである程度の閲覧機能を有した Logs IA は新しい選択肢の 1 つではあるものの、機能制限が多くなかなか難しい印象です。
Logs IA はログを CloudWatch Logs で一元管理することで可観測性を高めることを目的としたサービスですが、ここまで機能制限が多いと結局他のサービスとの併用が前提になってしまいます。S3 と比較してそこまで CloudWatch Logs を中心としたエコシステムが充実していない中、ログの移行に大きな制限を受けることは個人的には看過できないデメリットと感じます。
また、ログ収集は運用を続けてデータが増えてくるとその活用に向けて新しい要求が出てきたりします。一方で、システムの成長に伴いログの流量が増えてくると収集自体の難易度も上がっていくため、リリースしてから時間が経つほど 「変更したいけど変更しにくい」 状況が生じる難しい領域です。ログ収集に要するランニングコストはもちろん大事な要素ですが、それ以外に大事な検討事項がいくつもありますので、ログクラスは十分検討して選択しましょう👍
Discussion