Datadog Flex Logs：コストの檻を破壊し、全ログから「真実」を抽出するアーキテクチャ設計
運用監視の現場において、我々は常に一つのパラドックスと戦っている。「すべてのログを保持すれば破産するが、ログを捨てれば障害の真相は見えなくなる」という悪魔の取引だ。
これまで、DatadogのIndex Logsは、高速だが高価な「高級品」だった。しかし、Flex Logsの登場によって、このゲームのルールは変わった。これは単なるストレージの節約術ではない。ログを「コストセンター」から「戦略的資産」へと再定義する、オブザーバビリティのパラダイムシフトだ。
本稿では、Flex Logsを骨の髄まで掌握し、コストを極限まで最適化しながら、死角のない監視基盤を構築する術を伝授する。
—
1. Flex Logsの本質：インデックスの呪縛からの解放
従来のDatadogの運用において、最も重いコストは「Ingest」ではなく「Index」にあった。検索可能にするためのインデックス生成プロセスが、高額な課金の源泉だったからだ。
- Index Logs (旧来型): リアルタイム検索に最適化されたインメモリ/SSDストレージ。だが、保持期間が長くなれば指数関数的にコストが跳ね上がる。
- Flex Logs: インデックスを貼らない（あるいは必要最小限にする）代わりに、安価なストレージへ直接書き込む。「必要になったらスキャンする（Rehydration）」というアプローチだ。
この設計思想は、GoogleのDremelやAWS Athenaのそれに近い。「計算リソース（検索）は必要な時にのみ使い、ストレージ（保持）は安く済ませる」という原則を徹底している。
—
2. コスト最適化の極致：ライフサイクル戦略の自動化
Flex Logsの真価は、「どのログをインデックスし、どれをFlexで保持するか」の選別にある。すべてのログをIndexedにするのは怠慢であり、すべてをFlexにするのは盲目だ。
推奨戦略：2層アーキテクチャ
1. Critical (Indexed): 500系エラー、セキュリティイベント、ユーザー認証失敗。これらはMTTRを左右するため、即時検索が必須。
2. Telemetry/Debug (Flex): 200系アクセスログ、アプリケーションの詳細デバッグログ。これらはフォレンジックや長期分析用であり、Flexで十分だ。
自動化スクリプト：Datadog APIを用いた動的ログ設定
UIでポチポチ設定するなど、伝説的エンジニアの所業ではない。TerraformまたはDatadog APIを使って、ログのルーティングを完全にコード化しろ。
import requests
import os
Datadog API設定
DD_API_KEY = os.getenv(“DD_API_KEY”)
DD_APP_KEY = os.getenv(“DD_APP_KEY”)
HEADERS = {“DD-API-KEY”: DD_API_KEY, “DD-APPLICATION-KEY”: DD_APP_KEY}
def set_log_retention(index_name, retention_days, is_flex=True):
“””
特定インデックスの保持設定をAPI経由で強制更新する
Flex Logsへ移行し、コスト効率を最大化する
“””
url = f”https://api.datadoghq.com/api/v1/logs/config/indexes/{index_name}”
payload = {
“daily_limit”: 500000000, # 500GB制限
“retention_days”: retention_days,
“flex_logs”: is_flex # ここが肝：Flex Logsを有効化
}
response = requests.put(url, json=payload, headers=HEADERS)
if response.status_code == 200:
print(f”Successfully optimized {index_name} to Flex Logs.”)
else:
print(f”Failed: {response.text}”)
実行例：DEBUGログをFlexに移し、90日間保持する
set_log_retention(“app-debug-logs”, 90, is_flex=True)
—
3. パフォーマンスを維持する「インデックス設計」のハック
Flex Logsに投げ込んだデータは、検索時に「スキャン」が発生する。ここで重要なのは、「クエリの解像度」を保つためのパーティショニングだ。
構造化ログ（JSON）の強制
プレーンテキストのログをFlex Logsに放り込むのは、ゴミ箱に書類を投げ込むのと同じだ。後で「特定のリクエストID」を検索する際、スキャン範囲が広大になり、結果が返るまでコーヒーを飲み終わってしまうだろう。
- 属性の正規化: `service`, `env`, `version`, `status_code` は全てのログに必ず含める。
- 高頻度属性のインデックス化: Flex Logsであっても、Datadogの「Facet」機能を使えば、検索パフォーマンスを劇的に向上させることができる。
内部ハック：スキャン効率を最大化する「タグ」の設計
Datadogの内部アーキテクチャにおいて、Flex Logsは時間軸でチャンク化されている。クエリ実行時に `service:my-api AND status:500` のように、必ず「狭い時間範囲」と「高基数（high-cardinality）な属性」を指定せよ。
- 悪いクエリ: `@message:database_error` (フルスキャンが走り、数分かかる)
- 良いクエリ: `service:order-svc AND @status:500 AND @db.query_time:>100ms` (インデックスされた属性で絞り込み、Flex領域を最小限のスキャンに留める)
—
アーキテクトからの提言：最後に
Flex Logsは魔法の杖ではない。それは「データ管理の責任」をエンジニアに突きつける鏡だ。
ログを適切に構造化し、ライフサイクルをコードで管理し、必要な時に必要なだけ計算リソースを叩き込む。この規律を守れる者だけが、莫大なログデータを「宝の山」に変えることができる。
コストを恐れてログを削るな。Flex Logsという武器を手に取り、すべてのログを掌握せよ。それが、システムの本質を理解する唯一の道だ。
次に現場で障害が発生した時、君は「ログがない」と嘆くのではなく、「Flex Logsから過去90日分をスキャンして、相関関係を特定した」と報告するはずだ。それが、我々が目指すべきプロフェッショナルの姿である。