KubeCon Chinaで訊いたOpenTelemetryのマージ裏話
KubeCon Chinaの会場で、OpenTracingとOpenCensusのマージに関わっているエンジニアにインタビューを行うことができた。OpenTracingとOpenCensusをマージした後継のプロジェクトOpenTelemetryについては、2019年5月にヨーロッパで開催されたKubeCon Europeで発表されたものだ。インタビューに応じてくれたのはSteve Flanders氏、シリコンバレーのステルスな状態にあるスタートアップ、Omnitionのプロダクト責任者だ。
参考:KubeCon Europe開幕、初日のキーノートではLinkerd、OpenTelemetryに注目
自己紹介をお願いします。
Steve Flandersです。現在はまだステルスなシリコンバレーのベンチャー企業Omnitionでプロダクトの責任者をやっています。主に監視やトレーシングに関するビジネスを立ち上げようとしています。以前は、VMwareでログ分析やメトリクスデータ収集に関する製品開発のリードをやっていました。そのため、OpenTelemetryについても私のキャリアの延長線にあると言えますね。Omnitionは、GoogleやMicrosoftと共同でOpenCensusの開発を行ってきました。特に我々が貢献したのは、OpenCensus Servicesという部分で、これはエージェントとしてメトリクスデータを収集する部分のソフトウェアになります。そして今回のマージに関しても、多くのコミュニティメンバーと一緒に仕様を検討したり、他の企業とのすり合わせを行ったりすることで、結果としてマージすることのコンセンサスがとれて、これから実行に移すという段階です。
OpenCensusとOpenTracingがマージされた意味についても少し深く解説してください。
これはKubernetesがインフラストラクチャーレイヤーに対して行ったことを、トレーシングについてもやろうということだと言って良いと思います。つまりメトリクス情報を取得し、それをバックエンドで加工するという部分においてオープンなスタンダードを作ることで、どのベンダーもそれを利用することができ、ユーザーも一つのベンダーに依存することがなくなります。OpenTelemetryが実現しようとしているのは、そういう状態です。Kubernetesは、すでにオンプレミスでもパブリッククラウドでも同じように使えますから、デベロッパーはKubernetesを理解していれば、どのプラットフォームでも使うことができます。OpenTelemetryもそのような状態を目指すということです。
OpenTracingとOpenCensusのマージについては2年間のバックワードコンパチビリティ、つまり過去のバージョンと互換性をとるということがバルセロナでも強調されていました。この背景は?
OpenCensusもOpenTracingもそれなりに大きなユーザーベースを持っていますし、多くのプロダクション環境で使われています。オープンソースソフトウェアだからと言って、バージョンアップを行ったら互換性がとれなくなるというのは、ユーザーにとってもデベロッパーにとっても良いことではありません。ですからOpenTelemetryにとっては、そういうユーザーを救うためにも互換性は大事になります。そしてその2年間のうちに、OpenTelemetryに移行して欲しいというのがコミュニティの思いです。
OpenTelemetryのゴールは?
短期的なゴールは、それは2019年の年末までという意味ですが、マージしたプロダクトをリリースすることですね。リリースできれば2つのプロダクト、つまりOpenCensusとOpenTracingのリポジトリはリードオンリーになります。つまり新しいコード変更ができないようにするという意味ですね。その後にOpenTelemetryとしてOpenTracingとOpenCensusがサポートしているすべての言語をサポートすること、それに旧バージョンからのブリッジをするというのが1年から2年後の目標です。バルセロナで発表したように、我々はリリースから2年間は旧バージョンのサポートを行いますし、そこからOpenTelemetryへの移行を支援します。それが短期的なゴールということになります。
一方長期的なゴールは、トレーシングとメトリクスにとって標準的なAPIを定めること、そして将来的にログに関しても同じように標準化されること、メトリクス収集を容易に組み込めるようにすること、組み込むためのフレームワークを増やすことですね。これが実現できれば、ユーザーは非常に簡単にメトリクスを収集することが可能になります。
KubeConではGrafanaがログのためのツールLokiを発表しました。またメトリクス収集~分析はそのままアプリケーションパフォーマンスモニタリング(APM)に向かうということも自然の流れだと思います。色々なプロダクトの機能が少しずつ重なっているように見えます。それに関しては?
LokiはGrafana Labsが発表したログを収集するオープンソースソフトウェアですが、Grafanaとペアで使うことを想定しているようです。Grafana for LogというのがLokiのキャッチコピーですからね。一方OpenTelemetryは一つのベンダーにロックインされるのではなく、さまざまなベンダーがその上でさまざまなソリューションを提供できるようにするというのが我々の考え方です。
ログは非定形の文字データであるのに対して、メトリクスは数値データと言う意味では大きく異なっています。その2つのデータにおいて重要なのは相関を見るという部分ですが、それに関して我々はLokiでもFluentdでも話し合うことは可能です。我々が誰かを拒むということはないと思います。色々な議論を重ねて良いプロダクトを作ることができれば、最終的にはデベロッパーやユーザーにとってのメリットになります。実際APMに関しても、多くのベンダーが興味を示しています。DynaTraceはOpenCensusにもコントリビューションしてくれていますし、彼ら以外にもOpenTelemetryがスタンダードを決めてそれを拡げるというのは、APMベンダーにとって良いニュースだと思っていると思います。
機能的に少し重なっているところがあるとすれば、それはOpenMetricsかもしれません。OpenMetricsはデータのスタンダードフォーマットを定義しようとしていますし、OpenCensusもデータのフォーマットを持っていますので、その部分では重なるでしょう。その部分についてもこれから議論が進んでいくと思います。
今はサーバーサイドのマイクロサービスにおけるトレーシングが注目されていますが、これからIoTデバイス、特に自動運転などの車輌についてもモニタリングやトレーシングが必要となってくると思いますが、エッジデバイスに対しての計画は?
これも今は議論の中心にはなっていませんが、エッジにおけるメトリクスという部分が必要とされれば、そのデバイスに合わせた言語やライブラリーなどが用意されるようになると思います。その時に重要となるポイントは、データのサイズやそれを取得するレイテンシーなどではないですかね。すでにいくつかのベンダーが、エッジからデータを集めてサーバーに集約するというソリューションを発表しています。そうなればOpenTelemetryとしてはそのデータを扱うのは容易だと思います。しかし先程も言いましたが、OpenTelemetryとしては誰かを拒否したり、どこかと独占的に関係を深めたりするということはなく、オープンに議論を行って開発を行っていく予定ですので、エッジでのトレーシングも将来は出てくると思います。
今回のマージについてですが、誰から話が出て、どのくらいでまとまったのですか?
もともとはOpenCensusでAPIの変更をやろうという議論が最初だったと思います。その時にOpenTracingのチームとも話し合って「車輪の再発明」は止めようということから進んだと記憶しています。あと一つ付け加えるとすれば、CNCFのプロジェクトで初めてマージを行うのがOpenTelemetryであるということですね。
あぁ、それは他のオープンソースプロジェクトにとっても参考になりますね。最後になりますが、最近のパブリッククラウドプロバイダーによるOSSへのフリーライド問題について何かコメントはありますか? ElasticやMongoDBが、彼らのソフトウェアをパブリッククラウドプロバイダーが使えなくするように契約条項を変えたという辺りの話です。
私はどちらの言い分も理解できますが、最終的にはオープンソースソフトウェアの文化が残ると思います。
Flanders氏自身が所属するOmnitionはまだステルスということで、どんなビジネスを展開するのかに関しての詳しい説明はなかった。基本的にはOpenTelemetryをバックエンドに、OmnitionがSaaSベースのサービスを提供するということになるようだ。「トレーシングのKubernetesを目指す」というのは、KubeCon参加者にとっては分かりやすい指針だろう。今後もOpenTelemetryに注目したい。