プロトタイプから本番環境へ：Databricks AI Searchの高QPS対応

検索はあらゆる場所に存在します。小売サイトでの商品検索、スマートTVでの音声クエリ、あらゆるフィードでのレコメンデーション、アカウント照会時の本人確認などです。これらは、ページビューごと、キー入力ごと、ユーザーのアクションごとにリクエストを送信します。コンシューマー規模では、これは検索インデックスに1秒あたり数千件のクエリ（QPS）が送信されることを意味し、ピーク時のトラフィックはさらに数倍高くなることもよくあります。

また、検索は収益のクリティカルパスでもあります。Eコマースでは、検索を利用する買い物客のコンバージョン率は、単に閲覧しているだけの顧客の2〜3倍にのぼります。ストリーミングプラットフォームでは、レコメンデーションがユーザーの視聴コンテンツの大部分を決定づけています。

これまでは、本番環境レベルのQPSを達成するために、アプリケーションごとに独自の検索スタックを構築する必要がありました。インデックスサイズ、クエリタイプ、フィルターにわたる負荷テストの実施、手動でのキャパシティ設計、インデックスの前段へのロードバランサーの配置などです。新しい検索ユースケースが登場するたびに、この作業を最初からやり直さなければなりませんでした。この苦労は、ベクトルデータベース、検索エンジン、自作のスタックを問わず、共通の課題でした。

Databricks AI Searchの高QPSスケーリングの提供開始

本日、Databricks AI Searchの高QPSスケーリングの一般提供（GA）を開始したことをお知らせします。Standardエンドポイントは、人間が理解しやすい1つのパラメータを設定するだけで、数千QPSまでスケールできるようになりました。目標値を設定するだけで、それに合わせてインフラストラクチャが自動的にプロビジョニングされます。

エンドポイントの作成時に target_qpsを設定するか、SDK、REST API、またはエンドポイントUIから、既存のエンドポイントに対していつでも更新できます。Databricksが目標を達成するためのインフラストラクチャをプロビジョニングします。レプリカ数の管理、ノードのサイズ調整、ロードバランサーの配線などは一切不要です。

Unity CatalogによるガバナンスとDelta Syncはそのまま維持されます。プロトタイプを動かしていたのと同じエンドポイントが、プラットフォームから離れることなく、本番環境のトラフィックに合わせてスケールします。

高QPSスケーリングが必要になるケース

主に、以下の3つのリアルタイムな本番環境パターンで必要となります。

検索バー：Eコマースの商品検索、ストリーミングやメディアプラットフォームでのコンテンツ検索、スマートデバイスでの音声検索など。予測入力（タイポヘッド）ボックスは、キー入力ごとに検索コールを実行するため、アクティブな入力ボリュームに応じてQPSがスケールします。レイテンシはコンバージョンに直接影響します。エンドツーエンドのアーキテクチャについては、 Databricksでのリアルタイム商品検索の構築をご覧ください。

レコメンデーション／パーソナライズシステム：Eコマースの「おすすめ商品」パネル、メディアやストリーミングプラットフォームのパーソナライズされたフィードなど。ページビューごとにレコメンデーションクエリが実行されるため、トラフィックの急増はまず検索（リトリーバル）に影響します。レコメンデーションのレイテンシは、リクエストのクリティカルパス上にあります。

リアルタイムのエンティティ解決：リクエスト時のIDマッチング、重複排除、大規模カタログに対するルックアップなど。ここでのクエリレートは運用のSLAであり、バッファリングできるような一時的なバーストではありません。

以下のような現象が発生している場合、この機能が必要である可能性が高いです。

• 本番環境のログに429（Too Many Requests）エラーが表示されている
• 平均使用率が緩やかな場合でも、トラフィックの増加に伴いP95レイテンシが急上昇する
• エンドポイントの複製やクライアント側のロードバランシングなどの回避策をとっている

仕組みの詳細

宣言：エンドポイントに目標QPSを設定します。Databricksがその目標を達成するためのコンピュート容量を計算し、プロビジョニングします。レプリカ数、ノードサイズ、キャパシティプランニングの管理は不要です。

既存のエンドポイントに対応：Python SDK、REST API、またはUIを介して、任意のStandardエンドポイントを更新できます。新しい容量は、そのエンドポイント上のインデックスが次回作成または同期されたときに有効になります。

スケーリング状態の監視：エンドポイントの scaling_infoフィールドは、 SCALING_CHANGE_IN_PROGRESS to SCALING_CHANGE_APPLIEDからの移行プロセスの進捗を追跡します。

本番環境のオブザーバビリティ：本番環境で検索システムを運用するには、1秒あたりのリクエスト数、リクエストレイテンシ、エンドポイントの健全性を可視化する必要があります。エンドポイントUIで、すべてのエンドポイントについてこれら3つのメトリクスが表示されるようになりました。

サービスプリンシパル認証を使用してパフォーマンスを最大化：サービスプリンシパルのトラフィックは、高QPSの本番ワークロード向けに構築された、パフォーマンスが最適化されたネットワークを経由してルーティングされます。パーソナルアクセストークン（PAT）のトラフィックは数十QPSに制限されているため、プロトタイプ作成には適していますが、本番環境には適していません。 詳細な手順については、 パフォーマンスガイドをご覧ください。

サイズ調整：エンドポイントのオブザーバビリティUIとネイティブなGenie統合を使用してトラフィックパターンを把握し、スパイク（急増）に備えて十分な余裕を持たせた target_qps を設定します。

今すぐ構築を始めましょう

プロトタイプと本番環境の違いは、今や1つの設定パラメータだけです。高QPSスケーリングは本日より一般提供されており、オプトインは不要です。開始するには2つの方法があります。

• 初期目標値に target_qpsを設定して、新しいエンドポイントを起動する
• target_qpsを使用して既存のエンドポイントを更新し、すでにアプリケーションにサービスを提供しているインデックスをスケールアップする

今後の展望

私たちは、大規模な検索の運用をさらに容易にするための取り組みを続けています。手動でのキャパシティプランニングやサイズ調整が不要な、トラフィック急増時の自動スケーリング（オートスケーリング）や、ストレージ最適化エンドポイントのサポートを今年後半に予定しています。

詳細情報：

• 高QPSに関するドキュメント
• Databricks AI Searchの概要
• パフォーマンスのベストプラクティス
• Databricksでのリアルタイム商品検索の構築

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事