Pinecone のベンチマークパイプラインを解説

TLDR: Pinecone のデプロイ規模（オンデマンドか専用か、レプリカ数、ノードタイプ）を決める際、以前はエンジニアが EC2 上で手動で負荷テストスクリプトを実行し、出力を直接確認しながら一問ずつ推測していました。しかし現在では、パイプラインがワークロードの仕様を受け取って対応するインデックスを構築・読み込み、設定グリッド全体を自動で走査します。これにより、顧客はエンジニアの勘に頼るのではなく、自社の実際のワークロードに基づく測定値を根拠とした推奨サイズを即座に得られるようになりました。

Pinecone 上で顧客が下す意味のあるアーキテクチャ上の決断はすべて、スキーマを見ただけでは答えられない問いに帰着します。「この環境で実際にどのような挙動を示すのか？」

長らく、その問いに答える唯一の方法は、エンジニアが EC2 上で手動で負荷テストスクリプトを走らせ、出力結果を目視して確認することでした。これは一度に一つの質問には有効でしたが、Pinecone が実際に対応しなければならない膨大な数のサイズ決定タスクを処理するには不十分でした。また、顧客側も計画を立てられる具体的な数値を得られないという課題が残っていました。

このギャップを埋めるため、Pinecone はワークロード仕様を受け取って、自動的に完全にプロビジョニングされ、データが読み込まれ、測定済みのインデックスを生成するパイプラインを開発しました。これでデプロイの規模設定は、行データのバッチとクリック一つで完了します。顧客は誰でも、エンジニアの推測ではなく、自社のワークロードに基づく測定値を裏付けとした回答を得られるようになりました。

意思決定は測定の問題である

具体的な推奨を行うためには、特定のクエリレート、データセットの規模、フィルタパターンという条件の下で、「p99 の改善が頭打ちになるレプリカ数」と「ステップごとに必要なコスト」を明確に示す必要があります。その結論に至るには、複数のクエリレートとレプリカ数を組み合わせ、オンデマンド型と専用型の違い、そして異なるノードタイプ間の比較など、多角的なグリッド状のテストを実行する必要があります。これらはすべて、顧客が実際に使用しているインデックス構造を模した環境上で構築されます。

ゼロからこのプロセスを構築する場合、各ケースでセットアップ、データ取り込み、リクエストパターンの実行、そしてテardown（後片付け）が必要となるため、数十回から数百回の試行が必要です。これまで運用規模の決定は直感や過去の経験に頼っており、新しい顧客が既知のワークロードを持って現れるたびに、同じトレードオフについて議論し直すという非効率な繰り返しが発生していました。このグリッド状のテストを自動化するために、まずは「機能する最小限のもの」から着手しました。

構築された仕組み

最初のバージョンは、エンジニアが手動で行っていた作業をスクリプトで自動化したものです。EC2 インスタンス（AWS の単一仮想マシン）上でスクリプトを実行し、人間がその進行を見守るというシンプルな構成でした。これは個別の質問に対する回答には有効でしたが、グリッド全体を網羅するテストでは、各セルごとにセットアップ、負荷試験、後片付けを手動で繰り返す必要があり、最大数百回もの作業が発生しました。Pinecone 独自の VSB (Vector Search Bench) は負荷生成には優れていましたが、その周囲のプロビジョニングや容量設定、そしてテardown の工程は依然として手動であり、これがスウィープ（網羅的テスト）を遅くする要因となっていました。

現在、VSB を包み込むパイプラインに欠けていた自動化機能が追加されました。インデックスの用意から容量設定、負荷テストの実行、結果の記録、そしてリソースの解放までを自動で行うため、データベース上の 1 行のデータから測定結果が得られるまで、無人でスウィープ（一斉テスト）を実行できます。

ユーザーはシンプルな UI を介して、テストしたいワークロードを表の 1 つ以上の行として記述するだけでよく、システムが残りの処理をすべて担います。

全体の流れは以下の通りです。

セッションとは、まとめて提出された行のバッチのことです。通常は、ある顧客の質問に対するグリッド全体のデータが含まれます。このセッションを開始するとディスパッチャーが起動し、インデックスの形状ごとに行をグループ化します。そして、異なるインデックス形状それぞれに対して 1 つずつ EC2 ワーカーを立ち上げます。各ワーカーは行を 1 つずつ引き受け、順次実行していきます。

このグループ化こそが、スウィープを経済的に実現する鍵です。インデックスはその次元数、ベクトル数、類似度計算メトリクスによって一意に特定されるため、ある形状の最初の行でインポートコスト（1 回限りの費用）が発生します。その後の行では同じインデックスが再利用され、容量設定（例えばレプリカ数の変更など）のみを再調整してベンチマークを再実行するだけで済みます。つまり、1 つのデータセットに対して 48 個のセルを持つスウィープを行っても、データのインポートは 1 回だけ行われ、測定は 48 回実施されることになります。

重いクエリ負荷がかかる場合、インデックス自体よりも先に、単一の負荷生成用サーバーがボトルネックになる可能性があります。そのため、セッションでは複数の負荷生成ノードを要求できます。ワーカーがこれらを分散クラスタとして調整することで、目標とするクエリレートを実現し、単一サーバーの制限によって速度が抑制されるのを防ぎます。

ワークロードは設定項目の集合体

顧客のワークロードを忠実に記述することが目的です。各行には、パフォーマンスとコストに実際に影響を与える次元が明示されます。

• インデックス形状：ベクトル数、次元数、距離メトリクス、ハイブリッドワークロードで利用されるスパースモデルの種類。
• キャパシティ：オンデマンド（サーバーレス）か専用リーダノードかの選択。ノードタイプとレプリカ数を含み、サーバーレス環境から低コストでデータをインポートし、読み取りベンチマーク用に専用ノードへ切り替えるパスも定義します。
• クエリ負荷：目標とする 1 秒あたりのクエリ数、実行時間、top_k の値、結果に値やメタデータが含まれるか、またクエリに適用されるメタデータフィルターの有無。

各行には、その結果として何が起こったかも記録されます。達成されたスループット、リクエスト数、キャパシティ制限、完全なレイテンシ分布、そしてリコール率です。これが推奨機能の構築基盤となります。

これが顧客にもたらした変化

このパイプラインは、顧客との対話の可能性を 3 つの側面で変えました。

コスト削減。 最大の成果は、顧客が過剰なプロビジョニングを行わなくなった点です。以前のように「安全のために余裕を持たせる」ためにリソースを購入するのではなく、目指すパフォーマンスを確実に達成できる最小限のリソースだけを割り当てます。レプリカ数、キャパシティモード、ノードタイプにわたってワークロードをシミュレーションすることで、性能要件を満たしつつコスト増の効果がなくなる最適な設定を特定できます。顧客は、必要なレイテンシとスループットを、それを提供できる最低限の設定で得られるようになります。これは、実際のワークロードに基づく測定値によって裏付けられています。

パフォーマンス。 逆に、ワークロードが本当にレプリカの増加やノードサイズのアップグレード、あるいは異なる容量モードの導入を必要とする場合、データは遅延曲線がどこで曲がり、次のステップで何が得られるかを明確に示します。この推奨事項には裏付けとなるデータが含まれているため、3 ヶ月経過後も再検証されることなく信頼し続けられます。

期待値。 おそらく最も価値ある成果こそが、派手さの欠けるものです。スケーリング直前、あるいはアーキテクチャ変更を検討中の顧客にとって、コミットする前に何が起きるかを事前に知ることができます。現状のワークロードをベンチマークし、今後増えるトラフィックをモデル化することで、その先の遅延とスループットを事前に把握できるのです。これにより、スケーリングイベントは「信仰に頼った飛躍」から「計画された変更」へと変わり、本番環境での予期せぬトラブルは大幅に減ります。

このパイプラインは、以前ならエンジニアが 1 週間かけて行っていたスウィープ（探索）を、バッチ処理の行データとワンクリックで背景で実行します。これで浮いた時間は、直前の作業を手動で繰り返すのではなく、次に答えるべき価値あるワークロードの質問に注ぐことができます。