概要
APM の75%は除外可能
ヘルスチェック・静的ファイルが全スパンの60%。除外 + 20%サンプリングで $8,500 → $714(92%削減)。
ログは「上流で捨てる」
OTel Collector の filterprocessor で INFO/DEBUG を DROP。DataDog に届く前に排除することで取り込みコストもゼロになる。
カーディナリティ爆発を防ぐ
Custom Metrics は「メトリクス名 × タグ組み合わせ数」が課金単位。pod_name / host タグを削除するだけで70%削減。
ペイバック約1ヶ月
工数8人日(384,000円)で月額405,000円削減。初年度ROI 1,165%という圧倒的な費用対効果。
問題
ECサイトMOpsチームのDataDog月次コスト($6,200)を $3,500 以下に削減せよ。
現状の DataDog 利用構成
| 課金要素 | 現状 | 月額コスト(割引前) |
|---|---|---|
| APM(Indexed Spans) | 50億スパン/月 @ $1.70/100万 | $8,500 |
| Custom Metrics | 8,000メトリクス @ $0.05/メトリクス | $400 |
| ログ管理(取り込み+保存) | 500GB/月、30日保存 | $1,800 |
| Synthetic Tests | 200テスト × 12回/時間 | $600 |
| 合計(割引前) | $11,300 | |
| 合計(45%コミット割引後) | $6,200/月 |
課題情報
- APM: ヘルスチェック(
/health)や静的ファイルリクエストが全スパンの 60% を占める - Custom Metrics:
host/region/pod_nameなどの高カーディナリティタグで爆発中 - ログ: 全ログを INFO レベルから取り込み。実調査では WARNING 以上のみを使用
- Synthetic: 変更頻度の低いエンドポイント150個が高頻度テスト対象になっている
前提: DataDog Agent v7 + OTel Collector(OTLP)| GKE Autopilot + Python(FastAPI)+ Argo Workflows
目標: $6,200 → $3,500 以下(44%削減)| 工数: 8人日、6,000円/時間、1USD=150円
期待する回答形式: 数値計算 + 施策提案(設定例・フェーズ計画含む)
目標: $6,200 → $3,500 以下(44%削減)| 工数: 8人日、6,000円/時間、1USD=150円
期待する回答形式: 数値計算 + 施策提案(設定例・フェーズ計画含む)
ヒント(段階的開示)
ヒント1 — 方向性
DataDog の課金は「インデックス件数 × 単価」構造。削減するには フィルタリング(取り込まない) と サンプリング率の調整 が王道。APM スパン($8,500 = 全体の75%)から着手すること。
ヒント2 — 各要素のアプローチ
- APM:
DD_APM_IGNORE_RESOURCESでヘルスチェック除外 → サンプリング率20%(エラーは100%) - Custom Metrics:
host/region/pod_nameタグを削除してカーディナリティを 1/3 に - ログ: OTel Collector の
filterprocessorでseverity_number < WARNを DROP - Synthetic: 重要50テストのみ12回/時間を維持。残り150テストは1回/時間へ
ヒント3 — 計算の骨格
【APM削減試算】
ヘルスチェック除外後: 50億 × (1-0.60) = 20億スパン
サンプリング20%: 4億スパン
エラー1%(100%保持): 0.2億スパン
合計: 4.2億 × $1.70/100万 = $714(削減率92%)
【ログ削減試算】
WARNING以上は全体の10%想定: 50GB/月
取り込み: 50GB × $0.10 = $5
保存7日: 50GB × $0.24/GB × (7/30) ≈ $28
合計: ≈ $33(削減率98%)
【Synthetic削減試算】
変更後: (50×12 + 150×1) × 720 = 540,000回/月
元: 200×12×720 = 1,728,000回/月
削減率: 69% → コスト $600 × 31% ≈ $208
模範解答: APM フィルタ設定(Bad → Good)
Bad — 全スパン無差別収集
# otel-collector-config.yaml
# ❌ フィルタなし: ヘルスチェックも全収集
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch] # ← フィルタ処理なし
exporters: [datadog]
# ❌ サンプリング率: 100%(デフォルト)
# 50億スパン/月 → $8,500/月
# ❌ Python FastAPI: 全エンドポイント計装
@app.get("/health")
async def health():
# このスパンも DataDog に送信される
return {"status": "ok"}
月コスト: $8,500(APM)
Good — フィルタ + サンプリング設計
# otel-collector-config.yaml
processors:
# ✅ 低価値スパンを上流で除外
filter/drop_health:
traces:
span:
- 'attributes["http.target"] == "/health"'
- 'attributes["http.target"] == "/metrics"'
- 'IsMatch(attributes["http.target"], "/static/.*")'
# ✅ 正常トランザクションは20%サンプリング
probabilistic_sampler:
hash_seed: 22
sampling_percentage: 20
service:
pipelines:
traces:
receivers: [otlp]
processors: [filter/drop_health, probabilistic_sampler, batch]
exporters: [datadog]
# ✅ エラーは100%保持(DataDog側でエラートレース優先)
# DD_APM_IGNORE_RESOURCES="/health,/metrics,/static/*"
月コスト: $714(92%削減)
設計のポイント: エラートレースは
probabilistic_sampler でも100%保持される(DataDog Agent がエラースパンを優先的にインデックス化する)。正常フローのみ間引く構成が最適解。
模範解答: ログ最適化(Bad → Good)
Bad — 全ログ無条件取り込み
# ❌ DataDog Agent: INFOログも全収集
logs_config:
container_collect_all: true
# ← ログレベルフィルタなし
# ❌ Terraform: 除外フィルタなし
resource "datadog_logs_index" "main" {
name = "main"
# exclusion_filter なし → 全ログ保存
retention_days = 30 # 全ログ30日保存
}
# 結果: 500GB/月 × 30日保存 = $1,800/月
月コスト: $1,800(ログ)
Good — OTel + Terraform でフィルタ管理
# ✅ OTel Collector: WARNING未満をDROP
processors:
filter/log_level:
logs:
log_record:
- 'severity_number < SEVERITY_NUMBER_WARN'
service:
pipelines:
logs:
receivers: [otlp]
processors: [filter/log_level, batch]
exporters: [datadog]
# ✅ Terraform: Exclusion Filter + 保存期間短縮
resource "datadog_logs_index" "main" {
name = "main"
exclusion_filter {
name = "drop_info_debug"
is_enabled = true
filter {
query = "status:(info OR debug)"
sample_rate = 1.0 # 100%除外
}
}
retention_days = 7 # 30日→7日
}
# ✅ GCS: WARNINGログを別途アーカイブ
# (障害調査用に90日保存 @ $0.004/GB)
月コスト: $33(98%削減)
フェーズ別コスト推移
各要素の削減施策詳細
A. APM インデックス削減($3,300 → $275 ※割引後換算)
施策: OTel Collector の filterprocessor でヘルスチェック除外 + probabilistic_sampler 20% + エラー100%保持
# otel-collector-config.yaml(関連部分)
processors:
filter/drop_health:
traces:
span:
- 'attributes["http.target"] == "/health"'
- 'attributes["http.target"] == "/metrics"'
- 'IsMatch(attributes["http.target"], "/static/.*")'
- 'IsMatch(attributes["http.target"], "/favicon.*")'
probabilistic_sampler:
hash_seed: 22
sampling_percentage: 20 # ← 正常フロー20%サンプリング(エラーは自動的に100%保持)
service:
pipelines:
traces:
receivers: [otlp]
processors: [filter/drop_health, probabilistic_sampler, batch]
exporters: [datadog]
【試算】
ヘルスチェック除外後: 50億 × 40% = 20億スパン
サンプリング20%: 4億スパン
エラー(1%)は100%保持: 0.2億スパン
合計: 4.2億スパン × $1.70/100万 = $714(割引前)
割引後(45%): ≈ $392
削減額: 約$2,908/月(削減率88%)
B. Custom Metrics 削減($155 → $46 ※割引後換算)
施策: OpenTelemetry 計装でビジネス分析に不要なタグ(host/region/pod_name)を削除し、カーディナリティを 1/3 に圧縮
# Python FastAPI + OTel: タグの絞り込み
from opentelemetry import metrics
meter = metrics.get_meter(__name__)
request_counter = meter.create_counter(
"http.requests.total",
description="Total HTTP requests by service and status",
)
async def track_request(method: str, status_code: int) -> None:
# ❌ NG: カーディナリティ爆発(host × region × pod × path で数万組み合わせ)
# request_counter.add(1, {"method": method, "host": socket.gethostname(),
# "region": "asia-northeast1", "pod": os.environ["POD_NAME"],
# "path": path})
# ✅ OK: ビジネス分析に必要な最小タグのみ
request_counter.add(1, {
"method": method, # GET / POST
"status_code": str(status_code), # 200 / 4xx / 5xx
"service": "mops-api", # サービス識別
})
C. ログ管理削減($697 → $13 ※割引後換算)
施策: OTel Collector filterprocessor で WARN 未満を DROP + DataDog Exclusion Filter + 保存期間7日に短縮
# Terraform: DataDog Logs Index with Exclusion Filter
resource "datadog_logs_index" "main" {
name = "main"
exclusion_filter {
name = "drop_info_debug"
is_enabled = true
filter {
query = "status:(info OR debug)"
sample_rate = 1.0 # 100%除外(ゼロ保存)
}
}
retention_days = 7 # 30日 → 7日(WARNINGのみ)
}
# GCS: 長期アーカイブ(障害調査用)
resource "google_storage_bucket" "dd_log_archive" {
name = "mops-dd-log-archive"
location = "asia-northeast1"
lifecycle_rule {
condition { age = 90 }
action { type = "Delete" }
}
}
D. Synthetic Tests 削減($232 → $81 ※割引後換算)
施策: 重要50テストは5分間隔を維持、低頻度150テストは60分間隔へ変更
# Terraform: Synthetic Tests 頻度最適化
variable "critical_endpoints" {
description = "決済・在庫・注文など障害影響が大きい50エンドポイント"
type = set(string)
}
variable "low_freq_endpoints" {
description = "商品一覧・静的ページなど変更頻度の低い150エンドポイント"
type = set(string)
}
# 重要API: 5分(300秒)間隔 = 12回/時間を維持
resource "datadog_synthetics_test" "critical_api" {
for_each = var.critical_endpoints
type = "api"
subtype = "http"
options_list {
tick_every = 300 # ← 5分
}
}
# 低頻度API: 60分(3600秒)間隔 = 1回/時間に削減
resource "datadog_synthetics_test" "low_freq_api" {
for_each = var.low_freq_endpoints
type = "api"
subtype = "http"
options_list {
tick_every = 3600 # ← 60分(元の12分の1)
}
}
ROI・ペイバック計算
コストサマリー
| 要素 | 現状(割引後) | 改善後 | 削減額/月 | 削減率 |
|---|---|---|---|---|
| APM | $3,300 | $275 | $3,025 | 92% |
| Custom Metrics | $155 | $46 | $109 | 70% |
| ログ | $697 | $13 | $684 | 98% |
| Synthetic | $232 | $81 | $151 | 65% |
| 合計 | $4,384 | $415 | $3,969 | 91% |
目標達成: Phase1完了時点で $6,200 → ≈$3,615(▲42%)→ $3,500 目標クリア
ROI計算
【移行コスト】
8人日 × 8時間 × 6,000円 = 384,000円(≈ $2,560)
【月間削減額】
目標: $6,200 - $3,500 = $2,700/月
日本円: $2,700 × 150円 = 405,000円/月
【ペイバック期間】
384,000円 ÷ 405,000円 ≈ 0.95ヶ月 ≈ 約1ヶ月
【初年度ROI】
年間削減額: 405,000円 × 12 = 4,860,000円
ROI = (4,860,000 − 384,000) ÷ 384,000 × 100 ≈ 1,165%
実装フェーズ計画
Phase 1(Week 1-2): APM フィルタ + サンプリング
担当: エンジニア2名(3人日)
期待削減: ≈$3,025/月(割引前)→ 目標44%削減をこの時点でクリア
期待削減: ≈$3,025/月(割引前)→ 目標44%削減をこの時点でクリア
- OTel Collector configmap に
filter/drop_healthとprobabilistic_sampler追加 DD_APM_IGNORE_RESOURCESを Kubernetes Secret/ConfigMap 経由で設定- 変更後24〜48時間: DataDog Usage ダッシュボードでスパン数の推移を確認
Phase 2(Week 3): ログ最適化
担当: エンジニア1名(2人日)
期待追加削減: ≈$684/月
前提条件: GCS アーカイブ設定を先に完了させること
期待追加削減: ≈$684/月
前提条件: GCS アーカイブ設定を先に完了させること
- GCS バケット + DataDog Log Archive の Terraform 設定
- OTel Collector に
filter/log_levelを追加(WARNING未満DROP) - DataDog Exclusion Filter を Terraform 管理化
- 保存期間: 30日 → 7日
Phase 3(Week 4): Custom Metrics + Synthetic 最適化
担当: エンジニア2名(3人日)
期待追加削減: ≈$260/月
期待追加削減: ≈$260/月
datadog-ci metrics --allで高カーディナリティメトリクスを洗い出し- Python OTel 計装からビジネス不要タグを削除(コードレビュー必須)
- Terraform で Synthetic
tick_everyを150テスト分変更(PRレビュー推奨)
ポイント解説
1
APM の課金構造: Indexed Spans が全て
DataDog APM は「Indexed Spans(保存したスパン数)× 単価」で課金される。ヘルスチェックのような高頻度・低価値スパンは除外が最優先。サンプリングはエラーを100%保持しつつ正常を間引くのが鉄則で、障害検知精度を落とさずにコストを削減できる。
DataDog APM は「Indexed Spans(保存したスパン数)× 単価」で課金される。ヘルスチェックのような高頻度・低価値スパンは除外が最優先。サンプリングはエラーを100%保持しつつ正常を間引くのが鉄則で、障害検知精度を落とさずにコストを削減できる。
2
Custom Metrics のカーディナリティ爆発は設計時点で防ぐ
DataDog の Custom Metrics は「メトリクス名 × タグの組み合わせ数(カーディナリティ)」が課金単位。
DataDog の Custom Metrics は「メトリクス名 × タグの組み合わせ数(カーディナリティ)」が課金単位。
pod_name(数十〜数百)× host(数十)× region(数個)のように積み上がると数万になる。OTel のメトリクス計装レビュー時に「このタグはビジネス分析に必要か?」を問う文化が重要。
3
ログは「取り込まない」が最高のコスト削減、ただし代替保存を忘れずに
DataDog ログコストは「取り込み量 × 保存期間」。OTel Collector で上流から捨てることで、DataDog への転送コスト・課金を同時にゼロにできる。ただし障害調査用に GCS 等への別途アーカイブ設定が必須。「安くしたら本番障害を調査できなくなった」は最悪のシナリオ。
DataDog ログコストは「取り込み量 × 保存期間」。OTel Collector で上流から捨てることで、DataDog への転送コスト・課金を同時にゼロにできる。ただし障害調査用に GCS 等への別途アーカイブ設定が必須。「安くしたら本番障害を調査できなくなった」は最悪のシナリオ。
今日のまとめ
DataDog コスト削減の核心は「取り込む前に捨てる(OTel filterprocessor)」と「重要度で頻度を分ける(サンプリング・Synthetic 頻度最適化)」の2点。APM スパンの88%削減だけでペイバック約1ヶ月・初年度ROI 1,165%という圧倒的な費用対効果を実現できる。
シニアエンジニアとして重要なのは「可観測性コストを管理する」視点。監視ツールは「全部入れる」と際限なく膨張する。計装設計時点から「このシグナルはビジネス判断に使えるか?」を問う習慣が、中長期的なコスト健全性を保つ。
シニアエンジニアとして重要なのは「可観測性コストを管理する」視点。監視ツールは「全部入れる」と際限なく膨張する。計装設計時点から「このシグナルはビジネス判断に使えるか?」を問う習慣が、中長期的なコスト健全性を保つ。