Elasticsearch:機能概要

独立スケーリングによる読み取り/書き込み分離

書き込みとクエリは異なるノードロールを使用します。インデックスノードは取り込み量に基づいて設定し、検索ノードはクエリの同時実行数に基づいて設定します。いずれかのワークロードが増加した場合、対応するリソースのみを調整すればよく、書き込み、インデックスマージ、クエリが同一コンピュートリソースを競合することはありません。書き込みの急増がクエリ遅延に影響せず、クエリ負荷が取り込み速度を低下させることもありません。

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

完全なインデックスデータはオブジェクトストレージに保存されます。検索ノードのローカルディスクはクエリキャッシュとして機能します。頻繁にアクセスされるデータはキャッシュから継続的に提供され、ミリ秒単位でホットクエリに応答します。一方、アクセス頻度の低いデータは必要に応じてオブジェクトストレージからロードされます。ローカルキャッシュのサイズはアクティブな作業セットに基づいて設定され、総データ量と一致させる必要はありません。非アクティブなビジネススペースはコンピュートリソースやキャッシュリソースを消費せず、そのコストはオブジェクトストレージの従量課金料金に限定されます。

キャッシュの効果は、ワークロードのホット/コールド分布、キャッシュ容量、ノードスペック、およびクエリの同時実行数に依存します。アクセスパターンが高度に分散している、または頻繁に変化するワークロードについては、実際のデータを用いた容量評価および性能テストを実施してください。

統一管理による大規模ビジネススペース

アプリケーションは、ナレッジベース、コードリポジトリ、エージェント、またはテナントを Slice として扱い、同一の Collection を介して読み取りおよび書き込みを行えます。プラットフォームは容量に基づいて基盤となるインデックスおよびシャードを管理します。アプリケーション側でビジネススペースごとに個別のインデックスを作成したり、アプリケーションコード内で基盤となるインデックス名やテーブル構造を追跡したりする必要はありません。

クエリ実行時には、1 つの Slice、複数の Slice、または明示的にすべての Slice を選択できます。デフォルトでは、アプリケーションがクエリ範囲を指定する必要があります。これにより、ルーティング情報が欠落している場合に意図せず Collection 全体をスキャンするリスクを軽減できます。

データ移行不要の障害復旧

インデックスデータ、ライトアヘッドログ、クラスター状態はオブジェクトストレージに保存されます。コンピュートノードはローカルに永続状態を保持しません。ノード障害発生後、プラットフォームはオブジェクトストレージから操作を再開し、必要に応じてローカルキャッシュを再構築する代替ノードをスケジュールします。完全なデータ移行は不要です。従来のステートフルアーキテクチャでシャード復旧に数十分から数時間かかるのに対し、障害の影響範囲（ブラストレディウス）が大幅に縮小されます。

書き込みレイヤーが一時的にプライマリシャードをホストできない場合、新しい書き込みは一時停止されます。対応する検索シャードが利用可能な限り、システムはすでに永続化・公開されたデータに対してクエリを継続できます。

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

サポート対象の API 範囲内では、アプリケーションは引き続き Elasticsearch REST API および Query DSL を使用でき、全文検索、ベクトル KNN、フィルター、集約を組み合わせられます。公式の Python、Java、Go、JavaScript クライアント、Kibana などのエコシステムコンポーネントは、互換インターフェイスのリクエスト構造およびクエリ構文を再利用できるため、インターフェイス層の変更を最小限に抑えられます。移行前には、ターゲットインスタンスバージョンの API 互換性ドキュメントを参照し、使用中のインターフェイスおよびエコシステムコンポーネントを検証してください。

ユースケース

基本概念

AI Engine Edition を理解するには、Collection と Slice の違いを把握してください。

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

コアアーキテクチャ

クエリデータは必要に応じてローカルキャッシュに入ります。各コンポーネントの主な役割は次のとおりです。

データの書き込み方法

• アプリケーションはリクエストパスに Collection 名を使用し、Slice を通じて対象のビジネススペースを識別します。

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

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

データのクエリ方法

• アプリケーションはリクエストパスに Collection 名を使用し、Slice を通じて 1 つまたは複数のビジネススペースを指定します。Slice が指定されていないクエリは、意図しない全範囲クエリを防ぐため、デフォルトで拒否されます。Collection 全体をクエリするには、クエリ時に明示的にすべての Slice を選択してください。

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

• キャッシュミスが発生した場合、検索ノードはオブジェクトストレージから必要なデータ範囲をロードします。その後のクエリでは、すでにキャッシュに入ったホットデータを再利用し続けます。

  ノード障害時のクエリ可用性を維持するには、AI Engine Edition 利用ガイドに記載されているとおり、レプリカ数および検索ノード数を設定してください。

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

AI Engine Edition は、階層的 K-means クラスタリングと BBQ 量子化を組み合わせて IO 予測可能な KNN クエリを実現するディスクネイティブベクトルインデックスである DiskBBQ を採用しています。クエリ時には最大 2 レベルの重心を探索し、ヒットクラスタをブロックシーケンシャル順に読み取ります。これにより、ベクトルをメモリ上に常駐させる必要なく、SSD キャッシュおよびオブジェクトストレージに自然に適合します。HNSW と比較して、DiskBBQ はインデックス構築速度を約 1 桁向上させ、メモリ制約下でもパフォーマンスが急激に低下するのではなく、滑らかに劣化します。

今後の展開

オブジェクトストレージネイティブアーキテクチャを基盤として、ロードマップにはサブ秒単位のゼロコピー分岐（コピーオンライトに基づき任意の Slice に対して独立したデータブランチを作成し、評価、カナリアリリース、ロールバックに適したもの）、コンピュートレイヤーの Scale to Zero（アイドル状態のビジネススペースを自動的にほぼゼロまでスケーリングし、コストをアクティブな負荷にさらに適合させる機能）、および Alibaba Cloud Elasticsearch エコシステム機能とのより深い統合が含まれます。具体的な機能リリースのタイムラインは、プロダクトアナウンスに準拠します。