Datadog Flex Logs：コストを殺し、インサイトを狩る「真のデータ戦略」
エンジニア諸君、プロダクトが成長するにつれ、ログは「宝の山」から「コストのゴミ捨て場」へと変貌を遂げていないか？
「とりあえず全部投げ込んでおけば安心」という時代は終わった。DatadogのFlex Logsは、単なる「安いストレージ」ではない。これは、運用監視の設計思想を「高コストな即時インデックス」から「必要な時に必要なだけ掘り起こす」というオブザーバビリティの再定義である。
今回は、現場のテックリードとして、このFlex Logsを使いこなし、コストを抑えつつ開発速度を最大化する極意を伝授する。
—
1. Flex Logs vs Index Logs：なぜ今、設計を変えるべきか
従来の「Index Logs」は、ログが届いた瞬間にパースし、インデックスを貼る。これは高速だが、「全てのログをクエリ可能にする」ために、ストレージコストとインデックスコストが二重にのしかかる。
一方、Flex Logsの神髄は、「保存コストを極限まで下げつつ、必要に応じて後からインデックスを付与して検索できる（Rehydrate）」点にある。
- Index Logs: 高頻度でアクセスするエラーログ、直近のデバッグ用ログ（保持期間は短く）。
- Flex Logs: 監査ログ、長期的な傾向分析用データ、デバッグ時にしか見ない詳細なリクエストログ（保持期間は長く、安価に）。
この使い分けができないチームは、今後間違いなくコストで死ぬ。
—
2. コストを抑えるためのストレージ戦略とインデックス設計
Flex Logsでコストを最適化する鉄則は、「クエリの解像度を動的に変える」ことだ。
実践：ベストプラクティス構成例 (terraform)
ログのルーティングには `Log Pipelines` と `Archives` を活用せよ。全てをDatadogに入れず、一部をS3へアーカイブし、必要に応じてFlex Logsへ「再取り込み（Rehydration）」するフローを確立する。
Datadog Log Indexの最適化設定（概念）
全てのログをIndexするのではなく、重要なエラーのみをIndex Logsへ流す
logs_config:
- name: “critical_errors”
filter: “status:error OR service:auth-service”
retention_days: 15 # 高コストなIndex Logsは短期間のみ保持
- name: “flex_logs_storage”
# 低コストなFlex Logsへルーティング
# 実際にはLog Archive設定にてS3/GCSを指定し、検索時はRehydrateを使用
storage_class: “flex”
retention_days: 365 # 1年間保持しても格安
パフォーマンスを維持する「インデックス戦略」
Flex Logsからクエリを投げる際、闇雲に検索してはならない。「Attributeの正規化」が全てだ。JSONの階層が深いログは検索コストが跳ね上がる。パイプラインでフラットな構造に加工してから投入せよ。
—
3. 現場で震えるほど役立つ「加速」テクニック
チームの生産性を底上げするための、現場で必須の小技を共有する。
A. 隠れたキーボードショートカット
Datadogのログ画面でマウスを触っているようでは二流だ。
- `Shift + ?`: 全ショートカット一覧を表示。これを叩き込んでおけ。
- `g` → `l`: 瞬時にログエクスプローラーへ移動。
- `Cmd/Ctrl + Enter`: クエリの実行。
B. 絶対入れるべき「神」プラグイン・設定
ブラウザ拡張機能の 「Datadog Query Helper」 は必須だ。クエリの構文エラーを即座に指摘してくれる。また、チーム開発では「Saved Views」の共有が命だ。
チーム開発のルール：
- クエリの共有はURLではなく「Saved View」で。 URLはパラメータが複雑になりすぎて破損する。
- View名には「[Service名] – 役割 – 作成者」を明記。 例: `[Order-Svc] 決済失敗の相関分析 – @sato`
C. 実用的なアラート設定のYAMLテンプレート
過剰なアラートはノイズだ。Flex Logsを活用し、「異常値」のみを検知する。
Datadog Monitor: ログボリュームの急増を検知してコスト暴走を防ぐ
name: “Log Volume Anomaly Detection”
type: “log alert”
query: “logs(\”service:my-app\”).rollup(\”count\”).last(\”1h\”) > 5000″
message: “ログボリュームが閾値を超えました。Flex Logsの無駄な取り込みが発生していないか確認せよ。”
thresholds:
critical: 5000
—
結論：オブザーバビリティは「哲学」である
Flex Logsを導入することは、単にクラウドの請求額を減らすことではない。「何が重要で、何がノイズか」をエンジニアが定義するという、極めて高度な知的作業だ。
インデックスされたログの中に埋もれている「本当の答え」を探し出すために、今すぐIndex Logsの保持期間を見直し、Flex Logsへデータを逃がせ。
現場で迷ったときは、こう自問せよ。
「このログを、半年後の俺は検索するためにいくら払えるか？」
その問いに対する答えが、最強のインフラ構成を作る鍵となる。さあ、今すぐコンソールを叩け。