Elasticsearch:機能概要

独立したスケーリングによる読み書き分離

Agent Engine Edition は、書き込みとクエリを異なる役割のノードで実行します。データインジェスト量に基づいてインデックスノードを設定し、クエリ同時実行数に基づいて検索ノードを設定します。特定のワークロードが増加した場合、対応するリソースのみを調整すればよいため、同じコンピューティングリソースに対する書き込み、インデックスマージ、クエリ間の競合が大幅に削減されます。書き込みの急増はクエリの遅延からほぼ分離され、その逆も同様です。

自動的なホット/コールド階層化によるオンデマンドキャッシング

完全なインデックスデータはオブジェクトストレージに保存され、検索ノードのローカルディスクはクエリキャッシュとして機能します。頻繁にアクセスされるデータはキャッシュから継続的に再利用されるため、ホットクエリはミリ秒単位で応答します。ほとんどアクセスされないデータは、必要な場合にのみオブジェクトストレージから読み込まれます。ローカルキャッシュのサイズは、総データ量に合わせる必要はなく、アクティブワーキングセットに合わせて設定します。非アクティブなビジネススペースはコンピューティングリソースやキャッシュリソースを消費せず、そのストレージコストはオブジェクトストレージの従量課金料金に限定されます。

キャッシュの利点は、ワークロードのホット/コールドの分布、キャッシュ容量、ノード仕様、およびクエリ同時実行数に依存します。アクセスパターンが非常に分散している、または頻繁に変化するワークロードの場合は、実際のデータを使用して容量評価とパフォーマンステストを実施してください。

数億のビジネススペースの統合管理

Agent Engine Edition は、単一の Collection で数億のビジネススペースを統合管理できるように設計されています。アプリケーションは、各ナレッジベース、コードリポジトリ、エージェント、またはテナントを 1 つの Slice として扱い、同じ Collection を通じて読み取りと書き込みの両方を完了できます。プラットフォームは容量に基づいて基盤となるインデックスとシャードを管理するため、アプリケーションはビジネススペースごとに個別のインデックスを作成したり、基盤となるインデックス名やテーブルスキーマをアプリケーションコードで維持したりする必要がありません。本トピックの「パフォーマンスリファレンス」で説明するパフォーマンステストでは、10,000 のビジネススペースを対象としています。

クエリ時には、1 つまたは複数の Slice を選択するか、明示的にすべての Slice を選択できます。デフォルトでは、クエリスコープを明示的に指定する必要があります。デフォルトのクエリ動作については、本トピックの「データクエリの仕組み」をご参照ください。

データ移行なしでの秒単位の障害復旧

インデックスデータ、書き込みログ、およびクラスタ状態はオブジェクトストレージに保存され、コンピューティングノードはローカルに永続状態を保持しません。ノード障害後、プラットフォームは代替ノードを迅速にスケジュールします。このノードはオブジェクトストレージから操作を再開し、オンデマンドでローカルキャッシュを再構築するため、完全なデータ移行は不要です。従来のステートフルアーキテクチャにおけるシャードの復旧には数十分から数時間かかりますが、この設計により障害の影響範囲が縮小されます。

書き込み層が一時的にプライマリ (書き込み担当) シャードをホストできない場合、新規の書き込みは一時停止されます。対応する検索 (クエリ担当) シャードが利用可能な限り、システムは既に永続化され公開されたデータに対するクエリを提供し続けることができます。

Elasticsearch エコシステムとの互換性

サポートされている API の範囲内であれば、アプリケーションは Elasticsearch REST API と Query DSL を引き続き使用し、全文インデックス、ベクトル KNN、フィルタリング、および集計機能を組み合わせることができます。公式の Python、Java、Go、JavaScript クライアント、Kibana、およびその他のエコシステムコンポーネントは、互換性のあるインターフェースのリクエスト構造とクエリ構文を再利用できるため、インターフェース層の変更が削減されます。移行前に、使用するインターフェースとエコシステムコンポーネントを、お使いのインスタンスバージョンの互換性ドキュメントで検証してください。

ディスクネイティブベクトルインデックス (DiskBBQ)

Agent Engine Edition は、ディスクネイティブベクトルインデックス (DiskBBQ) を使用します。これは、階層的 k-means クラスタリングと BBQ 量子化を組み合わせることで、IO 予測可能な KNN クエリを実現します。クエリ時に、DiskBBQ は最大 2 レベルのセントロイドを探索し、ヒットしたクラスターをブロックシーケンシャル順に読み取ります。これにより、ベクトルをメモリ内に常駐させる必要なく、SSD キャッシングとオブジェクトストレージに適しています。HNSW と比較して、DiskBBQ はインデックス構築速度を約 1 桁向上させ、メモリが制約された場合でもパフォーマンスは急激にではなく緩やかに低下します。本トピックの「パフォーマンスリファレンス」のテスト結果は、クエリの遅延のみを対象としており、インデックス構築速度は含まれていません。選択する前に、ご自身のワークロードで構築パフォーマンスを検証してください。フィールド設定、KNN クエリパラメータ、および完全な例については、「DiskBBQ と Sliced DiskBBQ ベクトル検索」をご参照ください。

シナリオ

次の表は、Agent Engine Edition の典型的なシナリオと、各シナリオで推奨されるデータ編成を示しています。

コアコンセプト

Agent Engine Edition を理解するには、まず Collection と Slice を区別する必要があります。

データの読み書き時、アプリケーションは Collection 名を使用してデータにアクセスし、Slice を通じて対応するビジネススペースを指定します。プラットフォームはリクエストを Slice に対応するデータにルーティングし、基盤となるインデックスとシャードを管理します。アプリケーションは、基盤となるインデックス名を保存したり、直接操作したりする必要はありません。

コアアーキテクチャ

Agent Engine Edition のコアアーキテクチャは、3 つの考え方に基づいています。永続データはオブジェクトストレージに一元的に保存され、書き込みとクエリは独立してスケールする異なるノードタイプによって処理され、複数のビジネススペースは Collection と Slice を通じて編成されます。クエリデータは、オンデマンドでローカルキャッシュにキャッシュされます。

各コンポーネントの責務は次のとおりです。

データ書き込みの仕組み

• データを書き込む際、アプリケーションはリクエストの URI に Collection 名を使用し、Slice を通じてデータが属するビジネススペースを識別します。

• インデックスノードがリクエストを処理します。システムは、書き込みログ (Translog) がオブジェクトストレージに同期的に永続化された後にのみ、クライアントに書き込み完了を通知します。

• インデックスノードはバックグラウンドでインデックスファイルを生成し、新規インデックスバージョン (Commit) を公開します。検索ノードがリフレッシュされると、Elasticsearch のニアリアルタイムセマンティクスに従って、新規データがクエリ結果に反映されます。

データクエリの仕組み

• データをクエリする際、アプリケーションはリクエストの URI に Collection 名を使用し、Slice を通じて 1 つ以上のビジネススペースを指定します。デフォルトでは、Slice を指定しないクエリは拒否されます。これにより、ルーティング情報が欠落している場合に意図せず Collection 全体をクエリするリスクが軽減されます。

• 検索ノードは、まずクエリに必要なデータをローカルの共有キャッシュから読み取ります。

• キャッシュミス時に、検索ノードは現在のクエリで必要なデータ範囲をオブジェクトストレージから読み込みます。後続のクエリは、すでにキャッシュに入っているホットデータを継続して再利用します。

  Stateless architecture and resource planning