KubeCon Europe 2025、DynatraceのDevRelにインタビュー。F1でも使われているオブザーバビリティとは？

KubeCon Europe 2025から、オブザーバビリティのDynatraceのデベロッパーリレーションの担当にインタビューを実施した。オーストリアのリンツで創業されたDynatraceにとって、KubeCon Europeはホームコートといったところだろう。今回のショーケースでは最小の規模のブースを用意していたが多くの参加者が訪れていたようだ。インタビューに応えてくれたのはAndreas Grabner氏だ。

ブースの前でポーズを取るGrabner氏（中央）

最初に自己紹介をお願いします。

Grabner：私はデベロッパーリレーションとしてDynatraceのプロダクトと顧客を繋ぐ仕事をしています。Dynatraceのプロダクトは単に本番環境のオブザーバビリティと言うわけではなく、APMの領域もカバーしていますので、アプリケーション開発者にDynatraceのテクノロジーを認知してもらうことも私の役割のひとつですね。Dynatraceには17年前の2008年に入社しました。Dynatrace自体は2005年創業ですので、もう20年ということになりますね。CTOのBernd GreifenederとはDynatraceの前の会社で一緒に仕事をしていましたので、関係は深いですね。

クラウドネイティブに限らず多くのソリューションがオブザーバビリティの領域に存在します。SaaSだとDatadogやNew Relic、Splunkなどが競争相手になりますが、違いは何ですか？

Grabner：私は17年もDynatraceにいるので自社のソリューションには詳しくても他社のテクノロジーにはそれほど詳しくありませんが、各社のオブザーバビリティはそれぞれ出発点があると思います。Dynatraceはトレーシングから開発し始めました。New Relicはメトリクス、Splunkはログが出発点だと思います。そこから各社が買収などを通じてソリューションの領域を拡げていっています。

ただオブザーバビリティのベンダーが後回しにしていることのひとつに、集めたデータを管理するデータストアがあります。オブザーバビリティのツールやダッシュボードを先に開発し、収集したデータを収めるデータストアについては既存のオープンソースソフトウェアを使うというのがよくあるやり方です。しかしこの方法ではオブザーバビリティで集めたデータを最適化できません。Dynatraceは2022年にGrailというデータレイクハウステクノロジーを発表しました。これが現在のDynatraceのソリューションのコアになっています。ログやメトリクスなどがそれぞれのデータストアを使うのではなく、すべてのオブザーバビリティデータを統合しマッシブパラレルプロセッシング（MPP）で処理可能なデータレイクストアシステムです。Grailによってすべてのデータが集中的に管理され、統合され意味のある情報になります。

もうひとつ挙げるとすれば、ソフトウェアベンダーは買収によってソリューションを拡大していきますが、往々にして既存のプロダクトにボルトオンする、後付けする形になります。つまり同じ会社からリリースされているとしても、実際には別々の製品として分かれていることもあり得るわけです。Dynatraceは2023年にRookoutというアプリケーションセキュリティのベンダーを買収しました。2024年にはRunecastというチェコのコンプライアンスに関するソリューションを開発するベンダーも買収してポートフォリオを拡げていますが、どれも単に後付けするのではなくプラットフォームとして統合することに時間をかけています。

企業のコンプライアンスに関する機能をオブザーバビリティに追加するというのは新しい発想だと思いますが？

Grabner：企業は単にシステムのモニタリングをすることでは満足していないと思います。我々はもっと深いレベルでオブザーバビリティを実現したいと思っています。例えば、アプリケーションに加えた修正が原因で障害が発生したとします。このような場合、単にアプリケーションを前のバージョンに戻せば良いというのが従来の発想だと思いますが、実際にはその修正を行ったプルリクエストは何だったのか？ どういう状況で行われたのか？ などを検討する必要があります。そのためには開発段階から「何が行われていたのか？」を知る必要があります。ですのでDynatraceは本番環境にだけオブザーバビリティを入れるのではなく、もっとシフトレフトして開発プロセスからオブザーバビリティを入れるべきだと考えています。

もうひとつの発想はシステムのオブザーバビリティではなく、ビジネスのオブザーバビリティが必要だということですね。我々の顧客にレストランチェーンを営んでいる企業がありますが、彼らは新型コロナによるパンデミックの際に料理を配送するビジネスに進出しました。典型的な使われ方はスマートフォンから顧客がオーダーを送って料理がキッチンで作られて完成した料理が外部の配送ベンダーによって届けられるというものですが、自社のシステムだけを見ていても顧客が満足したのか？ はわかりません。つまりオーダーを受けるシステムが正常に稼働しているか？ だけでは顧客の満足度は測れないのです。配送ベンダーが請け負って配達され、最後に顧客はその料理について評価します。料理は美味しかったが配達に時間がかかって冷たくなってしまった、そういう時に単に自社のシステムだけをモニタリングしていても意味がありません。そのためには外部のベンダーからのデータと連携する必要があります。つまり配送にかかった時間、顧客が最後に評価したデータ、そういうデータも総合的に見ないとビジネスのオブザーバビリティは実現できません。そこまでをトータルに観測するということが必要なんです。そのためにはシステムのデータだけではなくビジネスの中で使われるデータもGrailの中で処理される必要があります。

これまでのオブザーバビリティは本番環境をモニタリングすることで問題を解決するという発想でしたが、Dynatraceはその本番環境を作る前の環境、つまり開発環境にもオブザーバビリティを取り入れて問題が起こる最初の段階に何が起こったのか？ を知ろうという発想ですね。

Grabner：そうです。でもすべてのデベロッパーが大量のメトリクスやトレーシングデータを見る必要はありません。Grailを使うことで関連する必要なデータだけを提供することができます。すべては繋がっているので、本番環境だけを見ても本質的な解決にはならないと考えています。

最後にチャレンジはなんですか？ 日本市場に対してでも会社全体についてでもいいですが。

Grabner：私個人は日本に行ったことがないので日本の市場はよくわからないというのが正直な感想です。日本に一度は行ってみたいと思っているので、6月に行われるKubeCon Japan 2025のCFPにもセッションの案を出しましたが、残念なことに通りませんでした。でも他のDynatraceのエンジニアが東京でセッションを行うので、皆さんはぜひ参加して欲しいと思います。ビジネスという意味ではグローバルな視点で見ればどの国、地域でもシステムやビジネスを観測したいという想いは変わらないので、日本だからと言って顧客が求めるソリューションに違いはないと思います。会社はオーストリアで起業したので、ヨーロッパには大きな存在感を示していると思いますが、これからは北米、そして日本にも積極的に展開をしていきたいと思います。

共著者となっている「Platform Engineering for Architects」にサインをするGrabner氏

最後にGrabner氏が共著者となっている「Platform Engineering for Architects」という書籍にサインをして筆者にプレゼントしてくれた。本番環境のオブザーバビリティだけではなく、すべては開発プロセスから始まっていると考えると、ソースコードを作る段階から誰が何をしたのか？ その背景は何なのか？ までを含めて観測するというのは新鮮な考え方だろう。本番環境のオブザーバビリティダッシュボードとGitリポジトリのログを分けて考えるのではなく、すべてのプロセスが繋がっているという発想から開発中のプロセスに関するデータをオブザーバビリティに取り込むということは、理に適っているように思えた。

なおDynatraceはフォーミュラワンのVisa Cash App Racing Bulls（VCARB）チームのシステムのオブザーバビリティを担当している。VCARBはOracle Red Bull Racingチームの兄弟チームとして、日本人ドライバーの角田裕毅がRed Bullに昇格するまで所属していたチームである。Red BullもDynatraceもオーストリアが創業の地であることから親和性が高いのかもしれないが、フォーミュラワンというリアルタイム性を要求される極限の環境で使われていることは、エンタープライズ企業にとっては良い宣伝となるだろう。

●参考：Dynatrace Partners with Visa Cash App Racing Bulls (VCARB) Formula One? Team as its Official Observability and Performance Analytics Technology Partner