OpenSearchCon North America 2025のキーノートの「Advancing Search and Observability at Uber with OpenSearch」をまとめます。
www.youtube.com
資料
https://static.sched.com/hosted_files/opensearchconna2025/62/Shanshan%20Song%20V3.pdf
スピーカー
- Shanshan Song
Uberと検索プラットフォームの役割
Uberは配車サービスでよく知られていますが、配車サービス以外にもUber EatsやUberデリバリー事業も提供しています。
Uber Eatsはオンラインフードデリバリーサービスで、顧客はレストランの食べ物や食料品をドアまで届けてもらうことができます。
UberとUber Eatsの両方において、検索プラットフォームは非常に重要な役割を果たしています。私たちは検索を使ってリアルタイムのドライバーと乗客のマッチングを行っています。顧客は検索を使ってモバイルアプリケーションからメニューを見つけたり閲覧したりします。検索はUberのリアルタイムオペレーションとビジネス全体の成功にとって非常に重要です。
検索プラットフォームは、住所検索、配達地点の特定、フィード、検索など、様々な検索機能を支えています。これらすべてが統合された検索プラットフォームによって実現されています。
セマンティック検索の採用
従来、私たちは語彙検索またはテキスト検索を利用していましたが、語彙検索にはいくつかの制約があり、それだけでは必ずしも顧客の要件を満たすことができないことに徐々に気づきました。
たとえば、モバイルアプリで「ビーガン、グルテンフリーバーガー」と入力した場合を考えてみましょう。理想的にはビーガンかつグルテンフリーのバーガーを検索したいのですが、語彙検索では「ビーガン」「グルテンフリー」「バーガー」を個別に扱うため、検索結果にはビーガンデザート、グルテンフリーパン、そして肉ベースのバーガーのようなものが返ってくる可能性があります。これでは顧客は非常にがっかりしてしまいます。
この問題を解決するために、私たちはセマンティック検索テクノロジーを採用しています。セマンティック検索は、検索クエリの背後にある意図と文脈的な意味を理解できます。食事制限と食品カテゴリの組み合わせを理解し、概念全体を意味的に表現するリストとマッチングします。その結果、植物ベースでグルテンフリーのバーガーを提供する、非常に関連性の高い店舗を表示できるようになりました。
セマンティック検索は、非常に関連性の高い検索結果を提供し、最終的に検索コンバージョン率を向上させ、Uberのビジネスをより成功させることができます。私たちのビジョンは、検索クエリの背後にある意図と文脈的な意味を使用して関連性の高い結果を提供し、Uberのビジネスを改善するエコシステムを構築することです。
セマンティック検索のアーキテクチャ
セマンティック検索のアーキテクチャについて詳しく説明しましょう。前提としてセマンティック検索はすべてembeddingに支えられています。
私たちのユースケースでは、店舗とアイテムに基づいて検索インデックスを構築しています。店舗とアイテムの入力に基づいて、embeddingモデルをトレーニングしています。そして、そのモデルをストレージ検索システム、つまり検索インデックスに取り込みます。
ユーザーがモバイルアプリケーションにアクセスしてアイテムを探そうとすると、携帯電話にテキストを入力します。このユーザーのクエリに基づいて、リアルタイムでクエリのベクトルも生成されます。私たちはこれを検索に用いることで、より良いクエリ結果を出すことができます。
私たちのアーキテクチャは、古典的な2フェーズモデルを採用しています。
第一段階：Retrieval
粗粒度の検索モデルを使用します。このモデルは、数十億のアイテムからなるすべての検索インデックスを検索し、これらの数十億のアイテムの中から数千のアイテムに絞り込みます。
第二段階：Ranking
よりきめ細かいモデルを適用し、これらの数千のアイテムの類似性をさらに並べ替えることで比較します。最終的には、これらを数十のアイテムに絞り込み、UIに表示します。
また、検索ユーザーエクスペリエンスを継続的に改善するために、フィードバックループが組み込まれています。LLMを活用し、ユーザー入力とユーザーのクリックによるコンバージョン率に基づいてさらにトレーニングを行います。この微調整されたトレーニングモデル（フィードバックループ）をエンベディングモデルに使い、最終的に検索インデックスを調整します。
このフィードバックループは、より良いユーザーエクスペリエンス、よりパーソナライズされたユーザーエクスペリエンスを実現するのに役立ち、時間の経過とともに検索コンバージョン率を向上させます。
Uberのプラットフォームは、世界中の700万人のドライバー、1億3000万人の乗客、8000万人以上の食事をサポートしています。この大規模なユーザーベースは、常に100万件以上の同時トランザクションを生成し、これは検索およびオブザーバビリティプラットフォーム上で大量のワークロードに変換されます。
私たちの検索プラットフォームは、1日に500億件以上の検索クエリを処理しています。この数の検索クエリは、50以上の独自の検索ユースケースを動かしています。前のスライドでUber Eatsについて話しましたが、Uber Eats以外にも多くの検索ユースケースがあります。これらすべての検索ユースケースは、150以上のクラスターにデプロイされており、各クラスターは数百、一部は数千のノードの規模を持っています。
私たちのオブザーバビリティプラットフォームも大規模です。毎秒50億のメトリクスを処理しており、毎秒4億5000万の時系列データを扱っています。グローバルなメトリクスカーディナリティは1600億に達し、毎秒25,000件のメトリクスクエリを処理しています。
オブザーバビリティの取り込み
オブザーバビリティについて、私たちはM3と呼ばれる自社製のメトリクスシステムを使用してきました。しかし、時間の経過とともに、この自社製メトリクスシステムにはいくつかの欠点が見られるようになってきました。
まず、高カーディナリティクエリをサポートしていないという問題があります。さらに深刻なのは、ゾーン障害に対するレジリエンスが不十分なことです。私たちのプラットフォームはオンプレミスとクラウドプロバイダーのデータセンターの両方にデプロイされているため、停電によりゾーンがしばしば故障する可能性があります。ゾーン障害が発生した場合、診断のためにメトリクスが必要ですが、残念ながら多くの場合、まさに必要な時に利用できません。
また、この自社製メトリクスシステムは、運用コストの面でも多くの課題を抱えています。インフラストラクチャチームとしては、コストを可能な限り低く抑えたいと考えていますが、ガバナンス機能が組み込まれていないため、現時点では十分にコストを制御できていません。
これらの課題すべてに対処するため、OpenSearchの上に構築される次世代メトリクスプラットフォームの開発に投資しています。
自社製ソリューションの主要な問題の1つは、M3クエリ言語（M3QL）の使用です。Prometheusクエリ言語（PromQL）は業界標準として広く採用されていますが、M3QLはそうではありません。この移行とともに、互換性を向上させ、開発者エクスペリエンスを向上させるために、業界標準のクエリ言語を採用し、サポートしたいと考えています。
新しいアーキテクチャでは、M3メトリクスとPrometheusメトリクスの両方をサポートし、OpenSearch用のインジェスタを通じてデータをパーティション化して保存します。クエリは、M3QLとPromQLの両方をサポートし、ルーティングとフェデレーション機能を提供することで、スムーズな移行を実現します。
この図は、時系列データベースをサポートする高レベルのアーキテクチャを示しています。
OpenSearchは大規模なロギングとトレーシングのユースケースをサポートしています。しかし、ネイティブに組み込まれた時系列データベースがないため、大規模なメトリクスユースケースをサポートできませんでした。私たちはこのギャップを埋めることを目指しています。
私たちのエンジニアは、Prometheusの時系列データベースの設計に触発されたソリューションに取り組んでいます。私たちが構築しようとしているのは、OpenSearchサーバー内に時系列エンジンを組み込むことです。この時系列エンジンには、述語プッシュダウン機能も備えており、効率的なクエリ処理を可能にします。
アーキテクチャでは、Metrics Indexが中心となり、4時間から2時間前のデータを保持するイミュータブルシャード（不変シャード）と、直近2時間のデータを扱うミュータブルシャード（可変シャード）で構成されています。時系列エンジン内には、PromQL/M3エグゼキュータとインジェスターが配置され、これらがOpenSearchサーバー内で動作します。
前のスライドで述べたように、業界標準に準拠し、より良いクエリをサポートするためにPrometheusクエリ言語を採用したいと考えています。ここでの私たちのより広範な目標は、OpenSearchをすべてのオブザーバビリティユースケース、つまりロギング、トレーシング、メトリクスを単一のプラットフォームで包括的かつ競争力のあるソリューションとして位置づけることです。
OpenSearchコミュニティへの貢献と今後の展望
Uberでは、業界標準の技術を採用し、エコシステムパートナーとの協力において革新するという戦略をとっています。私たちは、オープンソースコミュニティとクラウドプロバイダーの両方から、幅広いソリューションに依存しています。
OpenSearch以外にも、様々なオープンソース技術を活用しています。キーバリューストアにはCassandraを、メッセージングにはKafkaを採用しています。リアルタイムデータ処理とデータ分析処理にはFlinkとHudiを使用し、バッチワークロード処理にはSparkとPrestoを活用しています。また、Pinotを使ったリアルタイム分析やMarmarayによるデータパイプライン管理も行っています。
クラウドサービスについても、オンライン配車サービスのリアルタイムワークロード処理にはOracleオブジェクトストレージを使用し、データレイクとデータ分析にはGoogleクラウドストレージを使用しています。また、リアルタイムトランザクションデータベースを動かすためにCloud Spannerなどのクラウドデータベースも使用しています。
私たちはUberエンジニアリングブログを通じて積極的に成果を共有しています。また、APACHECON、Current、RTA Summit、Flink Forward、OpenSearchCon、PrestoConなど、多くのコミュニティカンファレンスにも積極的に参加しています。さらに、このホテルからわずか数マイル離れたサニービルにあるUberオフィスでミートアップを開催しています。
皆様をUberサニービルオフィスでのミートアップに心からご招待いたします。皆様の学びや課題をお聞かせいただき、皆様と一緒にすべての興味深い問題に取り組みたいと思います。
この基調講演に加えて、OpenSearchConのUberのエンジニアによるいくつかの講演をハイライトしたいと思います。これらはOpenSearchエコシステムへの私たちの貢献を示しています。
まず、「Next-Gen Search: How Uber and the OpenSearch Community Built a Cloud-Native 3.0」では、リーダーとライターの役割を分離したデカップリングされたクラウドネイティブアーキテクチャの構築について紹介します。次に、「Advancing OpenSearch With gRPC and Protobuf at Uber」では、分散協調のための高スループットメッセージングプロトコルについて説明します。そして、「Deep Dive Into OpenSearch Pull-Based Ingestion at Uber」では、OpenSearchコミュニティと密接に協力して開発されたサーバーレス環境に最適化されたプールベースのインジェストモデルに関する私たちの仕事を取り上げています。
これらのイノベーションは、OpenSearch 3.0をクラウドネイティブなUber規模のデプロイメント向けに構築された次世代オープンソースエンジンとして位置づけるのに役立っています。
www.youtube.com
www.youtube.com
www.youtube.com
ここで免責事項を述べておきたいと思います。現在、自社製の検索ソリューションであるLucene Plus上で動作しているUber検索ユースケースについては、まだOpenSearchを採用していません。私たちが望むのは、OpenSearchテクノロジーで特定された大規模なギャップをすべて埋めることで、Uberデリバリービジネスと私が述べたその他多くのユースケースをOpenSearchプラットフォームに移行することです。
プロジェクトへの参加に興味がある方は、OpenSearch SlackやGitHubを通じてコミュニティに参加できます。また、OpenSearchエコシステム内でセマンティック検索とオブザーバビリティの限界を押し広げることに情熱を注ぐOpenSearchエンジニアを積極的に募集しています。
あなたのアイデアと貢献は、私たちが想像し始めたばかりのこれらの機能の未来を形作るのに役立つでしょう。
