会計/ファイナンス・コスト効率 — DataDog 可観測性コスト 44%削減設計

2026-05-22 (Day 47) 金曜 E: ファイナンス/コスト ★★★☆☆ DataDog APM / OTel Collector / Synthetic / Custom Metrics $6,200 → $3,500 以下

概要

🔍

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 Metrics8,000メトリクス @ $0.05/メトリクス$400
ログ管理(取り込み+保存)500GB/月、30日保存$1,800
Synthetic Tests200テスト × 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円
期待する回答形式: 数値計算 + 施策提案(設定例・フェーズ計画含む)

ヒント(段階的開示)

ヒント1 — 方向性
DataDog の課金は「インデックス件数 × 単価」構造。削減するには フィルタリング(取り込まない)サンプリング率の調整 が王道。APM スパン($8,500 = 全体の75%)から着手すること。
ヒント2 — 各要素のアプローチ
  • APM: DD_APM_IGNORE_RESOURCES でヘルスチェック除外 → サンプリング率20%(エラーは100%)
  • Custom Metrics: host/region/pod_name タグを削除してカーディナリティを 1/3 に
  • ログ: OTel Collector の filterprocessorseverity_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%削減)

フェーズ別コスト推移

DataDog 月次コスト推移(USD) 0 3,000 4,500 6,200 目標: $3,500 $6,200 現状 APM $3,300 Log $697 SYN $232 M $155 $3,615 Phase1後 APM削減 ▲42% $2,951 Phase2後 ▲52% ✓目標達成 $2,531 Phase3後 ▲59%

各要素の削減施策詳細

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,02592%
Custom Metrics$155$46$10970%
ログ$697$13$68498%
Synthetic$232$81$15165%
合計$4,384$415$3,96991%
目標達成: 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%
ペイバック分析: 累積コスト vs 累積削減額(万円) 0 1ヶ月 2ヶ月 3ヶ月 6ヶ月 12ヶ月 投資: 38.4万円 累積削減額(40.5万円/月) ペイバック ≈1ヶ月

実装フェーズ計画

Phase 1(Week 1-2): APM フィルタ + サンプリング

担当: エンジニア2名(3人日)
期待削減: ≈$3,025/月(割引前)→ 目標44%削減をこの時点でクリア
  • OTel Collector configmap に filter/drop_healthprobabilistic_sampler 追加
  • DD_APM_IGNORE_RESOURCES を Kubernetes Secret/ConfigMap 経由で設定
  • 変更後24〜48時間: DataDog Usage ダッシュボードでスパン数の推移を確認

Phase 2(Week 3): ログ最適化

担当: エンジニア1名(2人日)
期待追加削減: ≈$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/月
  • datadog-ci metrics --all で高カーディナリティメトリクスを洗い出し
  • Python OTel 計装からビジネス不要タグを削除(コードレビュー必須)
  • Terraform で Synthetic tick_every を150テスト分変更(PRレビュー推奨)

ポイント解説

1 APM の課金構造: Indexed Spans が全て
DataDog APM は「Indexed Spans(保存したスパン数)× 単価」で課金される。ヘルスチェックのような高頻度・低価値スパンは除外が最優先。サンプリングはエラーを100%保持しつつ正常を間引くのが鉄則で、障害検知精度を落とさずにコストを削減できる。
2 Custom Metrics のカーディナリティ爆発は設計時点で防ぐ
DataDog の Custom Metrics は「メトリクス名 × タグの組み合わせ数(カーディナリティ)」が課金単位。pod_name(数十〜数百)× host(数十)× region(数個)のように積み上がると数万になる。OTel のメトリクス計装レビュー時に「このタグはビジネス分析に必要か?」を問う文化が重要。
3 ログは「取り込まない」が最高のコスト削減、ただし代替保存を忘れずに
DataDog ログコストは「取り込み量 × 保存期間」。OTel Collector で上流から捨てることで、DataDog への転送コスト・課金を同時にゼロにできる。ただし障害調査用に GCS 等への別途アーカイブ設定が必須。「安くしたら本番障害を調査できなくなった」は最悪のシナリオ。

今日のまとめ

DataDog コスト削減の核心は「取り込む前に捨てる(OTel filterprocessor)」と「重要度で頻度を分ける(サンプリング・Synthetic 頻度最適化)」の2点。APM スパンの88%削減だけでペイバック約1ヶ月・初年度ROI 1,165%という圧倒的な費用対効果を実現できる。

シニアエンジニアとして重要なのは「可観測性コストを管理する」視点。監視ツールは「全部入れる」と際限なく膨張する。計装設計時点から「このシグナルはビジネス判断に使えるか?」を問う習慣が、中長期的なコスト健全性を保つ。

自己評価

自分の回答

気づき・メモ