トレースとトレースとトレースの違い

New Relicでは以前からトランザクションという言葉を使ってきました。トランザクションと分散トレーシングの「トレース」の関係、そしてそもそもトレースという言葉が指すものが何を意味しているのかについて、少し古いですが「The Difference Between Tracing, Tracing, and Tracing」という記事を抄訳してお届けします。なお、文中の私は原文の筆者Erikaを指しており、時期は2018年4月時点となります。

New Relicで分散トレースプロジェクトをリードしている一人として、私は「トレース(tracing)」という言葉を頻繁に使うので、時々冗談で「トレース」という言葉の意味がわからなくなってしまうことがあります。しかし、言葉は重要です。特に「トレース(tracing)」は様々な物事を指し示すことに使われるため、特に重要です。

私たちの分散トレースプロジェクトは、11個の言語エージェントからデータ挿入層、処理と保管、そして最終的には多くのフロントエンドUIに至るまで、New Relicのエンジニアリング組織全体に及んでいます。次世代のトレーシングの計画を立て始めたとき、この大きくて扱いにくいプロジェクトを、データ収集、伝搬、表示といった独立した問題に分解して説明する方法を模索している自分に気づきました。

別々ではありますが、これらのドメインは関連しているので、プロジェクトに関わるすべての人に説明するのは難しいことでした。（そして、私たちはそれをすべて "分散トレーシング "と呼んでいます。）何人かの人はOpenTracingのサポートを発表したことを知っていましたが、それが何を意味するのか正確にはわかりませんでした。TraceContextやOpenCensusのようなCamelCaseの他のプロジェクトについて話し始めた時点で、目が点になった人もいました。

これらの標準化プロジェクトはそれぞれ、我々が総称して "トレース "と呼んでいる明確な問題を解決しています。2月に私が参加した分散トレースのワークショップにて、”トレースとトレースとトレースの違いは何か？"という質問と回答で、Ben Sigelmanがこれらの区別を解説しました。彼の許可を得て、そのフレームワークをここで紹介し、なぜ私たちが今生まれたばかりの分散トレース標準化に参加することに興奮しているのかを説明します。

トレースはトランザクションの分析に関するものです

トレーシングとは、どのようにシステムを監視し、そのパフォーマンスについての洞察を得る方法です。昨秋のFutureStackカンファレンスでは、独自の可視化機能を持った分散トレーシングのサポートを発表しました。

顧客にとって有用な方法で表示できなければ、トレースを収集するためのすべての努力は無駄になってしまいます。特定のトレースをつなぎ合わせるという基本的なことから、それがなぜ遅いのかを理解できること、データ取り込み処理で最もホットなポイントを通過した特定のワークフローの過去のトレンドを表示すること、機械学習を使用してシステム内のパターンを把握することまで、トレースを可視化することは非常に重要なことです。New Relicを含むほとんどのAPMベンダーは、この分野で競合他社との差別化を図っています。

トレースはトランザクションの記録に関するものです

トレーシングは、多くのトランザクションを追跡する方法です。基本的には、リクエストとしてサービスに入ってくるコンテキストを使って、ある種のトレーサーがそのコンテキストを他のプロセスに伝搬させ、トレースバックエンドに送られたトランザクションデータにアタッチします。このコンテキストを利用して、トランザクションを後からつなぎ合わせることができます。

New Relicは既存のcorss-application tracing機能でこれを実現しています。業界がモノリスからマイクロサービスへと移行する中、APMエージェントをインストールできないプロセス境界を越えてトランザクションを追跡することの重要性はますます高まっています。私たちは、新しいW3C分散トレースコンテキストフォーマットワーキンググループ（トレース情報をどのように受け渡すかの標準化）に積極的に参加しています。

より多くのサービスやより多くのクラウドを利用する状況では、トレースコンテキストが失われる可能性のあるポイントを通過することが増えています。私たちはトレースコンテキストの標準に参加していますので、例えば、リクエストがNew Relicで監視されているシステムで始まり、AWSで監視されているシステムを通過したときでも、コンテキストを伝搬するヘッダが落とされたりトレースが途切れたりすることはありません。

トレースはトランザクションの記述に関するものです

トレースとは、トランザクションを測定する方法です。何が起きて、どのくらいの時間がかかったのか？これがNew Relicが長い間定義してきた「トレース」の定義です。New Relicのエージェントは、アプリケーション内のトランザクション、エラー、遅いクエリをすでに追跡(トレース)しており、お客様は遅い部分がどこにあるのかを知ることができます。

New Relicのエージェントチームは、意味のあるトレースを作成するために、言語固有のアプリケーションフレームワークのエキスパートとなっています。フレームワークやライブラリの作者が独自のインストルメンテーションを含んでいれば、リリースのたびにエージェントを追跡して更新する必要はありません。そのインストルメンテーションがベンダニュートラルであれば、より広く採用されることを促進し、スイッチングコストを下げることができます。

OpenTracingプロジェクトは、汎用トレースAPIでこの問題を明確に解決しようとしています。お客様がNew Relicにデータを送る方法を増やすために、私たちはこれらのAPIコールをサポートし、データを独自のフォーマットに翻訳するようにエージェントを更新しています。

New RelicはOpenTracing標準規格に参加して、計測方法のサポートを拡張し、お客様がモニタリングにNew Relicを選択しやすいようにしています。ソフトウェアは、エンジニアが問題を迅速に診断・修正するのに役立つ計測の充実したアプリケーションから恩恵を受けることができると考えており、計測の充実したAPMソリューションを搭載したアプリケーションが提供する可視性の向上から、すべてのお客様に恩恵を受けていただきたいと考えています。

用語の定義

懸念事項を分けて考えることで、それぞれのトレーシングのドメイン固有のユーザーを考慮できます。運用エンドユーザーは、データとの対話や分析のために提供するUIやAPIを気にしています。Devエンドユーザーは、New RelicのインストルメンテーションAPIとパフォーマンスを気にしています。DevOpsのエンドユーザーは、その両方を気にしています。(そして、誰もコンテキストの伝播をトレースすることについては、邪魔になるか機能しない場合を除いて、実は気にしていません。)

トレース標準化プロジェクトは、必ずしもこれらのカテゴリにきちんと分類されているわけではありません。OpenCensus のようなプロジェクトは、メトリクスやトレース計測のための API を使って、記述と記録の両方のドメインで標準化を目指していますし、Zipkin のような分散トレースを記述、記録、分析するオールインワンのプロジェクトもあります。しかし、用語や問題ドメインを定義することで、それぞれの標準が何であるか（そして何ではないか）についての混乱を減らし、それらが解決する具体的な問題や、それらがどのように連携できるのかについて、より論理的に議論できるようになります。