"カーディナリティの高いデータ"が問題の原因特定に必要な理由

カーディナリティが低いデータしかない？

大規模なマーケティングキャンペーンを実行したその日、ウェブサイトが遅くて商品をカートに入れられないというお客様の声がツイッターに流れていたとします。幸いなことに、運用チームは「504エラーが過剰に発生したときに検知して警告する」といった監視設定をしていました。しかし、問題の原因を調査しようとすると行き詰まってしまうことに気づきます。エラーを引き起こす可能性のある膨大な数の関連要因、必要な詳細情報が収集して確認できるデータに欠けているのです。障害対応を行うチームは単に一連のメトリクスを監視するだけでは不十分であることに気づき、頭を抱えます。つまり、カーディナリティの高いデータ (後述します) があらかじめ収集されていなければ、サイトに影響を与えている根本的な問題を特定し、影響を軽減するための方法に最速で取り組むことができないのです。

まずは“オブザーバビリティ (可観測性)” と”監視”の違いを理解

昨今多くの MSP やシステム関連の技術ベンダーは自らを単なる監視ツールのプロバイダーではなく、オブザーバビリティ・プロバイダーとして位置づけようとしています。ダッシュボードやアラートを使っていくつかの主要指標を監視、アラートを発砲することは、全体的なオブザーバビリティ戦略の一部であることは確かです。監視とは「何かが間違っているとき」にその状態を教えてくれます。監視を行うには「監視したい信号（既知の未知数）を事前に知っておく」必要があります。一方、オブザーバビリティとは、「なぜ」という疑問を収集したデータに対して問いかけることができること、既知ではない事象をその場で掘り下げることができる柔軟性を持っています。

• 監視：事前に理解している問題が発生した時に知らせてくれる
• オブザーバビリティ (可観測性) : 未知の事象が発生した時に、その理由を尋ね、原因を特定していくことができる

何千ものマイクロサービスの上に構築された複雑な分散システムが存在する今日では、すべての問題を予測することは不可能であり、複雑な問題を解決するためには、データに対してどんな質問でもできる柔軟性が必要です。

ところでカーディナリティってなんだ？

前述のように、重要なアグリゲートシグナル（例えばメトリクス）をモニタリングすることは、スタックを円滑に運用するための重要な要素の一つです。(データのタイプ、メトリクス、イベント、ログ、トレースの違いについてまず知りたい場合はこちらの MELT ってなんだ？を見てみてください。)そのため New Relic では、PrometheusやTelegrafなど、ほぼすべてのサードパーティ製監視ツールから、メトリクスをTelemetry Data Platformに送信できるようにしています。これらのメトリクスは、システムの全体的な健全性とパフォーマンスに関する重要なシグナルを提供します。しかし、これらの指標にはメリットとデメリットが存在します。しかしそのトレードオフの関係を話す前に、2つの重要な概念を理解しておきましょう。

• データ・ディメンション (Data Dimensions)：顧客」「製品」「店舗」「時間」など、例えばビジネスで関心のある項目に関する一連のデータ属性のこと。データディメンションとは、CustomerID、URL、地域、日付など、数値的な事実のことで、基本的にはkey:valueペアの「key」にあたります。
• カーディナリティ(Cardinality)：データ・ディメンション内のユニークな値の数の粒度を指す。例えば「地域」は一意というよりはおおよその状態を表しているためカーディナリティの低いデータといえ、「CustomerID」はそれぞれが一意のデータであるため、カーディナリティの高いデータである、といえます。

メトリクスタイプのデータに代表されるカーディティリティの低いデータには限界があります。メトリクスにはcount、sum、min、max、average、latestなどの機能がありますが、それぞれの関数名からもわかるように、これらのデータポイントは個々のイベントやサンプルのトランザクションに関する「要約データ」です。例えば、以下のようなものがあります。

• 1分間の最大CPU使用率
• 1時間あたりの平均トランザクション数
• 1秒あたりの504エラーの数

しかし504エラーの数を知るだけでは「なぜそのようなエラーが発生したのか?」はわかりません。この限界を克服するために、データにディメンションを追加することができます。ディメンションを追加することで、データのカーディナリティを高めることができます。つまりトラブルシューティングに役立つデータにしていくことができるというわけです。

カーディナリティを高めることを制限するもの

「カーディナリティが高い方がいいというのであれば、スタックすべてのトランザクションを記録し、それぞれのトランザクションには無限のキーとバリューのペアを付加し、エラーと根本的な原因を関連付けることができるようにすればいいのでは？」と思うのは当然です。しかし問題は、ほとんどの監視ツールがカーディナリティの高いデータに対応できないことがあげられます。カーディナリティが高くなると、データ量が増加し、このデータを迅速かつ効率的に処理するために大量の計算機とストレージが必要になります。残念なことに、ほとんどのツールはこのような要求に対応できるほど強力ではありません。驚くべきことに、ツールの中にはアドホックにデータを照会できないものもあります。

例えば、あるSaaSモニタリング・ベンダーはクエリ時に拡張できないため、データインジェストを行う際にファセットしたいデータを事前に特定しておく必要があります。このアーキテクチャでは、インジェスト・パイプラインが遅くなるだけでなく、アドホックにデータを照会する能力が完全に制限されます。上記の制限の結果、以下のいずれか、もしくは同時に複数の問題が発生します。

• 追加できるディメンションの数に大きな制限がある

• サンプリングまたはアグリゲートされたデータしかない

• 保存期間の短縮
• タグ数の厳しい制限を超えた場合の急激なコスト増加

要約すると、問題を特定する機能はあっても、根本的な原因を特定して修正するためのデータ粒度をもつことができない監視しかできないということです。

カーディナリティが高いデータが答えてくれること

カーディナリティの低いデータやそこに基づいた監視でも問題の検出には役立ちます。しかし、どの顧客（またはホスト、App ID、プロセス、SQL クエリ）が問題に相関しているかを理解するには、カーディナリティの高いデータが必要です。カーディナリティの高いデータは、根本的な原因を切り分けて特定するために必要な粒度と精度を提供し、問題が発生した場所と理由をピンポイントで特定することができます。オブザーバビリティ (可観測性) という言葉が業界用語として使われるようになるずっと前から、New Relicは、アプリケーションのトランザクションやブラウザのページビューなど、個別の詳細な記録をサポートするカーディナリティの高いデータに焦点を当ててきました。

例えば、顧客がウェブサイトで注文をすることを想像してみてください。New Relic Oneのデータモデルでは、1つのトランザクションごとに、ユーザーID、金額、買った商品の数、処理時間、その他の必要な属性を記録することができます。また、データを取り込む Telemetry Data Platform はスキーマレスなので、トランザクションに含めるべきすべての属性を事前に知る必要はありません。ビジネスが発展し、異なるパラメータを持つ新しいタイプのトランザクションが導入された場合でも、トランザクションにそれらを追加するだけです。このような粒度の高いデータにより、個々のトランザクションを調査することができ、カーディナリティの低いデータで集約されたメトリクスの機能を超えることができます。実際にさまざまな問題に直面するエンジニアチームは、以下のような情報粒度で質問をしていきたいのではないでしょうか。

• 今日の午前9時30分から10時30分までの間に504エラーが発生したすべてのユーザーを表示してください。
• そのユーザーはすべてのホストに分散していたのか、それとも一部のホストだけだったのか？
• どのようなサービスにアクセスしていたか？
• どのようなデータベースの呼び出しが行われていたか？
• 特定の製品を購入しようとしていたか？

未知の事象に問いかけるために

このような質問に高速に答えるために、私たちは世界で最もパワフルな Telemetry Data Platform を構築しました。このプラットフォームは、特にカーディナリティの高いデータを扱うように設計されています。Telemetry Data Platformは、マルチテナント型のクラウドサービスである大規模な分散システム上で動作し、クエリは何千ものCPUコアで同時に実行され、ペタバイト級のデータに含まれる何十億ものレコードを数秒で処理し、ミリ秒単位で回答を得ることができます。New Relic の SQL ライクなクエリ言語である NRQL (ヌルクル) は、データをリアルタイムで照会することができ、データに対してあらゆる質問をすることができます。また、測定値、イベント、ログ、トレースなど、すべての遠隔測定データを統一されたプラットフォームに統合することで、テクノロジースタック全体を完全に把握することができます。パフォーマンスの問題を調査する際には、すべてのテレメトリデータを共通の次元で横断することができるようになっているのです。

また、ディメンションの追加 (タグ) が原因で料金が高くなる心配もありません。1GBあたり0.30ドルという業界最安値のコスト抑制モデルによって、必要なときに必要なデータがすぐに手に入るという予測可能性と安心感を提供します。

ぜひ New Relic にトライしてみてください。1 user / 100GB データ までなら無料で使うことができます。使い方がわからない場合は、こちらで定期的に New Relic の概要説明や Hands-On Webinar を開催していますのでチェックしてみてください。登録して参加ができなくても事後に資料と動画が送られてきますので登録しておくだけでも役に立つと思います。