カーディナリティ予算とラベル設計の規律

カーディナリティ予算という考え方

監視基盤の運用コストは、突き詰めれば アクティブな時系列（time series）の本数 にほぼ比例します。にもかかわらず、時系列はメトリクスを出す側が自由にラベルを足すたびに増えるため、放置すれば青天井です。そこで先に 「この基盤が抱えてよい時系列の総数」を上限として決め、各メトリクス／各チームにその枠を配分する 運用が カーディナリティ予算（cardinality budget） です。

予算は抽象論ではなく具体的な数字です。たとえば「1ノードあたりアクティブ系列数 200万まで」「1メトリクスあたり10万系列まで」のように上限を置き、超えたら設計をやり直す。基数爆発の機構そのものは /devops/metrics-cardinality/ に譲り、本稿は その上限をどう決め、ラベル設計でどう守るか に集中します。

時系列数の見積もり：直積で上限を計算する

1本のメトリクスが生む時系列数は、付与するラベルそれぞれの値域（取りうる値の種類数）の 直積（デカルト積） で決まります。設計時点でこの掛け算を必ず試算します。

時系列数 = メトリクス数 × ラベルAの値域 × ラベルBの値域 × …

たとえば http_requests_total に method（5種）・status（8種）・route（120種）を付け、それを300インスタンスで動かすと、

5 × 8 × 120 × 300 = 1,440,000 系列

このメトリクス1本で既に144万系列です。ここに route のテンプレート化を怠って生URLを入れたり、user_id を1本足したりすると、直積の項が1つ増えるだけで桁が変わります。ラベルの追加は加算ではなく乗算 なので、見積もりは常に最悪ケース（各ラベル値域の積）で行うのが鉄則です。

禁止すべき高基数次元

予算を守る第一歩は、値域が事実上無限の属性をラベルにしない ことです。これらは単独で予算を食い尽くすため、原則として禁止ラベルとして扱います。

判定基準は単純です。「その属性で系列を区別したいか、それとも個別の事例を追跡したいだけか」 を問う。前者（集計軸）ならラベル、後者（追跡）なら高基数情報はラベルではなく構造化ログやトレース側に載せます。個別事例を追う情報の置き場所については /devops/structured-logging-wide-events/ と /devops/distributed-tracing/ を参照してください。

ラベル選定の規律

予算内に収めるラベルの選び方には、いくつかの明確な基準があります。

• 集計軸として実際にクエリで使うか：ダッシュボードやアラートの by() / without() に現れない次元は載せない。「表示しないラベル」は純粋なコストです。
• 値域が有限かつ安定か：取りうる値が事前に列挙でき、運用中に増え続けないこと。status や method は安定、pod_name は不安定（チャーンで増える）。
• 直交する次元か：region と availability_zone のように一方が他方を含意する場合、両方を独立ラベルにすると無駄な直積が生まれる。冗長な次元は片方に寄せる。
• 値が運用者の制御下にあるか：外部入力（ユーザー指定の文字列など）をそのままラベルにしない。攻撃者が任意のラベル値を注入すれば、意図的な基数爆発（カーディナリティDoS）が成立します。

これらを満たさない属性は、ラベルではなくメトリクス値そのもの（カウントやヒストグラム）か、ログ・トレースのフィールドに移します。

予算管理の実装：ドロップ・keep・リラベリング

設計で抑えきれない、あるいは送信側が勝手に高基数ラベルを付けてくる場合に備え、取り込みパイプラインで予算を強制 します。Prometheus なら metric_relabel_configs が最後の防衛線です。

metric_relabel_configs:
  # 1) 高基数ラベルを削除（値は捨てるが系列は名前で残る）
  - regex: "user_id|session_id|request_id"
    action: labeldrop
  # 2) 不要な系列ごと捨てる（特定メトリクスを取り込まない）
  - source_labels: [__name__]
    regex: "go_gc_.*"
    action: drop
  # 3) 必要なものだけ keep（許可リスト方式）
  - source_labels: [__name__]
    regex: "http_.*|app_.*"
    action: keep

ここで重要なのは labeldrop と drop の違いです。labeldrop はラベルを消すことで複数系列を1本に畳む（直積の項を減らす）。一方 drop は系列そのものを取り込まない。前者は基数を下げ、後者は不要メトリクスを丸ごと止めます。許可リスト（keep）方式にすると、新しいメトリクスはデフォルトで入らないため、予算が無断で侵食されません。

事前集約とコストの内訳

予算を恒常的に下げるもう一段が recording rule（事前集約） です。高基数の生メトリクスは短い保持期間に留め、ダッシュボードは集約済みの低基数メトリクスを参照させます。

# 生メトリクス（高基数）から、集約軸だけ残した低基数系列を事前生成
record: route:http_requests:rate5m
expr:   sum by (route, status) (rate(http_requests_total[5m]))

sum by (route, status) で instance や method の直積を畳むため、結果系列数が激減し、クエリのたびに巨大な生系列を走査する必要もなくなります。なぜこれがコストに効くかは、時系列数が 3つのコストに線形に乗る からです。

時系列数を予算内に保つことは、この3コストを同時に抑えることに等しい。だからこそ「あとで効率化」ではなく、ラベルを足す瞬間に直積を試算して予算と照合する 規律が必要になります。アラート評価が予算超過で遅延する具体的な影響は /devops/alerting-theory/、基盤全体の容量配分は /devops/capacity-planning/ と併せて設計します。

まとめ

• カーディナリティ予算は 「抱えてよい時系列の総数」を上限として先に決め、各メトリクスへ配分する 運用。ラベルは予算という制約下の設計対象である。
• 時系列数は 各ラベル値域の直積 で決まる。ラベル追加は乗算的に効くため、見積もりは常に最悪ケースの積で行う。
• user_id・request_id・生URL・email など 値域が無限に近い次元はラベル禁止。集計軸に使う有限・安定・直交・制御下の属性だけをラベルにする。
• 予算強制は 入口の labeldrop／drop／keep で、恒常削減は recording rule の事前集約 で行う。時系列数はメモリ・索引・クエリに線形に乗るため、これを抑えることが直接コストを抑える。