テレメトリーデータとは？収集方法、オブザーバビリティに必要な理由

テレメトリーデータは、オブザーバビリティの実践において不可欠な要素のひとつです。テレメトリーデータを活用してシステムの健全性やパフォーマンスを監視することで、迅速な問題解決ができるようになります。また、ビジネス上の意思決定や効率的な運用にも役立てることができるでしょう。

ここでは、テレメトリーデータの種類や収集方法、オブザーバビリティに不可欠な理由のほか、オブザーバビリティツールを選ぶ際のポイントについて解説します。

テレメトリーデータとは、システムの状態を表すデータ

テレメトリーデータ（Telemetry Data）は、システムの状態を表すデータのことを指し、システムの異常の検知と解決、パフォーマンスの最適化を目的として収集されます。

そもそも「テレメトリー」は、対象物を離れた場所から観測・測定することを指し、IT分野では、システムやソフトウェアの動きを遠隔地から監視するプロセスの意味で使われます。例えば、現代の自動車は、IoTデバイスを通じてエンジン状態、燃料消費、走行距離などのデータを収集し、リアルタイムで遠隔地に送信しています。これもテレメトリーの一種です。

ITシステムにおいてテレメトリーデータは、システムやアプリケーションの状態を把握する仕組みであるオブザーバビリティに活用されます。

障害に強い組織を作る上で必須なオブザーバビリティ

オブザーバビリティは、システムが複雑化し、異常検知から解決までのスピード感が求められる現在において、重要な概念です。CPU使用率などの低レイヤのメトリクス監視とログ集約を基本とした従来の監視方法では、エラーの原因を特定するために膨大なログデータの解析を行ったり、ベテランエンジニアの経験や勘をもとに障害の原因を特定、推測したりしていました。

しかし、こうした監視方法では、現在のようなシステムが複雑化した環境に対応できません。組織にオブザーバビリティがあれば、どこにトラブルの原因があるのかを探り出すことが容易にできます。予期せぬトラブルが起きても、組織はその状況を迅速に把握でき、勘や経験に頼らずデータをもとに原因を特定できるでしょう。
オブザーバビリティは、言葉としての認知が広がりつつありますが、監視と混同されることが少なくありません。しかし、オブザーバビリティは、先程述べたような従来の監視とは決定的な違いがあります。
監視は、しきい値やログに表示される特定の文字列といった、あらかじめ予想した事象が起きるかどうかをチェックし続け、トラブルが発生してから既知の事象に対処するリアクティブな対処であるのに対し、オブザーバビリティは既知の問題への対処だけでなく、データを分析し潜在的な問題を特定するプロアクティブな対処です。

オブザーバビリティについては、こちらの記事「オブザーバビリティとは？監視との違い、必要性について解説」もご覧ください。

テレメトリーデータがオブザーバビリティに不可欠な理由

テレメトリーデータは、オブザーバビリティにおいて不可欠です。なぜなら、システムの内部状況を把握できるテレメトリーデータを活用することで、複雑なシステムの状態やアプリケーションの動きを可視化・解析できるからです。

例えば、アプリケーションの予期せぬ振る舞いの原因を迅速に特定することで、ユーザー体験に影響を与える前に問題を修正できます。また、パフォーマンスの低下や特定のエラーが頻発している箇所を特定することで、システムの品質を向上させることが可能です。
オブザーバビリティを実践するには、「包括的なテレメトリーデータの収集」、「テレメトリーデータの相関関係や意味付けを行う分析」、「分析されたテレメトリーデータを次のアクションをわかりやすく示す可視化」の3つが必要です。オブザーバビリティの実現には、こうしたテレメトリーデータの活用が鍵となります。

オブザーバビリティの実現に重要な3種類のテレメトリーデータ

一般的にオブザーバビリティの実現に重要なテレメトリーデータは、「メトリクス」「トレース」「ログ」といわれています。それぞれのデータについて解説します。

メトリクス：測定値の集合

メトリクスは、定期的に収集された測定値データの集合体です。基本的に「数値で表される情報」と考えればよいでしょう。メモリ使用率やCPU使用率、ネットワーク帯域使用率などの情報を平均値、最大値、最小値、パーセンタイルなど、さまざまな統計的手法を用いて要約します。

例えば、ネットワーク帯域使用率を毎分取得して、5分毎の平均値をメトリクスとして保存した場合、データの量は非常に軽量になりますが、特定の1分間のネットワーク帯域使用率や5分間の中の最大値をメトリクスから求めることはできません。メトリクスは利用するデータの定義と分析方法をあらかじめ定義することが必要です。

トレース：システム内のイベントフローの証跡

トレースは、マイクロサービス間、もしくは異なるコンポーネント間における、イベントやトランザクションの連携する状態を表します。また、トレースはログのようにそれぞれのマイクロサービスやコンポーネントから不規則に発生します。

トレースによって、どのコンポーネントが関与し、それぞれの処理にどれくらいの時間がかかったかが明らかになり、システムのパフォーマンスと効率性を向上させるための洞察を提供します。

ログ：システム活動の記録

ログはシステムの特定のイベントを記録するためのデータです。これは通常、システムが特定のアクションを実行するたびに生成され、エラーメッセージ、警告、情報メッセージなどを含むことがあります。

ログは、システムが何をしたか、何が問題であったか、何が起こったかを把握するための重要なデータです。

オブザーバビリティを高めるために必要なデータ「イベント」

一般的に、メトリクス、トレース、ログの3つのテレメトリーデータが、オブザーバビリティに重要とされています。しかし、オブザーバビリティを高めるためには、さらに「イベント」が必要です。
ここでいうイベントとは、New Relic特有の概念です。New Relicでは、オブザーバビリティを高めるために必要なデータを、メトリクス（Metrics）、イベント（Event）、ログ（Log）、トレース（Trace）の4種類としており、それぞれの頭文字をとって「MELT」と呼んでいます。

「イベント」は、システムやアプリケーション内で発生する特定のアクションを指します。これらのイベントデータは、ユーザーのアクション、システムのエラー、アプリケーションのクラッシュ、サービスの呼び出し、さまざまな形で発生します。
New Relicにおけるイベントは、通常、タイムスタンプ、イベントタイプ、およびイベントに関連するさまざまな属性やメトリクスを含む構造化されたデータ形式で記録されます。これにより、特定の時間枠内でどういったアクションが起きたのか、どのようなパターンが存在するのか、問題の原因は何かなど、システムやアプリケーションの動作に関する深い洞察を得ることができます。
「結果」のデータであるメトリクス、トレース、ログにイベントが加わることにより、結果となるデータが、どのように生まれたのかを解き明かすことが可能になります。

MELTを収集し保存しておくことで、障害が起こった際に、一連のプロセス上のどこに障害要因があるのかを動的に把握でき、根本原因をより的確かつ迅速に特定できるのです。

テレメトリーデータを扱う上での課題

テレメトリーデータを扱うにあたっては、注意しておきたい点がひとつあります。それは、データをどこに保存しておくかということです。

ビジネスを立ち上げて間もなく、まだサービスの規模が小さい間は、データの保存場所はあまり問題にならないかもしれません。しかし、事業が軌道に乗り、サービスの規模が拡大していくと、取得するテレメトリーデータの量も加速度的に膨張していきます。さらには、データの書き込みだけでなく、ダッシュボードの表示やアラート判定などのためのデータ読み込みも発生するため、常にデータストアに高負荷がかかる状態になってしまうのです。

テレメトリーデータの収集方法

テレメトリーデータの収集方法は、自社でデータストアを用意する方法とSaaSを活用する方法の大きく2つのパターンがあります。それぞれの特徴について見てみましょう。

自社でデータストアを用意する

テレメトリーデータの収集方法として、自社でデータストアを用意する方法があります。自社で開発した監視ツールを使う場合のほか、最近はオープンソースの監視ツールを使うケースも増加傾向にあります。自社でテレメトリーデータを保存するデータストアを用意する場合、初期費用がかかるだけではなく、設定、運用、管理も行わなければなりません。
また、サービス規模がスケールしてくると、データストアを含めた監視システム自体の可用性の問題が表面化する時がくるでしょう。データストアを自社内で管理する場合は、その分野に精通したエンジニアのリソースが必要になります。

SaaSプラットフォームを利用する

SaaSプラットフォームを使ってテレメトリーデータの収集を行う方法もあります。データストアも含めてSaaSプラットフォームを利用できるため、サービスの規模にかかわらず、変わらぬ環境で使い続けることができるでしょう。
しかし、SaaSプラットフォームは自社でデータストアを用意するためのリソースは節約できますが、SaaSプラットフォームを使用するための金銭的コストがかかります。そのため、最初は自社のデータストアを使用し、サービスが成長してきたタイミングで、SaaSプラットフォームに移行するというパターンも少なくありません。

オブザーバビリティツールを選ぶ際のポイント

オブザーバビリティツールを選ぶ際は、オープンテレメトリーに対応しているかどうかが、重要なポイントになります。オープンテレメトリーとは、ベンダーに依存せず、データの収集からバックエンドへの転送までを標準化することを目的とした統一規格です。

システムの状態やアプリケーションの動きを正確に把握するために、アプリケーションごとに収集ツールを使い分けるとなると、データのサイロ化が起こり、障害発生時の原因究明や復旧作業が難しくなってしまいます。同時に、ほかのベンダーの製品への乗り換えが難しくなり、特定のベンダーに依存するベンダーロックインの状態におちいりかねません。
この問題に対処したのが、オープンテレメトリーです。バックエンドのプラットフォームを変更しても、オープンテレメトリーに準拠していれば、プラットフォーム固有のエージェントをインストールしなくても済みます。
オープンテレメトリーに準拠しているオブザーバビリティツールは、各社からリリースされています。ただ、データの扱い方と見せ方については、各ツールそれぞれに違いがあるため、いくつか試用してみて、自社のニーズに合い、見やすく、扱いやすいツールを選ぶとよいでしょう。

オープンテレメトリーについては、こちらの記事「OpenTelemetryとは何か、そしてなぜそれが計装器の未来なのか？」も合わせてご覧ください。

オブザーバビリティの導入なら4つのテレメトリーデータを活用したNew Relicがおすすめ

これからオブザーバビリティを実践するなら、テレメトリーデータプラットフォームであるNew Relicがおすすめです。ここでは、New Relicの特徴をご紹介します。

イベントによる詳細な分析が可能

New Relicの大きな特徴のひとつは、メトリクス、トレース、ログに加えて、独自の概念であるイベントを収集することです。これらのテレメトリーデータを収集し、分析することで、外れ値の発見や全体の傾向を俯瞰することも可能になります。

例として、New RelicのAPMから送られてくるイベント「トランザクション」についてご紹介しましょう。トランザクションは、システムからリクエストが来てレスポンスを返すまでの一連の動きをイベントとしてとらえ、それをJSON（JavaScript Object Notation）で保存したデータです。
そこには、タイムスタンプが入り、HTTPメソッドはGETかPOSTか、時間がどれほどかかったのか、ユーザーエージェントやステータスコードは何か、などの細かな情報が、リクエストごとに作成され、記録されます。こうしたイベントを使うと、「直近のWebトランザクションの平均処理時間を、リクエストURL、HTTPメソッドごとに集計する」といった分析視点を持った検索が容易になります。こうした検索は、メトリクスやログだけでは簡単にはできません。
また、モバイルエージェントの場合、アプリケーションの突然のクラッシュもイベントとして収集することで、どのデバイスで起こりやすいのか、どのOS、どのバージョンで起こりやすいのかといった傾向分析ができ、イベントを軸に詳細な調査ができます。

見やすくわかりやすく、移行しやすい

New Relicは、「More Perfect Software」をコンセプトとして、お客様のサービスがより完璧に近づけるためのプラットフォームを提供しています。これは機能面だけでなく、ユーザーインターフェースの見やすさ、扱いやすさといったUI/UXにおいてもいえることです。

例えば、画面上でトランザクション一覧を表示する場合でも、早急に対処・改善が必要なものを優先的に表示する機能を持ちます。これは、ユーザーがエラーの解消やパフォーマンス改善に、素早く対応できるために設計されているのです。
また、New Relicは、あらゆるデータを蓄積し、用途に応じて可視化できる強力なデータベースを備えているため、直感的に検索が可能なところも大きな魅力でもあります。オープンテレメトリーにも対応しており、データ収集の仕組みはオープンソースを使用してデータの保存先をNew Relicで行うという使い方も可能です。

これからオブザーバビリティを導入するなら、さらなる「完璧」を目指せるNew Relicを、ぜひお試しください。