エラスティック Status update

Elasticでインベスター・リレーションズ担当バイスプレジデントを務めるアレックス・カーツマンです。本日は、当社の新しいメトリクス製品について詳しくご説明するためにお集まりいただき、ありがとうございます。本日は、オブザーバビリティ担当ゼネラルマネージャーのバハ・アザーミと、セキュリティおよびオブザーバビリティ・ソリューション担当シニア・バイスプレジデントのサントシュ・クリシュナンも参加しています。本日の議題ですが、まずバハから簡単なプレゼンテーションを行い、その後、短いお客様向け動画をご覧いただき、最後に質疑応答を行います。まず、法的免責事項について簡単にご説明します。本日のプレゼンテーションには、将来予測に関する記述が含まれます。これには、市場および当社の製品・ソリューションに対する需要に関する予測や見通し、ならびに当社の製品・ソリューションに期待される機能が含まれる場合があります。

これらの将来予測に関する記述は、現時点で当社が把握している要因に基づくものであり、本プレゼンテーションの日付時点でのみ有効です。また、実際の結果が大きく異なる可能性のあるリスクや不確実性の影響を受けます。当社は、法律で義務付けられている場合を除き、これらの将来予測に関する記述を更新または改訂する義務を負いません。こちらに記載したリスクおよび不確実性に関する免責事項、ならびに米国証券取引委員会への提出書類でより詳しく説明している内容をご参照ください。それでは、バハに引き継ぎます。

ありがとうございます、アレックス。次のスライドに移ります。移ることができればですが。はい。皆さん、こんにちは。バハです。Elasticでオブザーバビリティ担当ゼネラルマネージャーを務めています。私はElasticに11年間在籍しており、本日、当社の新しいメトリクス製品についてご説明できることをうれしく思います。当社の新しいメトリクス製品は、6月の会計年度開始直後にローンチされました。この新しいメトリクス製品で当社が実現したのは、お客様の要件を満たすだけでなく、市場で最高水準のメトリクスソリューションの一部を上回るソリューションによって、この市場に参入したことです。どのように実現したのかは、このプレゼンテーションでご説明します。

大まかに言うと、メトリクス向けにElasticsearchを再設計しました。また、お客様が現在利用している環境に合わせるとともに、お客様が今日取り組んでいること、つまりAIワークロードを見据えてメトリクスソリューションを構築するよう徹底しました。メトリクスソリューションには3つの特徴があります。第一に、非常に高速であることです。メトリクス市場に参入するのであれば、高速でなければなりません。これはソリューションにおける指針の1つです。PrometheusやMimirなどの競合ソリューションとベンチマークを比較しました。数値については、このプレゼンテーションの後半で詳しくご説明します。もう1つ当社が実現したのは、お客様が当社でログ、トレース、メトリクスを扱っている場合に、あるソリューションから別のソリューションへ移行する必要がないようにしたことです。お客様は同じプラットフォームを使い続ける必要があります。データストアも同じであるべきです。

オブザーバビリティを実施する際に、これらすべてのシグナルを当社で保存することも、Elasticでデータをクエリすることも、当社が提供するオブザーバビリティ向けのさまざまなエクスペリエンスを利用することも、お客様にとっては完全にシームレスです。すべてが同じプラットフォーム上にあります。最後に、AI向けに構築しました。従来のアプリケーションよりもエージェントが多くなり、AIによってワークロードの形態が変化する中で、以前よりもはるかに多くのシグナル、データ、メトリクスが生じています。そこで当社は、新しいタイプのワークロードに対応できるよう、メトリクスソリューションを可能な限り効率的にすることを考えました。ただ、当社が実現したことの詳細に入る前に、皆さんとの認識を合わせておきたいと思います。メトリクスについてなじみがない方のために説明すると、メトリクスはオブザーバビリティにおける主要なシグナルです。インシデントが発生したときに、文字どおりエンジニアを午前3:00に起こすものです。

朝、確認すべきことが発生した際に、人々に通知するものです。したがって、オブザーバビリティのソリューションを利用する際には、ルールを作成します。それらのルールがアラートを発報しますが、その99%はメトリクスに基づいています。ここで、画面にいくつか例を示しています。アプリケーション、つまりウェブアプリケーションがあり、そのアプリケーションのトラフィックを確認しているとします。例えば、HTTPリクエスト数を確認します。このアプリケーションは、インフラストラクチャ、つまりアプリケーションスタックに依存しています。そこにはさまざまなテクノロジーが関わっており、このアプリケーションに割り当てられたリソースがあります。したがって、CPUなどのリソース使用率を確認します。また、このアプリケーションを通じて公開しているAPIに送られるリクエストのレイテンシーなども確認できます。このように、アプリケーションの特性の多くがメトリクスを生成します。

アプリケーションもインフラストラクチャも、メトリクスを生成します。オブザーバビリティのソリューションがそれらのメトリクスを取得し、アラートを発報するルールを作成すると、その後、人々に通知が送られます。変化した点は、従来型のアプリケーション、例えば銀行のアプリケーションを見ると、ユーザーとして自分の銀行口座にアクセスし、明細を確認し、明細をスクロールして項目をクリックするという点です。これらはすべて、非常に従来型のアプリケーションにおける、あらかじめ定義された経路とトランザクションです。フロントエンド、バックエンド、データストア、データベース、マイクロサービス、クラウドへのデプロイがあります。私はこれらすべてを、従来型のアプリケーションというカテゴリーに入れています。つまり、そうしたトランザクションがよく知られているだけでなく、先ほど申し上げたように、トレース、ログ、メトリクスも生成されます。そのため、予想できる一定のボリュームがあります。

しかし、エージェントの場合は大きく異なります。AIによって、メトリクスが爆発的に増加しています。AIと言うとき、異なる種類のワークロードや、観測する必要があるものについて考えてみてください。例えば、LLMの呼び出し、GPUサイクル、RAGクエリ、エージェント、ハーネスなどです。これらすべてが、収集する必要のある新たな一連のオブザーバビリティシグナルを生み出しています。課題は、皆さんもご存じのとおり、LLMとやり取りすると推論ステップが発生し、その推論ステップは何を要求するかによって変わることです。そこからツールの呼び出しへと進みます。そのツールが事前に把握されているとは限りません。ここでは、エージェントがMCPを介して従来型のアプリケーションを呼び出すことになりますが、エージェントとのやり取りが何ターンになるかは、実に予測できません。その結果、顧客は新たなパラドックスに直面することになります。

まず顧客は、これほど大量のデータにどう対処するのかを考えなければなりません。顧客にコスト負担を強いるソリューションが存在し、すべてのデータを保持できていないことは、私たちも把握しています。この問題により、顧客はやがて盲点を抱えるようになります。保持できるデータ量について、妥協しなければなりません。そしてインシデントが発生したとき、何が起きたのかを完全な精度で把握できなくなります。根本原因を理解することが難しくなります。AIによる新たな課題です。この新しいメトリクス製品をどのように市場に投入するかを考え始めたとき、いくつかの基本方針を定めました。これらについては、後のスライドでさらに詳しく説明します。

第一に、メトリクスを保存する新しい方法を導入しました。単に保存するだけでなく、管理も行える方法です。これには、データを自動的に集約したり、ダウンサンプリングしたり、圧縮したりする機能が備わっています。第二に、メトリクスソリューションのユーザーがElasticにアクセスして当社のメトリクス製品を利用する際に、使い慣れた感覚を持てるようにしたいと考えました。市場標準であるPromQLなどのサポートに特に力を入れています。その点については、これからご説明します。最後に、繰り返しになりますが、AIのスケールに対応できるように構築しました。AIによって、観測すべきデータや新たな対象が増えていることをご覧いただきました。そのワークロードに対応するために必要な効率性を備えた形で、これを構築しています。皆さまは、おそらくログについてElasticをご存じだと思います。お客様は、扱いの難しいログを当社にお任せくださっています。そのような非構造化データをすべて受け入れられることを、当社は大変うれしく思っています。

当社の中核は検索エンジンですので、構造化データにも非構造化データにも非常に適しています。ログが流れ込んできて、ドキュメントストアに格納されます。そこからフィールドを抽出し、集計に利用できるようにします。そのデータに対して全文検索を行うこともできます。これが、ログに関する当社の取り組みと、その実現方法です。当社はドキュメントストアを使用しています。メトリクスについては、ログとは形が異なるため、状況が大きく異なります。メトリクスには数値があり、ラベルが付いています。例えば、CPU使用率を表す数値のようなものです。タイムスタンプがあり、ディメンションがあります。それは、あるホストに属しています。そのホストは特定のKubernetesポッド上にデプロイされ、そのポッドは世界のある地域にデプロイされ、さらにその地域は特定のクラウドプロバイダー上にデプロイされています。その他にもあります。このように非常に多くの異なるディメンションがあります。メトリクスに対応するため、当社はElasticsearchを完全に再設計しました。

メトリクスには固有の課題があるため、Elasticsearch内にカラムストアを構築しました。先ほど、ディメンションについてお話ししました。第一に、ディメンションは、市場にある既存のメトリクスソリューションにとって、管理が非常に難しいものです。当社は、カーディナリティの面でお客様に制約を設けないようにしたいと考えました。これは、市場にあるメトリクスソリューションについて、皆さまが頻繁に耳にする言葉です。カーディナリティには制約を設けたくありません。ディメンションはいくつでも設定できます。そこでそのように説明すると、ユーザーは「分かりました。それでは、クエリではどのような処理になるのですか」と尋ねます。ディメンションが多いと、メモリ上ですべてのデータを管理するのが難しくなるからです。

カラムストアは、非常に優れたアーキテクチャを備えており、メトリクスに非常に適しています。例えば、30個のディメンションがあるとします。クエリで30個のディメンションを処理することには、それ自体に課題があります。30個のうち2個のディメンションを指定する場合、その2個のディメンションだけを取り出し、残りの28個についてはデータを解析する必要がないようにする必要があります。そのため、メモリ上でいくつかの課題が生じますが、当社ではディメンションフィルターのような技術によって実際に解決しています。また、コーデックをチューニングすることで、ストレージ上のデータをどのように管理し、効率性を確保するかという点も解決しています。当社のカラム型データストアがクエリ処理とストレージの両方で効率的になるよう、可能な限り多くの技術を活用しています。その成果は数字に表れています。当社ではベンチマーク結果を文書化しています。結果はオンラインで公開しています。GitHubでオープンソースコードとして提供していますので、実際に実行して数字を検証できます。