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

検索は至る所にあります。小売サイトでの商品発見、スマートテレビでの音声クエリ、すべてのフィードでのレコメンデーション、アカウント検索時の本人確認。それぞれがページビュー、キーストローク、ユーザーアクションごとにリクエストを発生させます。消費者規模では、毎秒数千のクエリが検索インデックスにヒットし、ピークトラフィックは数倍になることもあります。

検索は収益のクリティカルパスにも位置します。小売では、検索を利用する買い物客のコンバージョン率は、単にブラウズするだけの人の2～3倍です。ストリーミングプラットフォームでは、レコメンデーションがユーザーの視聴コンテンツの大部分を占めています。

従来、本番レベルの QPS を達成するには、アプリごとにカスタム検索スタックを構築する必要がありました。インデックスサイズ、クエリタイプ、フィルタにわたる負荷テスト、手動での容量見積もり、インデックス前のロードバランサーの設定。新しい検索ユースケースごとに作業が繰り返されます。この問題は、ベクトルデータベース、検索エンジン、DIY スタックに共通しています。

本日、Databricks AI Search の高 QPS スケーリングが一般提供開始となりました。人間が読める単一のパラメータで、標準エンドポイントを数千 QPS にスケールできます。目標を伝えていただければ、当社がインフラをプロビジョニングします。

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

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

高 QPS スケーリングが必要な場合：

3つのリアルタイム本番パターンで必要となります。

検索バー：eコマースの商品検索、ストリーミングやメディアプラットフォームのコンテンツ発見、コネクテッドデバイスでの音声検索など。タイプアヘッドボックスはキーストロークごとに検索呼び出しを発行するため、QPS はアクティブな入力量に応じてスケールします。レイテンシは直接コンバージョンに影響します。

レコメンデーション/パーソナライゼーションシステム：eコマースの「あなたへのおすすめ」パネル、メディアやストリーミングプラットフォームのパーソナライズフィードなど。ページビューごとにレコメンデーションクエリが発生するため、トラフィックの急増はまず検索に影響します。レコメンデーションのレイテンシはリクエストのクリティカルパスにあります。

リアルタイムエンティティ解決：本人確認、重複排除、リクエスト時の大規模カタログ検索など。ここでのクエリレートは運用 SLA であり、バッファリングできるバーストではありません。

次のような兆候が見られる場合、この機能が必要になる可能性があります：

• 本番ログでの 429（Too Many Requests）エラー
• 平均使用率が適度でも、トラフィック増加に伴う P95 レイテンシの急上昇
• 重複エンドポイントやクライアントサイドのロードバランシングなどの回避策

仕組みの詳細：

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

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

スケーリング状態の監視：エンドポイントの scaling_info フィールドが、SCALING_CHANGE_IN_PROGRESS から 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 上でのリアルタイム商品検索の構築