こんにちは！日々のログ分析や障害対応、本当にお疲れ様です。
システムが巨大化するにつれて、こんな悩みに直面していませんか？
「アクセスログや監査ログは法規制やセキュリティの観点から長期間保存しておきたいけれど、Datadogのインデックス化コスト（Indexing Cost）が爆発して予算を圧迫している……」
「かといって、安いストレージに放り込むと、いざという時に検索が遅すぎて使い物にならない……」
そんな、すべてのSREやインフラエンジニアが頭を抱えてきた永遠のジレンマを鮮やかに解決するのが、今回紹介する「Datadog Flex Logs」です。
これをマスターすれば、毎日のコストの心配から解放されつつ、必要なインサイトを瞬時に引き出せるようになりますよ。今日は、その本質と実践的なセットアップ手法を、優しく紐解いていきましょう。
—
1. Flex Logsとは何か？ 従来のIndex Logsとの決定的な違い
まず、Datadogにおけるログ管理のパラダイムシフトを理解しましょう。
これまで、Datadogに送られたログは、届いた瞬間にパースされ、インデックス（Index Logs）に登録されていました。これにより超高速な検索が可能になる反面、「すべてのログにインデックス代という高い通行料を払う」構造になっていました。たまにしか見ないデバッグログや、トラブルシューティングで「もしかしたら使うかもしれない」レベルの膨大なログに、メインメモリ級のコストを払い続けるのは、財務的につらいものがあります。
Flex Logsの正体：冷たいストレージ、熱いクエリ
Flex Logsは、一言で言えば「圧倒的な低コストで長期間保存でき、必要な時だけSQLライクにスキャンできるストレージ層」です。
- Index Logs（従来の高速層）： メモリやSSDのイメージ。コストは高いが、リアルタイムのダッシュボードやアラートに最適。
- Flex Logs（新世代の経済層）： S3などのオブジェクトストレージベース。コストは従来の数分の一と極めて安価だが、全件スキャンには少し時間がかかる（とはいえDatadogの最適化により実用的な速度が出ます）。
つまり、「毎日ガンガン見るクリティカルなエラーログはIndex Logs」「監査やトラブルシューティング用の巨大な生ログはFlex Logs」というように、データの「熱量」に合わせて適材適所で使い分けるのが、モダンなオブザーバビリティの常識です。
—
2. コストを抑えて長期間保持するためのストレージ最適化設定
それでは、実際にDatadog上でFlex Logsをセットアップし、コストを最小化しながら長期間保持するための設計を行っていきましょう。
初心者の方でも迷わないよう、ステップバイステップで解説します。
ステップ1：ログのルーティング（Archive vs Flex Logs）
まず前提として、Datadogに送られてくるすべてのログを、最初からインデックスに通してはいけません。Pipeline（パイプライン）機能を使って、ログの重要度（Status）やサービス名に応じて宛先をコントロールします。
ここで重要になるのが、「インデックスを通さずに直接Flex Logsへルーティングする」という設定です。
DatadogのUIまたはTerraformなどのIaCツールを使い、インデックスの割り当てルールを設定します。以下は、Terraformを用いて「重要度の低いデバッグログや情報ログを、インデックスコストをかけずにFlex Logs側へ流す」ためのイメージに近い設定例です。
TerraformによるDatadogログインデックス・アーカイブの最適化設定例
resource “datadog_logs_index” “flex_routing_example” {
name = “cost_optimized_flex_index”
filter {
# エラーや警告以外（INFOやDEBUG）をキャッチ
query = “status:info OR status:debug”
}
daily_limit = 1000000 # 日別のリミットを設定して予期せぬ暴走を防ぐ
# 保持期間の調整（コスト最適化のキモ）
# 高コストなインデックス保持期間は最小限（例: 3日）にし、
# 残りはFlex Logsやアーカイブへ逃がす設計にします
num_retention_days = 3
}
> 先輩からのアドバイス：
> 「とりあえず全部インデックスする」という初期設定のまま放置するのが、クラウド費用の最大の無駄遣いです。`status:error` 以外はFlex Logs行きにするだけで、コストが数分の一に激減するケースも珍しくありません。
—
3. クエリ時のパフォーマンスを維持するためのインデックス設計とコスト対効果の最大化手法
「安いのは分かったけれど、検索が遅かったら意味がないよね？」
ごもっともです。Flex Logsでパフォーマンスを維持しつつコスト対効果を最大化するためには、「Facet（ファセット）とIndexの最小化」が鍵になります。
ファセットを絞り、スキャン効率を最大化する
Flex Logs環境下では、すべてのJSONキーに対してインデックスを張る必要はありません。
検索で頻繁に使うキー（例: `http.status_code`, `user.id`, `error.kind`）だけにファセットを定義し、それ以外は「アドホック（その場しのぎ）な検索」に任せます。
Datadogの検索クエリを書く際は、以下の鉄則を守りましょう。
【良い例】インデックス化されたファセットとタイムスタンプで範囲を絞り込む
service:web-api status:error @http.status_code:500 timestamp:[now-7d TO now]
【避けるべき例】範囲を絞らず、巨大な文字列の部分一致（Wildcard）だけで検索する
- “database connection timeout”
コスト対効果を最大化する3つの黄金律
1. 「3日・30日・365日」のルールを決める
- リアルタイム監視用（Index）：3日間
- 一般的なトラブルシューティング用（Flex Logs）：30日間
- コンプライアンス・監査用（Flex Logs / Archive）：365日間
このように、データの寿命に合わせてストレージ階層をスライドさせます。
2. 不要なログは「落とす（Drop）」
そもそも保存する価値のないヘルスチェックのログ（`GET /healthz` 等の200 OK）は、Datadogに送る手前のエージェント（Datadog Agentのログ収集設定）か、DatadogのPipelinesの「Drop processor」で最初から捨てるのが最大のコスト削減になります。保存しないログが、一番安いのですから。
3. クエリの「スコープ」を常に意識する
Flex Logsを検索する際は、必ず `service:` や `env:` などのタグで検索範囲を狭めてからキーワード検索を行ってください。無駄なスキャンデータ量を減らすことが、結果的にクエリの高速化に直結します。
—
おわりに：今日から始める第一歩
Datadog Flex Logsは、単なる「安いストレージ」ではありません。「ログはすべて高いお金を払ってインデックスしなければならない」というこれまでの常識を覆し、オブザーバビリティをより持続可能なものにするための強力な武器です。
まずは、今のログインデックスの中で「本当に3日間以上高速に検索する必要があるログはどれくらいあるか？」を見直すところから始めてみてください。
これをマスターすれば、財務部門からのコストツッコミに怯えることなく、エンジニアとして必要なすべてのインサイトを手の内に収めることができます。あなたのシステムの運用が、よりスマートで快適なものになることを応援しています！