Datadog Metrics Without Limitsの真髄：カーディナリティ爆発を制し、コストとオブザーバビリティを両立させる裏技
テックリードの君なら、月末に送られてくるDatadogの請求書を見て冷や汗をかいた経験が一度や二度ではないはずだ。
「おい、誰だこのカスタムメトリクスをぶち込んだのは……！」
KubernetesのPod ID、ユーザーID、動的なリクエストパス、果てにはクライアントのIPアドレスまでタグに詰め込み、高カーディナリティ（High Cardinality）のメトリクス爆発を引き起こす。結果として、インデックス数（Custom Metrics）は天井知らずに跳ね上がり、財務部門から「クラウド費用の監査が入る」と呼び出される。
慌ててコードに戻り、メトリクスの送信処理を修正し、不要なタグを削ぎ落とし、再デプロイの海を泳ぐ。――だが、ちょっと待ってほしい。
「タグを自由に変更したいからこそ、とりあえず細かく送っておきたい」という開発チームの欲求と、「コストを抑えたい」というマネジメントの要求は、本当に両立不可能なのだろうか？
そのパラドックスを鮮やかに粉砕するのが、Datadogの Metrics Without Limits（MWL） だ。
今回は、この機能を単なる「コストカットツール」としてではなく、開発スピードを落とさずにオブザーバビリティを極限まで高めるための戦略兵器として使い倒すための実践ノウハウを伝授する。
—
1. 高カーディナリティという名の「時限爆弾」とDatadogの経済学
まず、敵を知ろう。なぜカスタムメトリクスはこれほどまでにコストを圧迫するのか。
Datadogの課金モデルの根幹には「インデックス化されたカスタムメトリクスの数」がある。メトリクス名（例: `http.server.requests`）だけでなく、それに付与されるタグの組み合わせ（カーディナリティ）が爆発すると、Datadog側で生成される時系列データのポイント数が幾何級数的に増加する。
従来の絶望的なワークフロー
1. 開発者A: 「このAPIのレイテナシー、ユーザーごとの傾向も見たいから `user_id` タグを入れよう」
2. コード実装: `statsd.increment(“api.latency”, tags=[f”user_id:{user.id}”, f”path:{req.path}”])`
3. 爆発: アクティブユーザーが10万人いれば、1つのメトリクス名から10万個のユニークな時系列データが生まれ、一瞬で予算を食いつぶす。
4. 対策（悪夢）: 「ごめん、コストヤバいから `user_id` タグ消して再デプロイして」
この「タグ変更のたびにコード修正とデプロイが発生する」という構造こそが、開発スピードを殺し、エンジニアの心理的安全性を奪う元凶なのだ。
—
2. Metrics Without Limits（MWL）のアーキテクチャと核心
Metrics Without Limitsは、この構造を根本からひっくり返す。
従来モデルでは、エージェントやクライアントライブラリが送信した瞬間にタグの組み合わせが確定し、インデックスされてしまっていた。しかしMWLのアーキテクチャでは、「パイプラインの途中でタグのフィルタリングや集約を動的にコントロールする」。
[Application / StatsD]
│
▼ (全タグ付きで送信：カーディナリティを恐れない)
[Datadog Ingestion Pipeline]
│
├── [Metrics Without Limits (MWL)] ──> ここでタグの除外・集約を適用！
│ (コード変更・再デプロイ不要)
▼
[Indexed Custom Metrics] (コスト最適化＆必要な粒度のみ保持)
MWLがもたらすパラダイムシフト
- 送信側は「全部盛り」でいい: アプリケーション側では、将来必要になるかもしれない高カーディナリティなタグを躊躇なく付与して送信する。
- 受信側（Datadog UI）でコントロール: Datadogの画面上（あるいはAPI）で、「どのタグをインデックスし、どのタグをドロップ（あるいはエイリアス化）するか」を後から自由に定義できる。
- コストのコントロール: 不要な高カーディナリティタグをインデックス対象外に指定することで、メトリクス数を激減させ、コストをコントロール下に置きながら、ログやAPMとの相関分析には元のデータを活かす道を残せる。
—
3. チームの生産性を最大化する設定・運用ノウハウ
ここからが実践だ。MWLをチーム開発に組み込み、開発スピードとコスト最適化を両立させるための具体的なワークフローと設定術を公開する。
A. 開発を加速するキーボードショートカット & UIハック
DatadogのUIでMetrics Without Limitsの設定画面を素早く開くためのショートカットを体に叩き込んでおけ。
- Command + K (Mac) / Ctrl + K (Windows): グローバルサーチを開く。
- `MWL` と打ち込むか、Metrics > Summary へ直行する。
- メトリクス名をクリックし、“Configure Tags” または “Manage Tags” セクションを開く。ここがすべてのコントロールハブだ。
B. 絶対入れるべき神インテグレーション・設定
MWLを真に活かすためには、アプリケーション側の設定（DogStatsDなど）で「構造化されたタグ付け」を徹底する必要がある。以下のベストプラクティス構成を守れ。
Datadog Agent設定 (`datadog.yaml`) のベストプラクティス
エージェント側で無駄なメトリクスを拾わないためのフィルタリング設定の例だ。
/etc/datadog-agent/datadog.yaml
グローバルなタグの付与（環境、チーム名など静的なものに限定する）
tags:
- env: production
- region: ap-northeast-1
- team: core-platform
DogStatsDを通じたカスタムメトリクスの受信設定
dogstatsd_non_local_traffic: true
dogstatsd_port: 8125
メトリクスのマッピングやドロップのルール（必要に応じてエージェント側でも制御）
ただし、細かなタグの制御はMWL（クラウド側）に任せるのがモダンなアプローチ
TerraformによるMWLのコード管理（IaC化）
チーム開発において、DatadogのUIポチポチ設定は「暗黙知」を生み、障害の元となる。Metrics Without Limitsの設定は、必ずTerraformなどのIaCでコード化して共有せよ。
以下は、特定の高カーディナリティタグ（例: `client_ip`）をインデックスから除外しつつ、メトリクス自体はキャプチャし続けるためのTerraformコードのベストプラクティスだ。
terraform {
required_providers {
datadog = {
source = “DataDog/datadog”
version = “~> 3.0”
}
}
}
provider “datadog” {
api_key = var.datadog_api_key
app_key = var.datadog_app_key
}
Metrics Without Limitsの設定管理
指定したメトリクスに対して、インデックスするタグを明示的にコントロールする
resource “datadog_metric_metadata” “api_latency_optimization” {
metric = “app.http.request.latency”
# 必要最低限のタグのみをインデックスに残し、
# 爆発の原因になる高カーディナリティタグ（client_ip, request_idなど）をインデックス対象外にする
# ※データ自体は送られ続けるため、後からのアドホックな調査やAPMでの追跡は可能
}
実際のMWLタグ管理は Datadogの Metric Configuration API / リソースを使用する
resource “datadog_metrics_preferences” “cost_control” {
# パーセンタイルやカスタムアグリゲーションの設定
# チーム間で「どのメトリクスにコスト上限を設けるか」をGit管理する
}
> 💡 プロの知見:
> Terraformで管理する際は、`datadog_metric_metadata` や関連するMetric Policiesを活用し、「どのメトリクスがチームの予算の何%を消費しているか」をCI/CDのパイプラインで警告できるようにしておくと、財務部門からの評価が爆発的に上がる。
—
4. 現場で使える「裏技的」運用ルール
最後に、チーム全体にこの仕組みを定着させ、二度とメトリクス爆発を起こさないための運用ルールを授ける。
1. 「送るな」ではなく「インデックスするな」を合言葉にする
開発者から「このタグ送っても大丈夫ですか？」と聞かれたら、「コード上は何を送ってもいい。ただし、MWLのインデックス対象にするタグは厳選しろ」と指導せよ。これにより、「タグを追加したいからPRを出してレビューを待つ」という開発のボトルネックが消滅する。
2. 週次で「Metric Summary」をレビューするアジアンスタンドアップ
毎週月曜の朝会で、DatadogのMetric Summaryを開き、「今週、最もインデックス数を増やした犯人（メトリクス）」を全員で確認する。MWLのおかげで、そこで高コストなタグが見つかっても、コードを直さずDatadog上の設定変更（あるいはTerraformの修正）だけで一瞬でコストを鎮火できる快感をチームで共有せよ。
3. APMとカスタムメトリクスの役割分担
「詳細なリクエストパスやユーザーごとのトレース」は、カスタムメトリクス（StatsD）ではなく、Datadog APM（Traces）に任せるべきだ。カスタムメトリクスはあくまで「マクロな状態監視とアラート」に特化させ、ミクロな原因究明はトレーシングの世界に逃がす。このアーキテクチャの棲み分けこそが、オブザーバビリティの神髄である。
—
さあ、今すぐブラウザで `Command + K` を押し、自社のダッシュボードに潜む「高カーディナリティの怪物」たちをMetrics Without Limitsで飼い慣らせ。
君のコードベースはより自由に、そして会社の財布はより安全になる。これぞ、真のオブザーバビリティ・エンジニアリングだ。