メトリクスのカーディナリティとは? 時系列の爆発を解説

メトリクスにおけるカーディナリティとは、メトリクスが生成する個別の時系列の数であり、ラベル値の一意な組み合わせがいくつ存在するかによって決まります。

カーディナリティは、メトリクスシステムを最も頻繁に破綻させる概念であり、初心者が最も予期しないものです。メトリクスに付与されたラベルの一意な組み合わせごとに、保存とクエリのための別々の時系列が作られます。誤ったラベルを追加すると、その数は数百から数百万へと爆発し、深刻なコストとパフォーマンスの問題を招きます。

カーディナリティの意味

ラベル付きのメトリクスは、ラベル値の一意な組み合わせごとに1つの時系列を生成します。method と status code でラベル付けされたリクエスト数メトリクスで、それぞれの値が少数であれば、数十の時系列になるでしょう。カーディナリティとは、単にその個別の時系列の総数であり、ラベルの次元が増えるごとに乗算的に増加します。

どのように爆発するか

問題は種類の多いラベルから生じます。user ID、request ID、または生のURLをラベルとして追加すると、一意な値ごとに独自の時系列が作られます。100万通りの値を持つラベルは、時系列の数を100万倍にします。これがメトリクスのバックエンドを圧倒するカーディナリティの爆発です。

高カーディナリティがコスト高になる理由

各時系列はメモリとストレージを消費し、インデックス化される必要があります。カーディナリティが増えるにつれて、取り込みが遅くなり、クエリのコストが上がり、監視システム自体がダウンすることもあります。高カーディナリティは、メトリクスシステムが遅く、信頼できず、または費用的に成り立たなくなる主な原因です。

カーディナリティの制御

肝心なのはラベルの種類を少なく保つことです。status code や region のように上限があり列挙可能な値を使い、上限のない識別子をメトリクスのラベルに決して入れないことです。本当にエンティティ単位の詳細が必要な場合、それはメトリクスではなく、ログや高カーディナリティに適したイベントツールに属します。

CI/CDメトリクスにおけるカーディナリティ

同じ落とし穴がpipelineのメトリクスにも当てはまります。build メトリクスを repository、workflow、runner の種類といった安定した次元でラベル付けするのは問題ありません。しかし commit SHA や run ID でラベル付けすると、buildごとに新しい時系列が作られ、カーディナリティが爆発します。pipelineメトリクスのラベルは上限のあるものに保ち、一意な識別子はログに送りましょう。

重要なポイント

カーディナリティとは、ラベルの組み合わせから生じる一意な時系列の数です。
IDのような上限のないラベルはカーディナリティの爆発を引き起こします。
高カーディナリティはコストを押し上げ、メトリクスシステムを劣化させます。
ラベルは種類を少なく保ち、一意なIDはメトリクスではなくログに入れます。