「良い」テレメトリーとは何か？

オブザーバビリティ・アーキテクトとして、チームがベストプラクティスを採用できるよう支援してきた私の経験の中で、最もよく聞かれる質問の一つが「『良いテレメトリ』とは具体的に何を指すのですか？」というものです。正直なところ、これを説明するのは必ずしも簡単ではありません。

アプリケーションがリアルタイムでどのように動作しているかを理解するために、テレメトリデータが不可欠であることは誰もが知っています。とはいえ、どの状態を「良い」と見なすかを決めるのは難しいものなのです。「良い」とされる状態はさまざまな観点から定義できます。たとえば、アプリケーション内でのデータ生成のスケーラビリティ、テレメトリーがシステムやビジネスロジックをどれだけ適切に表現しているか、さらにそのデータをオブザーバビリティプラットフォームへどれだけ確実に送信できるか、といった点です。また、「良い」と言えるかどうかは、それを使うシステムやチーム、組織によって大きく変わります。小規模なスタートアップに合う方法が、大企業にとっても適しているとは限りません。リアルタイムのデータ処理を重視するシステムと、バッチ処理を行うシステムとでは、求められるものも異なります。

一方、何かを測定しなければ改善はできません。これはオブザーバビリティ（可観測性）にも当てはまる原則です。結局のところ、オブザーバビリティは監視のような行為ではなく、セキュリティや信頼性と同じように、システムに本来備わっている特性なのです。システムの観測方法を本気で改善したいのであれば、私たちが正しい方向に進んでいるかどうかを示す、皆で合意した標準的な測定基準を定めることが重要になります。

この信念があるからこそ、私はオブザーバビリティ分野の新しいプロジェクト「Instrumentation Score（テレメトリー評価スコア）」を発表できることを嬉しく思っています。このオープンスタンダードは、アプリケーションがオブザーバビリティに適切に対応できる状態かを測定することを目的としています。チーム全体で取り組んだプロジェクトで、当初はNew Relic、Ollygarden、Splunk、Dash0などのエンジニアが参加していました。たいへん嬉しいことに、私はその初期開発のリードを手伝っておりました。

作業に最適なツール

なぜこれが重要なのか、詳しく見ていきましょう。システムの全体像を把握するには、トレース、メトリクス、ログ／イベント、プロファイルなど、複数のシグナルが必要だとよく言われます。OpenTelemetryは、エンドユーザーであれオープンソースライブラリの所有者であれ、ベンダーに依存しない標準的な方法でそれらを生成できるよう支援します。この内容は最近、KubeCon + CloudNativeConで「OpenTelemetry in 5 Minutes（5分でわかるOpenTelemetry）」として取り上げました。しかし、各信号をいつ使用するかは、どのように見極めればよいのでしょうか。どのようにして、それが本来の目的に沿って実行されているかを確認できるのでしょうか。

これを例証するために思考実験をして理解を深めてみましょう。以下の図をご覧ください。たとえば、誰かがあなたのウェブサイトを訪問し、決済処理時に不快な経験をした場合を考えてみます。この現象は、ユーザーのブラウザから送信される「決済処理失敗」イベントの件数の増加として表れます。これらは個別のイベントの場合もありますが、共通の「 session.id」属性を使用することで、同じユーザーセッション中に生成された分散トレースとそれらのイベントを関連付けることができます。これらのトレースを使うと、個々のリクエストがシステム内でどのように処理されているかを、バックエンドサービスに至るまで追跡できます。下の図では、それぞれ異なる色で表されています。これにより、どこでどのように障害が発生しているかをより深く理解し、すべてのリクエストにおける異常を特定し、最終的にはそれらのエラーの根本原因を突き止めることができます。

一方で、バックエンドサービスのうちの1つを運用しているチームが、関連性のある性能低下や不具合の再発に関するアラートを受け取ることも想定できます。今回この運用チームは、エンドユーザーの視点からではなく、サービス内で発生した「 5xx 」応答の件数を示す高レベルの標準メトリクスから分析を始めました。OpenTelemetryの「Exemplars」などの概念のおかげで、エラーメトリクスが生成されたのと同じタイミングで記録された個別のトレースを見つけることができます。このコンテキストを使用すると、エンドユーザーへの影響を迅速に把握し、サービス障害の原因となっている問題のある依存関係を特定することもできます。すべての要素はシステム全体を包括的に説明する一部であり、トラブルシューティングに関わるすべてのエンジニアがその全体像を理解しています。

同じトレースコンテキストは、個々のトランザクションで生成されたログに付加したり、特定のレプリカ内のコールスタックを確認することでしか特定できない問題を詳しく調べるプロファイルにも付加することができます。粒度のレベルは異なりますが、全体的なコンテキストは同じです。

最後に、これらすべてのシグナルにわたって標準のセマンティック規約を使用すると、New Relicなどのオブザーバビリティプラットフォームは、異なる測定値同士の関係性や因果関係を理解できるようになります。たとえば、これらの失敗したリクエストはすべて同じKubernetesポッドに属していて、特定のレプリカにおけるメモリ競合が潜在的な根本原因となっている可能性も考えられます。

私はAIの専門家ではありませんが、一つだけわかっていることがあります。それは、コンテキストが優れているほど、より優れた洞察が得られるということです。これらすべての信号が同じコンテキストと同じセマンティック規約を共有している場合、それらを単一のクエリで関連付けられるオブザーバビリティプラットフォームがあれば、「これらの失敗した決済のリクエストを処理したサービスのレプリカのメモリ使用率はどれくらいだったか」といった質問に答えることができます。あるいは、そもそも質問をする必要すらなく、高性能な新AIに任せてしまえばいいのです。

結局のところ、オブザーバビリティの目標は、ユーザーを満足させる要因や、システムがユーザーに優れた体験を効率的に提供できるようにする仕組みを理解することであり、そのためには質の高いデータが必要です。直感ではなく証拠に基づいて質問に答えられるように、システムを記述するデータが必要なのです。これらのデータは、過去に起きたことが再び起こるかもしれないという前提ではなく、相関関係に基づいています。

すべてのデータが同じように作られているわけではない

しかし、すべてのデータが同じように作成されるわけではありません。オブザーバビリティデータには、監査やその他の種類の分析に使用されるデータとは異なる要件があります。たとえば、完成度よりも鮮度を重視することがあります。また、当社のシステムを通るトランザクションの大部分は、実際にはそれほど「興味深いもの」ではないこともわかっています。それらのトランザクションは、通常通りの時間で問題なく完了するからです。では、何か問題が発生した場合に備えて、すべてのデバッグレベルの情報を転送・保存する必要があるのでしょうか？ほとんどの場合、その必要はありません。トラブルシューティングとパフォーマンス監視のための「適切な」データの収集に注力するべきです。そうすれば地球にもやさしくなります。

テレメトリーの中でも、各シグナルにはそもそも信頼性の違いがあり、それぞれ異なる用途に適しています。たとえば、メトリクスの計測データは、予測がしやすく信頼性の高い情報をもたらします。エンドポイントごとのリクエスト数をカウンターとして集計するメトリクスは、サービスが1秒あたり100万件のリクエストを処理するか、10件のリクエストを処理するかに関係なく、おおよそ同じ量のデータしか生成しません。これにより、OTLPなどのプロトコルを実装しているクライアントは、リクエストごとにレコードが生成されるトレースやログよりも、メトリクスのエクスポートをより長い時間バッファリングしたり再試行したりすることができます。そして、メトリクスはデータが高度に集約されているため、長期的な傾向分析やアラートの設定に非常に適しています。ただし、本質的にコンテキストが欠如しているため、デバッグや異常の原因を把握するような場合にはあまり適していません。

一方、トレースは粒度が高いため、システムとその中の相互依存関係を深く理解するのに最適です。分散システムを真に理解する上で重要です。ただし、トレースデータは量が多いため、もしメトリクスと同じレベルの信頼性を実現しようとすると、バッファリングや再試行、トラフィックの送信に非常に高いコストがかかる可能性があります。幸いなことに、コンテキストはここでも役立ちます。スマートサンプリング手法を使用して本当に重要なデータだけを保存し、他の信号と相関付けることができます。

ここで登場するのがInstrumentation Scoreです。Instrumentation Scoreは、これらすべての信号がどのように組み合わさっているのかを詳しく示し、最終的なテレメトリーがシステム全体をどれだけ総合的に表現できているかを測定します。これは、テレメトリーが特定のオブザーバビリティニーズをどの程度満たしているかを、効果的かつ効率的に測定し、多額の請求や運用上の予期せぬ事態を回避する方法です。

オブザーバビリティを成熟させるために

きっとこう思われる方もいるでしょう。「それなら、OpenTelemetryのセマンティック規約がまさにそのためにあるんじゃないの？」おっしゃるとおりです。セマンティック規約は、テレメトリーの送り手の観点から見た良いテレメトリーのあり方を定義します。WeaverのようなOpenTelemetryツールを使えば、それらのスキーマへの準拠度を測定したり、独自のユースケースに合わせて拡張したりすることもできます。しかし、Instrumentation Scoreはそれをさらに一歩進め、より幅広い観点から評価します。これは、使用時点でのテレメトリーの品質を考慮した、より上位レベルの視点です。当社が重視しているのは、テレメトリーがソースでどれだけ適切に生成されているかだけではありません。監視対象のアプリケーションと利用しているオブザーバビリティプラットフォームから構成される特定の環境の中で、そのテレメトリーが実際にどれほどシステムの理解や改善に役立っているかという点にも注目しています。

最後に、オブザーバビリティの成熟度について説明します。オブザーバビリティは、監視対象となるシステムが持つ固有の特性であり、それによって私たちは特定のビジネス成果を推進できることを先ほど述べました。しかし、ゼロから理想の状態へ一気に到達できるわけではありません。そのため、段階的に自社の体制を改善していく上で、何を優先して取り組むべきかを理解することが重要です。少しずつでも確実に歩みを進めていきましょう。

オブザーバビリティの専門家が、平均的なチームに対して「オブザーバビリティ向上のために実行できるアクション」をすべてまとめた長大なリストを渡したとしたら、チームはそれぞれの影響を理解できないまま、膨大なアドバイスに圧倒されてしまうでしょう。結局、そのリストを閉じたまま、二度と目を通すことはなくなってしまいます。ここで重要になってくるのが、Instrumentation Scoreと、それをもとに作成できるスコアカードです。各ルールに異なる影響度や加重スコアを設定することで、成熟度モデルの構築や組織内でのベストプラクティスの導入促進が可能になります。こうすることで、チームはシステムのオブザーバビリティ向上のために、最も価値の高いアクションから優先的に取り組めるようになります。また、オペレーショナルエクセレンスの活動にゲーム要素を取り入れることで、みんながより楽しく取り組めるはずです。

ぜひご参加ください！

いかがでしたか。本記事でご紹介した考えについてぜひご意見をお聞かせください。オブザーバビリティをすべての人にとってより役立つものにするにはどうしたらいいか、意見を交換しませんか。Instrumentation Scoreはまだ初期段階にあり、何を測定すべきか、そしてどのように測定するかという重要なポイントを模索しています。その様子は、https://github.com/instrumentation-score/specでの議論からもご確認いただけます。ぜひご参加いただき、より優れたオブザーバビリティデータの未来を一緒に切り拓いていきましょう。