OpenTelemetry の安定化とリリース慣行の進化
概要
OpenTelemetry は、あらゆる指標において、クラウドネイティブ領域で最も大規模かつ注目されているプロジェクトのひとつです。 過去5年間で、このコミュニティは歴史上最も重要なオブザーバビリティプロジェクトのひとつを築き上げてきました。 しかし、私たちは現状に満足しているわけではありません。 プロジェクトは常に、幅広いステークホルダーからのフィードバックを求め、耳を傾けています。 皆さんから聞こえてくるのは、次のレベルに進むためには優先事項を調整し、安定性、信頼性、そしてプロジェクトのリリースやドキュメント・サンプルコードなどの成果物の整理に注力する必要があるということです。
過去1年間にわたり、さまざまなユーザーインタビューやアンケートを実施し、多くの場でオープンな議論を行ってきました。 これらの議論を通じて、OpenTelemetry の複雑さと安定性の欠如が本番デプロイメントの障壁となっていることが明らかになりました。
このブログ記事では、このフィードバックに対処するために Governance Committee が重要と考える目標と目的を示します。 まずはこの記事から始めて、議論を公開の場で行っていきます。
私たちの目標
- すべての OpenTelemetry ディストリビューションが「デフォルトで安定」であることを保証し、ユーザーが実験的または不安定な機能にオプトインするための標準化されたメカニズムを提供する。
- ドキュメント、パフォーマンステスト、ベンチマークなどを含む、安定性に関する明確で一貫した基準を単一のセットとして用意する。
- 計装ライブラリの安定化を容易にし、セマンティック規約のフェデレーションを促進する。
- エンドユーザー組織にとって導入しやすい「エポックリリース」を導入する。
フィードバックをお待ちしています！
メンテナーやコントリビューターの皆さんには、この提案全般と、実装のタイムライン、安定性レベルの移行要件、テレメトリー出力の移行をどう扱うかなどの具体的な事項についてフィードバックをいただきたいです。
エンドユーザーの皆さんには、OpenTelemetry のリリースをどのように導入したいか、また現在どのように導入しているかについてフィードバックをいただきたいです。 さまざまなバージョニングやリリース戦略を評価するにあたり、現在どのように変更をロールアウトしているか、特にポリグロット環境での状況を理解できると助かります。 また、計装ライブラリや Collector などのコンポーネントに関するドキュメントやパフォーマンスベンチマークについてもフィードバックをお待ちしています。
インテグレーター、ベンダー、そしてより広いエコシステムの皆さんには、計装やセマンティック規約のメタデータとディスカバリーに関するフィードバックと建設的な提案をいただきたいです。 OpenTelemetry の上に、あるいは OpenTelemetry と並行して構築しているインテグレーターの皆さんには、皆さんやユーザーが OpenTelemetry をより簡単に利用できるようにするにはどうすればよいか、また皆さん自身の計装の公開と保守をより容易にするにはどうすればよいか、ぜひお聞かせください。
このブログの後続のセクションでは、フィードバックをいただきたい具体的な事項がほかにもあります。 これらの目標を達成する具体的な方法は確定していないことを覚えておいてください。 だからこそ、提案に対する皆さんのフィードバックを求めているのです！ 目標を達成するためのより良い方法があると思う場合は、ディスカッションでお知らせください。
なぜこれを行うのか
OpenTelemetry は、大規模で複雑なエコシステムへと成長しました。 4つのテレメトリーシグナル（トレース、メトリクス、ログ、プロファイル）を12以上のプログラミング言語でサポートしています。 各言語には固有のランタイム要件と実行環境があります。 仕様準拠マトリックスを見れば、私たちがどれほど多くのことを達成しようとしているかがわかります。 その量は圧倒的です。
この複雑さが導入の現実的な障壁を生み出しています。 本番環境で OpenTelemetry をデプロイしようとする組織は、予期しない問題に直面します。 マイナーバージョン間で設定が壊れたり、スケール時にのみ現れるパフォーマンスの後退が起きたり、数百から数千のサービスにわたるロールアウトの調整が困難であったりします。 その結果、多くのチームが OpenTelemetry のデプロイメントを延期したり、規模を縮小したりしています。
メンテナーにとっても、この複雑さは仕事を必要以上に困難にしています。 ある時点で「何が最も重要か」についての明確なマイルストーンやガイダンスが不足しています。 安定化の取り組みには多くの変更が伴い、時間をどこに集中すべきかについて矛盾するガイダンスがあることも少なくありません。
これらの懸念への対処は、メンテナーやコントリビューターの健全性のためだけでなく、プロジェクトの成熟に伴い、特にクラウドネイティブエコシステムにより深く統合されていく中で、成長とスケールを続けるためにも、プロジェクトにとって高い優先度であるべきです。
Governance Committee は、これらの変更を成功させるにはコミュニティの関与と議論が必要であると考えています。 そのため、この機会に私たちの意図を発表し、ユーザー、メンテナー、コントリビューターからのフィードバックを得るために GitHub ディスカッションを開きます。 これらの変更が一夜にして完了するとは思っていません。 プロジェクト全体の健全性と成熟に必要な変更を検討する中でも、ユーザーやメンテナーに対する既存のコミットメントを引き続き優先することを皆さんに保証したいと思います。
1. デフォルトで安定
安定性の保証は OpenTelemetry における長年の原則であり、非常に高い基準が設けられています。 これとユーザーニーズの間に緊張関係があり、それについて議論したいと考えています。
背景
OpenTelemetry は、クラウドネイティブソフトウェア（ライブラリ、フレームワーク、インフラストラクチャの抽象化、実行コードなど）がその動作に関するテレメトリーデータをどのように生成し通信するかの仕様です。 この仕様は、網羅的で包括的かつ低レベルであるように設計されています。 仕様の要素の多くは、プラネタリースケールでのテレメトリーシステムの構築、運用、設計に携わった著者たちの数十年にわたる経験から得られた貴重な知見です。
しかし、実装のない仕様はエンドユーザーにとって有用なものではありません。 開発者やオペレーターはさまざまな視点からテレメトリーにアプローチします。 オブザーバビリティに対して高い基準を持ち、内部の監視・計装フレームワークの構築にチームを専念させている組織もあります。 一方で、オブザーバビリティや監視を二の次、三の次の優先事項と考える組織もあります。 つまり、必要ではあるが積極的に推進されるものではないという位置づけです。 仕様としての OpenTelemetry は、これらすべてのユーザーとユースケースに対応する必要があります。
OpenTelemetry を有用なものにするには、既存の方法やモード、既存のツールや戦略からの「オンランプ」を提供する必要があります。 つまり、仕様の実装だけでなく、その応用も提供する必要があるのです。 実際には、既存の HTTP サーバーやクライアントに OpenTelemetry 計装を追加するライブラリや、MySQL からメトリクスをスクレイプして OTLP に変換する Collector レシーバーを配布する必要があります。
コミュニティが OpenTelemetry から得る価値の大部分は、コア SDK ではなく、計装ライブラリと Collector コンポーネントから直接得られています。
これらはコアコンポーネントと区別するために contrib リポジトリとして整理していますが、エンドユーザーにはこの区別は見えませんし、気にもしません。
ユーザーが求めているのは、動作する計装です。
メンテナーやプロジェクトリーダーにとって、安定性の目標と contrib の性質は大きな課題を突きつけます。
ユーザーは安定していて、十分にテストされ、パフォーマンスの良いリリースを求めています。
しかも、商用の計装エージェントと同等の機能を果たすことも期待されています。
目標と目的
大まかに言えば、この領域には3つのポイントがあります。
- すべてのリポジトリ（セマンティック規約を含む）のすべてのコンポーネントは、プログラムで検出および解析できるメタデータファイルや情報を通じて、安定性を伝達する一貫した方法に従うべきです。 正確なフォーマットは OTEP を通じて定義され、仕様に組み込まれるべきです。
- 安定性の要件を拡大し、ドキュメントとそのホスティング先、サンプルコード、パフォーマンスベンチマーク（該当する場合）、実装クックブック、その他必要な成果物に関する要件を含めるべきです。
- OpenTelemetry の安定したディストリビューションは、デフォルトで安定したコンポーネントのみを有効にするべきです。 ユーザーは、ドキュメント化された一貫した設定オプションで、希望する最低安定性レベルを選択できるべきです。
これらはメンテナー、特にライブラリの v1 以降をリリースした方にとって大きな変更となることは承知しています。 ディスカッションでこれらの目標に対するフィードバックをいただけると幸いです。
2. 計装の安定性とセマンティック規約
安定性の目標を達成するためには、セマンティック規約の安定性とプロセスにも対処する必要があります。
セマンティック規約の課題
セマンティック規約は、多様なテレメトリーシステムで機能する必要があるため、ゆっくりと慎重に進化します。 OpenTelemetry は相互接続されたシグナルが一緒に流れるように設計されていますが、ユーザーはこのデータを消費するためにさまざまなストレージおよび分析エンジンをデプロイします。 各バックエンドには独自の制約と機能があります。 メンテナーは、カーディナリティを管理可能に保つこと、属性が有用だが過度に特定的でないこと、データがどこに格納されるかに関係なく適切に機能する規約を作ること、といった競合する関心事のバランスを取る必要があります。
このことの欠点は、セマンティック規約の進展が遅くなりうることであり、この遅さは規約のすべての利用者に影響します。 多くの計装ライブラリは、実験的なセマンティック規約に依存しているため、現在プレリリースバージョンで止まっています。 外部のコントリビューターは、仕様にないテレメトリーを出力するか、長期的なコミットメントが必要なプロセスに参加するかの間で板挟みになっています。 さらに、プロジェクト内の計装間で内部的な一貫性がありません。 規約にマッピングされたライブラリもあれば、規約とは独立して存在するライブラリもあります。
計装と規約の目標
ここでの目標は、3つの成果を達成するように設計されています。
- 計装の安定性はセマンティック規約の安定性から切り離されるべきです。 本番環境で安全に実行できる安定した計装が多数ありますが、データは将来変更される可能性があります。 これら2つの安定性レベルを混同することは混乱を招き、選択肢を制限するとユーザーから聞いています。
- セマンティック規約はより連合的（フェデレーテッド）であるべきです。 OpenTelemetry がどの規約が存在するかの最終決定者であるべきではなく、拡張および構築可能なコア規約の作成に注力すべきです。
- セマンティック規約の開発と反復は、ディストリビューションのメンテナーにとってブロッカーになるべきではありません。
このため、仕様に盛り込みたいいくつかの推奨事項があります。 まず、OpenTelemetry における計装ライブラリに関する私たちの立場は、それらがセマンティック規約の具体的な実装として存在するということです。 これにより、ディストリビューションでサポートしたい「ファーストパーティ」計装ライブラリの具体的なターゲットが得られます。 加えて、メンテナーは既存の規約に沿った計装を優先し、そうでないものの優先度を下げるべきです。
次に、メンテナーが安定した計装をリリースしやすくしたいと考えています。 計装の API サーフェスが安定している場合、セマンティック規約の安定性がその計装ライブラリの安定化をブロックすべきではないと考えています。 これは、オペレーターが計装ライブラリの新しいメジャーバージョンにアップグレードする際に、テレメトリーの移行パスを慎重に提供する必要があることを意味します。
さらに、サードパーティが独自のセマンティック規約を公開しやすくするために、セマンティック規約の必要な部分を正式化し安定させたいと考えています。 これにより、他の組織が自社のライブラリ、フレームワーク、テクノロジースタックなどの規約を提供できるようになります。
これを実現するために、メンテナーやエンドユーザーからいくつかの領域についてフィードバックを求めています。 特に、セマンティック規約の成熟度やライフサイクル、そしてセマンティック規約のフェデレーションに関して何が不足しているかについてです。 ここでの提案にはより柔軟に対応しますが、目指す成果は変わりません。 プロジェクトの核となる目標は、他のライブラリ、ツール、フレームワークが OpenTelemetry をネイティブに採用することを促進することであり、セマンティック規約はその大きな部分を占めています。
3. 自信を持てる安定したリリース
課題
OpenTelemetry は、Kubernetes クラスターにデプロイされる単一のバイナリではありません。 計装ライブラリ、Collector レシーバー、SDK の異なるバージョン間で、設定からテレメトリー出力に至るまで微妙な違いがあり、導入者にとって大きな悩みの種となりえます。 加えて、多くのコンポーネントのリリース頻度が高いことが、エンドユーザー、特に Collector 周辺で大きな困難を引き起こしています。 エンタープライズのデプロイメントとアップグレードは、慎重に行われるものです。 チームには、私たちがリリースするペースで変更を検証しロールアウトするだけの帯域がありません。
リリースの目標と戦略
ここでの目標は、大規模な組織が OpenTelemetry をデプロイしやすくすることです。 多くの組織では「デプロイメント」と「アップグレード」が、セキュリティを含む異なるビジネスユニットや責任領域にまたがる多くのチームやステークホルダーが関与する簡単ではないタスクであることを念頭に置いてください。
現在の提案は、OpenTelemetry の「エポック」リリースのスケジュールを作成する責任を負う Release SIG の設立です。 これらのエポックバージョンは、プロジェクトの安定性要件を満たすテスト済みでドキュメント化された安定したコンポーネントのセットを指すマニフェストとなります。
これが簡単な取り組みでないことは明確にしておきます。 先述の取り組みが、これらのエポックリリースが従うべき多くの要件を伝えることになるからです。 メンテナーやコントリビューターの皆さんに申し上げたいのは、この取り組みは個々のコンポーネント、SDK、API のバージョニングやリリース方法を変更することを意図していないということです。 むしろ、安定性を必要とするエンドユーザーのために、テスト済みで安定した、うまく連携するリリースの組み合わせを提供したいのです。
エンドユーザーの皆さんには、現在どのようにアップグレードを管理しているか、この領域で何を求めているか、SDK と Collector の両方のデプロイメントとアップグレードにおける現在の課題についてフィードバックをいただきたいです。
今後に向けて
これらの変更は、クラウドネイティブソフトウェアコミュニティに対する OpenTelemetry の影響と重要性を反映しています。 OpenTelemetry は過去数年間にわたり CNCF で2番目に活発なプロジェクトであり、調査対象のクラウドネイティブエンドユーザー企業の約50%がこのプロジェクトを導入しています。 これらの変更は、私たちの成功の次の章を築き、真にユビキタスな存在となるための準備です。
プロジェクトとしてのミッションは変わりませんが、優先事項は変わります。
- すべての開発者とユーザーにとっての安定性と使いやすさ。
- 明確なパッケージング、インストール、使用方法のパス。
- 予測可能性と一貫性。
コントリビューターやメンテナーにとって、これは何を意味するのでしょうか。 これらの優先事項に沿った提案は迅速に進めます。 それに沿わない機能作業や計装がある場合でも問題ありません。 プロジェクトの外で取り組み、既存の統合ポイントやパターンがどこでうまく機能しないかを見つけてください。 それは有益なフィードバックであり、すべての人のために仕様を改善する助けとなります。
メンテナー、コントリビューター、インテグレーターの皆さんには、ここで挙げたトピックや提案について GitHub ディスカッションでフィードバックをいただきたいです。 feedback@opentelemetry.io にメールでフィードバックを送ることも、CNCF Slack の #opentelemetry チャンネルで共有することもできます。 来週の KubeCon でクラウドネイティブコミュニティの皆さんとお会いできることも楽しみにしています。 コメントをお持ちください！