OpenTelemetryの進化：共同創設者 Ted Youngと深掘りする
ソフトウェアにおける最大の挑戦は、時にコードそのものではなく「合意形成」にあります。何と呼ぶべきか？何を標準化すべきか？そして、何千もの企業が依存しているシステムを、途中で何も壊さずにどう進化させるのか？
今回の「Grafana’s Big Tent」ポッドキャストでは、Grafana LabsのPrincipal Software EngineerであるMat Ryerと、VP of CultureのMatt Tobackが、OpenTelemetryの共同創設者でありGrafana LabsのDeveloper Programs Directorを務めるTed Youngをゲストに迎えました。オブザーバビリティ標準の変遷や、トレース導入の現実、そしてOpenTelemetryが「徹底した合意形成」と「圧倒的な進化スピード」をなぜ両立させているのかについて議論します。
また、彼らは「3つの柱」という神話、ログに隠された複雑さ、言語レベルの制約、そして真の「ゼロタッチ」なインストルメンテーションへの取り組みについても掘り下げています。
エピソードの全編は以下のYouTubeビデオ、またはSpotifyやApple Podcastsでご視聴いただけます。
（注：以下は「Grafana’s Big Tent」シーズン3・エピソード6のハイライトです。この書き起こしは、長さと明快さのために編集されています。）
※この記事は「Grafana's Big Tent」ポッドキャスト シーズン3・第6話の書き起こしを、読みやすくまとめた編集版です。
ステージを整える：OpenTelemetryと標準化
Ted Young: OpenTelemetryはテレメトリシステムです。オブザーバビリティスタックを分割する新しい方法だと考えてください。かつて、私たちはスタックを「シグナル」ごとに分割していました。トレース、ログ、メトリクス、プロファイリングといったオブザーバビリティのスタイルを一つ選び、「ログシステムを作ろう」と決めるわけです。ログフォーマットを作り、それらのログを生成・処理するためのログAPIとログクライアントを作ります。さらに、そのログを保存するデータベースと、データベース内のログを見るためのUIを作ります。これが従来のログシステムでした。しかし、次に誰かがメトリクスシステムを欲しがると、そのメトリクスシステムのためだけに、これらすべての作業をやり直すことになります。
新しい分割方法は、テレメトリ、アプリケーション、システム、そしてコンピューティングリソースが存在し、それらがすべて「自己記述的」であると定義することです。それらはすべて、自分たちが何をしているのかを記述しようとしています。そして記述する際、すべてが「同じ言語」を話そうとします。なぜなら、それらが何をしているのかを理解しようとする時、個々のピースを切り離して見ることはないからです。全体を一緒に見るはずです。ですから、もしそれらすべてが同じ言語で自分たちの動作を記述できれば、包括的な全体像を把握するのがずっと容易になります。
私たちはコンピューターが何をしているかを記述することについて話していますが、コンピューターがしていることの多くは、ネットワークプロトコルを介した通信などの標準化された動作です。であれば、システムが自身を記述するために使う言語を標準化することは可能なはずです。もしそれを実現したいなら、分析やストレージ、ユーザーエクスペリエンスといった要素から切り離す必要があります。それら（分析やUI）はまだ開拓の余地がある、自由な領域（グリーンフィールド）だからです。
これがオブザーバビリティを切り分ける新しい方法です。私たちが標準化し、全員で共有したいのは「テレメトリ」である、ということです。
トレース、ログ、そして「3つの柱」という神話
Ted: 伝統的に、ログと分散トレースはまったく別物として語られてきましたが、それは実際には人間がたどってきた歴史的な偶然にすぎません。私たちは、トレースとは単に「ログにずっと欲しかったコンテキスト（文脈）が付随したもの」であると気づき始めています。例えば、「これらのログはどのトランザクションの一部なのか？」といったことです。同じトランザクション内の他のログを引くだけのことが、何十年もできなかったというのは、私にとって驚くべきことです。
Mat Ryer: あなたはパーティーにやってきて、「もしログやイベントが本当はトレースだったらどうする？」なんて存亡に関わるような問いを投げかけるタイプの人ですね。みんな「もう帰りなよ」ってなりそうです。
Ted: 実態は正反対です。私は概念的な議論に終始したくはありません。人々が「このツールにはこの価値がある」とあらかじめ分類してしまっているため、そうした既成概念を相手に孤独な戦いを強いられている気分です。例えば、「トレースはレイテンシ分析のためのツールだ」と思われていますよね。でも、トレースはコストが非常にかかるため、大量のサンプリングが避けられません。あらかじめ（入口で）間引いてしまうため、いざ障害対応や根本原因分析をしようとしても、肝心のデータが手元にないんです。すべてを記録しておくログシステムとは、そこが決定的に違います。
トレースが激しくサンプリングされる唯一の理由は、既存の「高価で全データを保存するログシステム」に後付けしようとしたからです。でも、そのログシステム自体にはトレースコンテキストがなく、しかも既存システムには怖くて手を加えられませんでした。その結果、まるで「トレース」という名の「第2のログシステム」を横に作り、ログシステムの余り物のリソースだけで細々と動かすことになったんです。だからレイテンシ分析のためにデータを間引くしかありませんでした。これは単なる歴史的な経緯によるもので、トレースとログが本質的に別物だからではないんです。
高レイテンシ、高スループット
Ted: OpenTelemetryは奇妙な生き物です。私はOpenTelemetryの非公式マスコットは、『ネバーエンディング・ストーリー』に出てくる「レーシング・スネイル（走るカタツムリ）」だと思っています。OpenTelemetryは「高レイテンシ、かつ高スループット」です。つまり、何か特定の課題に取り組もうとすると、「なんて遅いんだ、委員会主導の設計だ」と感じるでしょう。実際、そう感じられることがあります。なぜなら、他の多くのオープンソースプロジェクトとは異なり、OpenTelemetryには「やり直し」が許されないからです。一般的に、私たちが世に出して普及した後にそれを壊してしまうと、人々は私たちを永遠に恨むでしょう。新しいもので壊れても「まあ、新しいオープンソースだからね」で済む他のプロジェクトよりも、ずっと強くです。
Mat: それは誰もがそう感じるのではないですか？ 愛用していたものが奪われたら。
Ted: いえいえ、OpenTelemetryは後方互換性を壊した時の罰が、他のプロジェクトよりもずっと重いと感じています。特定のレベルやレイヤーでは、非常に厳格でなければなりません。特にAPIやデータレイヤーにおいて、例えば「このライブラリはOpenTelemetry 1.0に依存し、別のライブラリは2.0に依存している」という依存関係の競合が発生すると、OpenTelemetryのせいでこれらのライブラリを組み合わせて（コンポーザブルに）使えなくなってしまいます。だから、私たちは細心の注意を払わなければならないのです。
なぜトレースはもっと早く普及しなかったのか？
Matt Toback: もし根本的なアーキテクチャが違っていたら、分散トレースはもっと早く普及していたと思いますか？
Ted: 分散トレースで最も難しいのは、その「インストール」だと思います。トレースから得られるコンテキストは、追跡している「実行フロー」そのものだからです。しかし、言語のランタイムは、オブザーバビリティの観点からその実行フローを効果的に追跡する方法を提供していません。スレッドを持つ言語でスレッドローカル変数に頼れば、ある程度は可能かもしれません。しかし、処理はしばしば「スレッド」を切り替えますよね？ あるスレッドから別のスレッドへ移動したり、一連のスレッドが Scatter-Gather（分散・集約）的な動きをしたりします。
あらゆる言語においてOpenTelemetryで最もトリッキーな部分は、私たちが考案しなければならない「コンテキスト伝播」のメカニズムです。そして、すべてのインストルメンテーションが同じ横断的なメカニズムを使用しなければなりません。これは、自分だけのコーナーで始められるメトリクスやログに比べて、ロールアウトして価値を得るまでのハードルが高いのです。
もしトレースの価値がこの「分散コンテキスト」にあると言うなら、その価値を得るためには、関連するすべてのサービスにトレースをロールアウトしなければなりません。それが問題でした。膨大な作業量に加え、ユーザーが「ベンダーを切り替える時に、これらすべてを剥がして入れ替えなければならない」と考える状況では、GoogleやMicrosoft、パロアルト研究所（Xerox PARC）のように、それをやり遂げるだけの巨大な内部エンジニアリング文化を持つ組織以外では、導入時点で頓挫（Dead on arrival）してしまいます。それが本当の障壁でした。
ゼロタッチなオブザーバビリティに向けて
Ted: 私が見たい未来は、誰もどこにもOpenTelemetryのインストルメンテーションをインストールする必要がない世界です。人々がソフトウェアを書く時に、そのソフトウェアがどう実行されるかを考え、自らインストルメンテーションを行い、実行する人のための「プレイブック（手引書）」を一緒に提供する。設定パラメータをどうチューニングすべきかを伝える。そんな世界を望んでいます。現在、多くの人がオブザーバビリティについて考えないのは、自分のコードをインストルメントするためのツールを持っていないから、という側面もあると思います。OpenTelemetryなしでは、ネイティブなインストルメンテーションを行うのは実際には困難です。長期的には、その副産物として、誰もがオブザーバビリティの専門家に近づいていくことを期待しています。
Matt: AIはその達成を助けてくれると思いますか？
Ted: AIに関しては、「ツールがより複雑になるだけで何も変わらない確率が90%」、「世界がターミネーターのような災厄で終わる確率が10%」で、その中間はほとんどないと感じています。私のAI予測は非常に極端（バイモーダル）なんです。
「Grafana’s Big Tent」ポッドキャストでは、皆様からのご意見をお待ちしています。共有したいストーリーや、会話への参加、フィードバックがある場合は、Big Tentチーム（bigtent@grafana.com）までご連絡ください。