スマートトーク エピソード7：オブザーバビリティにおけるカーディナリティ、制御、コストのナビゲーション

このシリーズではオブザーバビリティと補完的なAIOpsの領域について何度か議論してきましたが、今回はより実践的な視点で、購買者のメンタリティを理解するためにトピックに深く潜ります。組織のCIOがオブザーバビリティソリューションを探しているとき、何を求めるべきか？ このエピソードでは、Stratolaのチーフアナリスト兼創業者ディネシュ・チャンドラセカールが、KloudfuseのCEOクリシュナ・ヤダッパナバールと対談します。クリシュナはオブザーバビリティを3つの要因—カーディナリティ、制御、コスト—のレンズで説明します。これら3つのCは、増え続けるオブザーバビリティデータの理解と管理の鍵です。これらの要因はデータ管理だけでなく、データとメタデータを追加分析に活用する上でも重要です。オブザーバビリティ分野の新たな展開は、特に生成AIを駆動するLLMのモデルオブザーバビリティです。3つのCはこの新興ユースケースにも適用されます。

このスマートトークエピソードでカバーされるトピック：

• オブザーバビリティデータの可能性
• ツール増殖
• サイロ化したオブザーバビリティデータの克服
• メタデータの考慮
• コストへの洞察

ゲスト
クリシュナ・ヤダッパナバール、Kloudfuse CEO
クリシュナ・ヤダッパナバールは統合オブザーバビリティプラットフォームKloudfuseの共同創業者兼CEO。以前、SpringPathを共同設立し、9400万ドルの資金調達とシスコによる3億2000万ドルでの買収を主導。20以上の特許を持ち、Veritas、Commvault、EMC、VMware、シスコでデータ、仮想化、ストレージテクノロジーに大きな影響を与えました。VMwareのVMFSを共著し、ESX Serverのストレージ仮想化スタックの重要コンポーネントを設計。また、データ、仮想化、クラウド、セキュリティ、AI/ML分野の新興スタートアップへのアドバイスと投資を行い、ビジョン、製品戦略、エンジニアリング、ゴートゥーマーケットに貢献しています。

ホスト： ディネシュ・チャンドラセカールはテクノロジーエバンジェリスト、思想的リーダー、ベテランIT業界アナリストです。約30年の経験を持ち、B2BエンタープライズソフトウェアとSaaS製品で、複雑なアーキテクチャを持つ顧客向けに洗練されたソリューションの提供とマーケティングに従事。LogicMonitor、Cloudera、Hortonworks、CA Technologies、Software AG、IBMなど様々な企業で、複数の高成長製品を市場投入するための非常に成功したGTM戦略の定義と実行を行ってきました。多作なスピーカー、ブロガー、週末プログラマーでもあります。サンタクララ大学MBA、マドラス大学コンピュータアプリケーション修士。現在は自身の会社Stratolaを経営し、顧客中心のビジネス戦略コンサルティングとフルスタックマーケティングサービスを提供しています。

リソース
スマートトーク エピソード6：AIOpsとIT監視の未来
スマートトーク エピソード5：オブザーバビリティスタックの分解
スマートトーク エピソード4：リアルタイムデータとベクトルデータベース
スマートトーク エピソード3：モダンデータパイプラインとLLM
スマートトーク エピソード2：Data-in-Motionを活用したGenAIアプリケーションの台頭
スマートトーク エピソード1：Data-in-Motionエコシステムランドスケープ
データインモーションエコシステムマップをこちらで閲覧
RTInsightsでデータインモーションについてこちらで詳細

トランスクリプト
ディネシュ・チャンドラセカール

こんにちは、Data in Motionリーダーシップシリーズのスマートトークへようこそ。このエピソードでは特別ゲスト、クリシュナ・ヤダッパナバールをお迎えしています。彼はCloud FuseのCEOです。スタートアップエコシステムの常連で、シリアルアントレプレナーです。これまでにいくつかの会社を設立し、私たちも温かくクリシュナを歓迎し、このシリーズでお気に入りのテーマであるオブザーバビリティについて会話します。

クリシュナ・ヤダッパナバール

ありがとうございます。

ディネシュ・チャンドラセカール

クリシュナ、自己紹介として、Kloudfuseと創業の動機について教えてください。

クリシュナ・ヤダッパナバール (01:01)：

もちろんです。ディネシュ、温かい紹介ありがとうございます。皆さん、私はクリシュナです。シリコンバレーでほぼ20年以上暮らし、多くのスタートアップと大企業で働いてきました。有名なのはVMwareで、初期スタートアップの頃に入社し、文字通り100万ドルARRに近いところから640億ドル企業へ成長するのを見ました。ファイルシステム、分散システム、データベース、OLAP、OLTPなど、さまざまなデータ関連テクノロジーに関わってきました。私のスタートアップSpringpathでは、ストレージ、ネットワーキング、セキュリティをすべて一つのボックスに統合するハイパーコンバージェンスを目指し、シスコに売却しました。

シスコで少し時間を過ごした後、次に来る大きなトレンドは何かと考えました。これは2020年初頭のことです。いくつかのトレンドに遭遇しました。開発者、DevOps、SecOpsに関するデータが指数関数的に増加しているトレンド。機械学習、AI、LLMモデルの新トレンドが市場をどう破壊するか（当時LLMモデルは初期段階）。人間の脳が特定のインシデントにどう思考し反応するかのように、マシンも同様に振る舞ってほしい。これらが私たちが直面した問題の一部で、これら3つの交差点で、オブザーバビリティだけでなく、開発者とDevOpsに焦点を当てたデータの上での分析と自動化の問題解決が非常に重要だと気づきました。それがKloudfuseの始まりにつながり、一つのことが別のことを導き、今では40人以上のチームになっています。

ディネシュ・チャンドラセカール (03:16)：

おめでとうございます、素晴らしいスタートです。その道のりで幸運を祈ります。オブザーバビリティについて話すと、これは昨日今日始まったことではありません。私もその分野でかなりの時間働きました。オブザーバビリティの概念は年々進化してきました。もともと10〜12年前はインフラ監視、ネットワーク監視などで盛り上がり、ゆっくりとクラウド監視、コンテナ監視機能が追加され、今日ではオブザーバビリティという概念がかなり一般的になりました。監視を謳っていたほとんどの会社が今やオブザーバビリティ企業です。あなたがオブザーバビリティ空間でゼロから始め、差別化を図ろうとしたことは知っています。この進化をどう説明しますか？ 以前と今の比較、どう進化を見てきましたか？

クリシュナ・ヤダッパナバール (04:09)：

素晴らしい質問です、ディネシュ。私も見てきました。モノリシックアプリケーションを物理マシンで実行する開発者として自分でコードを書いていました。それからVMwareやHyper-V、オープンソース仮想化テクノロジーなど仮想化の到来、コンテナ化が来ました。オブザーバビリティのデータにおける核心的問題を見ると、これらの進化に伴い、データに関連する属性が増え続け、それらのラベルが取り得る潜在的値のカルテシアン積を取ると、数百万〜数十億オーダーで非常に大きくなります。これがいわゆるカーディナリティ、データボリュームです。データボリュームが増えるにつれ、人々はデータAをデータBに変換してより良い分析をしたい、データ上で特定ワークフローを自動化したい、データをスライス&ダイスしてより良いインサイトを得たいと考えます。要するに、データボリュームが増えるにつれ、いわゆる「既知の既知」を監視する従来のやり方が通用しなくなり、これが従来の監視です。それから「既知の未知」を探るようになり、これがオブザーバビリティの始まりです。そして「未知の未知」が完全にあり、何も分からない状態でマルチテラバイト〜ペタバイトのデータに投げ込まれ、その中からより良い言葉がないが、問題が 정확히 어디にあるか、インシデントとどう相関するか、根本原因分析、影響分析を見つけ出さなければなりません。開発者がコードを書き続け、ますます多くのサービスが来る限り、この複雑さは高まり続け、新たな課題が出現し続ける進化し続ける領域です。

ディネシュ・チャンドラセカール (06:14)：

素晴らしい。オブザーバビリティは明らかに解決が難しい問題です。なぜ難しいかを探りたいですが、少し触れられましたね。しかし、ダース一杯のベンダーが「この部分のオブザーバビリティを解決、あの種類を解決」と言う混雑したマーケットプレースがあり、それでも理想的なソリューションを探し続けています。私が話すすべてのCIOは、この問題を魔法のように解決する一発逆転のソリューションを常に探しています。なぜでしょう？ それを理解するために別のレンズで見る必要があるのでしょうか？

クリシュナ・ヤダッパナバール (07:04)：

前の発言で示唆したように、少し立ち戻りましょう。顧客が理想的なオブザーバビリティソリューションを考えるとき、何を求めているか？ 問題から始めましょう。私はこの問題を3つのC—カーディナリティ、制御、コスト—に分類します。次のレベルの詳細に入りましょう。これら3つのCが何を意味するか？ カーディナリティは、トリッキーメトリックポイント、ログ行、イベント、トレース、分散トレーシングからのスパン、継続的プロファイルのプロファイルなど、特定のデータが追加の、より良い言葉がないが、ラベルやタグとともに付属することに関係します。それらのラベルが取り得る潜在的値のカルテシアン積を取ると、非常に高くなります。だから今、すべてのデータポイントがそのタグと関連付けられる必要があります。

タグをメタデータと呼びましょう。そしてデータがあります。スキームによって異なる問題があります。メトリクス側ではメタデータヘビー。ログやスパン、分散トレーシングに来るとデータヘビーですが、効果的にはカーディナリティによるオブザーバビリティデータボリュームの著しい増加です。最近、逆のトレンドを見ています。昔は「Hey、データをSaaSポータルに送れば、SaaSベンダーがすべて管理してくれる」と考えられていました。しかし、CTO、CIO、エンジニアリング責任者、開発者、アーキテクト、さらにはCFOと話すと、「自分のデータをコントロールしたい」と考えています。どういうことか？ さまざまな理由で—エグレスコストのリスク、セキュリティ面、データボリューム自体—膨大なデータがあるため、データを自分たちのVPC外に出したくないという逆トレンドが進行中です。

もう一つの角度があります。従来のオブザーバビリティ系インターフェース（ダッシュボード作成、アラート、SLO、SQLやGraphQLで書ける分析機能、Sparkジョブでオブザーバビリティデータ上で分析実行などの高度なもの）を含め、考えられるすべてのインターフェースを取り込みたい。オブザーバビリティがそれほど基本的な柱になったからです。つまり、データを所有しなければなりません。データはVPCを出てはいけません。私がデータと言うとき、取り込まれるデータ、クエリされるデータ、分析されるデータ、そして最後ですが決して軽視できないコストです。従来のSaaS商用ベンダーであれオープンソースコンポーネントであれ、どのベンダーに行っても、インフラコスト、ベンダーコストはデータボリュームに比例し、クエリ数に比例し、ユーザー数に比例します。これら3つが、理想的なソリューション、理想的なオブザーバビリティソリューションを探す従来の組織が抱える問題です。

ディネシュ・チャンドラセカール (10:24)：

カーディナリティ、制御、コスト。これがオブザーバビリティ空間を見る、実際のユーザーにとって何が重要かを推測する素晴らしい方法だと思います。コストについて触れたので、この質問もしたいです。私の個人的経験から、オブザーバビリティソリューションを探している顧客と話すと、「Hey、各部門で少なくとも8〜10の異なるツールがある。組織全体で30〜40ツールを見ている。毎年これらのライセンス費用で既に多くのコストがかかっている。『なぜさらにもう一つオブザーバビリティソリューションが必要なのか』というプッシュバックを受けました。同じ質問を、コストの側面に触れた今、あなたに投げかけます。CIOにどうアプローチし、なぜこれが30〜40の異なるツールを持つより良いかを説得または伝えますか？

クリシュナ・ヤダッパナバール (11:23)：

素晴らしい質問です。なぜツール増殖が起きるかという問題から始めましょう。エコシステム全体を見ると、伝統的に一部の商用ベンダーは特定のストリームで優れていました。ログならSplunk。メトリクスならDatadog。Googleや世界のFANG企業内部では、Kubernetesの登場とともにオープンソースムーブメントが始まり、Prometheus、OpenTelemetryなどが登場しました。

これはオープンソースベースのソリューションへのシフト全体が進行していることを意味します。どういう意味か？ 開発者、アーキテクト、DevOpsの人々が、オープンフォーマットでオブザーバビリティデータを取り込みたいということです。つまり、コードを計装するどの計装を選んでも、エージェントでデータ収集しても、それが100%オープンソース互換であるべきだということです。だから商用ベンダーもエージェントをオープンソースにし始めました。クエリ側では、可視化、ダッシュボード、アラート—これらすべての機能がオープンソースクエリ言語で駆動されることを望みます。だからPromQL、LogQL、TraceQL、OpenTelemetryの出現、今ではもう一つのオープンソースクエリ言語を試みています。

だから今、多くの選択肢がある世界にいます。顧客は特定のストリームに特定のベンダーをすでに選んでいます。

オープンソースムーブメントがあり、異なるチームが異なるインフラを使用。一部はKubernetesベース、一部はサーバーレス、一部はECS、Fargateなど。これが別の次元を加え、製品デリバリーの速度と俊敏性を得るために、CI/CDがこの交差点で問題を非常に速く解決するよう進化しました。ポイントソリューションを探そうとし、結果として非常にポイントソリューションを選んでしまいます。私たちが理想的なオブザーバビリティソリューションとして、自社のオブザーバビリティスタックを始めるとしたら、一歩引いて「Hey、MTTRとMTTDを減らしたいなら、オブザーバビリティデータのすべてのエンドストリームを収集する必要がある。n個の異なるベンダーに行ってn個の異なるストリームを拾うか、オブザーバビリティデータレイクに行ってすべてのストリームを一緒に置くか、相関、外れ値検知、異常、因果関係のような高度な機能が比較的容易になるか？」そのようなデータレイクでデータを自社プレミス内で保存しながらすべてを統合できるのが理想的なソリューションです。

ディネシュ・チャンドラセカール (14:18)：

素晴らしい。ツール増殖のコストについても付け加えたいと思います。開発者が自分のものを構築したがり、多くのオープンソースツールもミックスに加わったことは大きく同意しますが、部門レベルでの購入もあります。IT部門が「この問題を解決できる、バンドエイドソリューションを買って使おう」と感じ、棚からツールを買います。時間が経つと、気づかないうちに武器庫にツールを一つ追加し、木を見て森を見ず状態になります。CIOとの会話は常に興味深く、企業全体でツール数を圧縮・削減し、部門横断、アプリケーション横断、インフラ、コンテナなどを見渡す一つのオブザーバビリティプラットフォームを持つ方法についてです。

クリシュナ・ヤダッパナバール (15:08)：

まったくその通りです。今、会社の異なるペルソナも同じデータを見ています。DevOps開発者、アーキテクトがインフラ、コンテナ化、アプリケーションに関するオブザーバビリティデータを見ています。同じログを使って。SecOpsの人々がセキュリティと脅威を探るためにデータを解剖しようとしています。ログやトレースから来る類似データを見ています。DataOpsの人々も「Hey、私のデータオペレーションはどの程度良いか？」と見ています。そして今、LLMの登場で、LLM Opsの人々も類似データを見て自分たちの種類の分析をしています。だから、別の統合が必要です。理想的なオブザーバビリティソリューションで私が見るべきことは、組織のすべての異なるペルソナをどう取り込み、彼らがいわゆるデータレイクから同じデータを活用できるようにするかです。

ディネシュ・チャンドラセカール (16:05)：

まさに私たちが皆目指してきたことわざの「シングルペイン・オブ・グラス」です。良いことです。前の回答で簡単に触れられたもう一つのことに触れたいと思います。MTTR削減についてです。オブザーバビリティの主要な核心として、トラブルシューティングだけでなく、MTTR削減、アラートノイズ削減などのメトリクスもあります。これはSREとIT Opsが髪を分けてトラブルがどこにあるかを突き止めるのを確実に救う、重要な基本要件です。リアルタイムイベントにアクセスできる必要があります。特定のアプリケーションやサーバーで悪意のあるアクティビティについてのログが記録された場合、そのイベントにすぐにアクセスして、異常がどこにあるか、インフラ全体で何が起きているか、なぜ特定のメモリスレッドで特定のスパイクが起きたかを理解する必要があります。

それを突き止める必要があり、そのためにはすべてをリアルタイムで取り込む能力が必要です。データ即時性—私が昨年好んで使ってきた用語—とデータ鮮度が、ここで最重要です。オブザーバビリティのこの特定の文脈では、データがどれだけ新鮮か、どれだけ速くその特定の問題を解決できるか、あるいはこの文脈で起きようとしていることを回避できるか、特に数百〜数千のサーバーを監視しているとき、どこにピンポイントで「ここにトラブルがある」と言えるか、データを可能な限り新鮮にする、またはそうでないかについて、どう考えますか？ 取り込みメカニズムに大きく依存しますか？ TELや他の計装技術についても話されました。この観点から、いかにしてリアルタイムデータに速くアクセスできるか、どう考えたり見たりしますか？

クリシュナ・ヤダッパナバール (18:03)：

オブザーブチームのもう一つの素晴らしい側面です、完全に正しい、ダネシュ。オブザーバビリティデータが消費される重要な次元は、データがソースを離れた瞬間からどれだけ速くデータを持てるかです。アプリケーション、インフラコンポーネント、オープンソースコンポーネントのようなプラットフォームなど、データのソースが何であれ。過去5〜10年で業界がどう進化したかを見ると、リアルタイムストリーミングサービス、リアルタイムデータベースが登場しました。従来のオブザーブソリューションを見ると、テクノロジーが比較的古かったため、それらの機能を活用できませんでした。リアルタイムストリーミングとリアルタイムデータベースの登場により、データへのアクセスを可能な限り速く得られます。それが、データがアプリケーションを離れた瞬間からクエリ可能になるまでの、いわゆるデータ鮮度の測定基準です。それがすべてです。

次に、「Hey、すべてのデータがある。どうコンパートメンタル化する？ 関連パターンを見つけて根本原因にたどり着くには？」という問題セットがあります。つまり、データをあるデータから別のデータに変換できる必要があります。ログのシリーズを取得。そこからメトリクスを素早く見れるか？ スパンのシリーズを取得。そのスパンやトレース内の属性を見てデータを分析できるか？ これらの属性は通常相関しており、それがデバッグの仕組みです。これが次の次元です。そして3つ目の次元は高度な分析。そのデータの上で、興味深い統計的または大規模言語モデルを持ち込み、システムのいわゆる外れ値を見つける分析ができるか？ システムの異常を見つけられるか？ データの季節性を見れるか？ 過去から見たものに基づいてデータを予測できるか？ データの季節的側面？ これらすべてが私が高度な分析のパッケージと呼ぶものです。データの鮮度の問題が解決されたら、データをレンガの単位として考え、各レンガをどう調整し、分析関数のセットをどうするか。そして自然なことは「Hey、これを一度分析した、自動化できるか？」になります。それが全体への自然な拡張になります。だから3つのCの問題とともに、顧客が「どう観測し、分析し、自動化できるか」を尋ねるのを見てきました。

ディネシュ・チャンドラセカール (20:57)：

とてもクール。とてもクール。そして回答の一部として、魔法の言葉LLM、大規模言語モデルも言及されました。最近はGenAI LLMなしで会話できません。言及いただけて嬉しいです。LLMオブザーバビリティについて聞けます。LLMが至る所に普及し、人々がそれらのパフォーマンス理解に苦労している中、突然現れた新興領域のようです。それについて教えてください。Kloudfuseもそのフロントで何か構築しているようですね。詳しく教えてください。

クリシュナ・ヤダッパナバール (21:32)：

はい。根本的に、LLMモデルがさまざまなユースケースでデプロイされています。より良い言葉がないが。特にオブザーバビリティ世界ではデータが非常に動的です。特定の操作を行う適切なLLMモデルを構築するのは常に難しい。私たちは2つの方法で問題を見ました。既存のオブザーバビリティデータの上で特定のLLMモデルをどう活用できるか。DevOps、SecOps、DataOps、LLM Opsの人々など、私が話したさまざまなペルソナによって消費されるデータ。これが一つの側面。もう一つの側面は、「Hey、LLMが非常に重要なコンポーネントであるアプリケーションを開発している。データを生成するアプリケーションの完全なオブザーバビリティをどう見るか、それがLLMに供給され、それらのLLMモデルからデータを消費する多くのコンシューマーがいる。」

私たちは、実はLLMモデルを使用して開発されたすべてのアプリケーションの真のオブザーバビリティをエンドツーエンドで考える最初の存在だと言えます。モデルオブザーバビリティだけ、ドリフトなどを見るソリューションをたくさん見てきました。しかし、私たちはエンドツーエンドを見ています。それは非常に興味深い側面です。インフラストラクチャ、アプリケーションのオブザーバビリティがモデルオブザーバビリティとその他と共に進みます。最後に、どのCIOやCFOに聞いても、LLMのコスト、現在のソリューションではコストがもう一つの重要な次元です。そのコストをどう抑えるか、あるいはLLMモデル自体のコストメトリクスについて分析を提供するかは別の側面です。パフォーマンス、LLMアプリケーションのAPMと呼ぼう、そしてコスト。これらが見るべき典型的な次元です。

ディネシュ・チャンドラセカール

とてもクール、エキサイティングな領域で、今後数ヶ月でその分野に何が来るか definitely excited です。本当にありがとう、クリシュナ。これは非常に素晴らしい会話でした。オブザーバビリティについて話すのが大好きでした。あなたの3つのC：カーディナリティ、制御、コストを覚えておきます。オブザーバビリティを見る素晴らしい方法、素晴らしいマントラだと思います。すべてのインサイトに感謝。ここにいてくれてありがとう。ありがとう。

クリシュナ・ヤダッパナバール

ありがとう、ディネシュ。あなたのウェブチャットに招待してくれてありがとう。