今さら聞けないカーディナリティ

はじめに

オブザーバビリティを本格的に実現しようとすると、カーディナリティという言葉をよく耳にします。本ブログではカーディナリティとは何か？それがなぜオブザーバビリティの世界では大切な要素（時に課題）となるのか、について、できる限りわかりやすく解説していこうと思います。

カーディナリティとは？

カーディナリティとは、特定のデータセットやフィールドにおけるユニークな値の数を指します。データベース定義の世界で言い換えると、ユニークキーとその組み合わせになります。

ちょっとよく分からないと思いますので、とある小学校のテストの成績を管理・分析する場合を例に説明していきます。まず、どのようなデータが必要になるでしょうか？少なくともこのブログを読んでいる方はIT技術者の方が多いかと思いますので、以下のようなデータ構造になるな、というのは想像しやすいと思います。

データ構造例

• 学校ID(学校名)
• 学年
• クラス
• 生徒ID(氏名)
• 教科
• 得点　など

カーディナリティとは、この各属性の組み合わせが多いか少ないか、を意味します。この例ですと、とある学校での成績を管理したいだけなので、学校ID(学校名)は全て同じ値になります。学年も小学校なので1年から6年までの6パターンになります。クラスも、学校の規模にもよりますが、せいぜい5−10クラスくらいでしょう。教科なども同様です。つまりこれらの属性は、カーディナリティが低いということになります。一方で生徒IDはどうでしょう。1人1人異なるID氏名になりますので、全生徒分のパターンが存在します。全校生徒が300人いれば300パターンとなり、カーディナリティが高いということになります。

カーディナリティがなぜ重要なのか？

上記の例だと、要件は「とある学校におけるテストの成績を管理・分析する」でした。そしてどのようなデータを集めるべきかは、想像しうる要件をなんとなく抽出してデータ構造を定義してみました。ですが、要件が「学校全体の平均点を管理する」だけであればデータ構造は変わりますよね。つまり、事前に要件がしっかりと定義され、変動が少ないような状況であればそれに最適なデータを収集すれば良いはずです。しかし、様々なステークホルダがいる中でどのような要件になり得るかはやってみないとわからないですし、有効な対策を実施するための根拠を得るには多角的な分析が必須になります。私は、おそらく以下のような分析は必要だと考えたので上記のようなデータ構造としました。

• 学年毎の平均、最高、最低点
• クラス別の平均、最高、最低点
• 教科毎の平均、最高、最低点
• 個人毎の平均、最高、最低点　など

カーディナリティがデータ量に直結する理由

様々な角度で分析するためには、その分細かい粒度のデータが必要になり、集めたデータを集計して分析することができるようになります。この例だと、学校全体の平均を求めるだけであれば、学校IDと平均得点の1件のデータがあれば求めることができます。しかしながら、全校生徒300人の様々な分析を行うためには、例えば5教科あれば300人×5教科分の点数(1,500件のデータ)を記録してあげる必要があります。他校のデータも掛け合わせたり生徒の人数や教科が増えればその分データが増えていきますし、これら以外に分析したい属性が増えたり、個人の成績の推移や傾向を分析するために過去の成績も必要となると、指数関数的に記録すべきデータが増えていくことは想像に難くありません。

話をITシステムにおけるオブザーバビリティに戻して考える

多角的な分析を行うためには、カーディナリティの高いデータが必要であること、故に大量のデータが必要になるということがわかったところで、話をITシステムに戻します。昨今のシステムは、クラウド、マイクロサービスが当たり前になり、その障害ポイントも非常に多様化しています。つまりどこで何がいつ起こるか分からず、それがどの程度の影響を与えるかも分析することは困難を極めます。だからこそ、できる限り細かい粒度のデータを集め続け、いつでも分析ができるようにしておくことが大切になるのです。

　ここまでが理解できたら、ぜひこちらのブログも読んでみてください。カーディナリティとデータ量の関係を理解しながら実際のユースケースを想像できるようになると思います。

カーディナリティを調節してコストとのバランスを整える

とはいえ、何でもかんでもデータを送ってコスト爆発を起こしてしまっては意味がありません。New Relicは毎月送信したデータ量で課金されますので、送った量だけ課金されてしまいます。必要以上に高カーディナリティなデータを送っていないかを分析して、データ量を調節していきましょう。

Cardinality Managementのご紹介

New Relicでは、Administration > Cardinality Managementから、カーディナリティ管理機能にアクセスすることができます。ここでは、New Relicが管理できる最大のカーディナリティ制限*に抵触していないかと、実際にカーディナリティが高いデータをドリルダウンして分析することができます。これにより、送ったデータが意図せず高カーディナリティになっていないか、そもそも送る必要のない属性が含まれていることによって高カーディナリティになってしまっていないかを確認することができます。

* 制限の詳細はこちらを参照してください

以下の画面では、どのメトリクスがカーディナリティが高くなっているのかを確認することができます。

該当メトリクスをクリックすると、そのメトリクス内の属性毎のカーディナリティまで分析することができます。

Prometheusを使っている場合には特に気をつけよう

特にKubernetesを使ったシステムの場合、テレメトリーデータの収集にPrometheusを使っている場合が多いと思います。Prometheusは簡単にデータを収集できる仕組みではありますが、非常に高カーディナリティになり、データ量が爆増しがちです。上記のCardinality Managementを確認することはもちろん、こちらのブログもお読みいただき、そもそもPrometheus側で必要以上のデータを送っていないか確認してみましょう。

まとめ

いかがでしたか？本ポストでは、オブザーバビリティを実現していこうとするとよく遭遇するカーディナリティにフォーカスして、具体的な例を用いて詳細を解説しました。特に筆者は、「カーディナリティがなぜデータ量に影響するのかがわからない」という質問を受けることがよくあります。このブログを読んでその疑問が解消されれば嬉しいなと思っております。

カーディナリティとうまく付き合って適切なコストで効率の良いオブザーバビリティを実現していきましょう。