本記事は OpenSearch Project に投稿された Announcing OpenSearch 3.0 の日本語訳版です。一部冗長な表現をカットしています。
はじめに
OpenSearch 3.0 がついにリリースされました！
OpenSearch プロジェクトの最初のメジャーバージョン（2022 年以来）となるこのリリースでは、パフォーマンス、データ管理、ベクトルデータベース機能などが大幅な進化しています。
なぜメジャーバージョンのリリースまで 3 年もかかったのでしょうか？OpenSearch Project はセマンティックバージョニングに従い、破壊的変更はメジャーバージョンでのみリリースするという方針を守ってきました。Apache Lucene 10 のリリースによる本質的なパフォーマンス向上が、3.0 への移行を決断する契機となりました。
OpenSearch 開発者コミュニティは、この機会を活かして OpenSearch の機能、パフォーマンス、汎用性を新たなレベルに引き上げる技術革新を多数提供しました。彼らの努力と技術運営委員会の監督のおかげで、OpenSearch 3.x シリーズはこちらから入手可能となり、将来のアプリケーションが必要とする高性能ワークロードと大規模データセットに対応する準備ができています。
このリリースのハイライトについては以下をご覧ください。また、新機能と破壊的変更の包括的なリストについてはリリースノートをご覧ください。
コスト、パフォーマンス、スケーラビリティ
OpenSearch は、データ集約型の検索、可観測性、生成 AI ワークロードのパフォーマンス要求に先んじるため、パフォーマンスの大幅な向上（およびベンチマーク比較での優位性）を実現してきました。
3.0 リリースではこれらのパフォーマンス向上をさらに加速し、OpenSearch 2.19 と比較して desc_sort_after_timestamp、query_string_on_messagem、cardinality_agg_high などの影響が大きいオペレーションにおいて、総合的に 20% の改善を実現しています。本リリースは OpenSearch 1.3 と比較して、主要なクエリタイプで 9.5 倍以上高速に動作します。
Lucene 10 のアップグレードの恩恵
Apache Lucene の最新バージョンは、パフォーマンス、効率性、ベクトル検索機能に大幅な改善をもたらします。これらの改善により、より大規模なベクトルと検索デプロイメントが可能になり、AI ワークロードが飛躍的にスケールできるようになります。Lucene 10 リリースの投稿にはすべての詳細が含まれていますが、本投稿ではハイライトをピックアップしてお伝えします。
• インデックス作成パフォーマンス: Lucene 10 はベクトルフィールドのインデックス作成プロセスを最適化し、ベクトルデータのインデックス作成時間の短縮とインデックスサイズの削減を実現しました。
• スパースインデックス: インデックスソートと組み合わせて類似したドキュメントをグループ化するスパースインデックスによって、 CPU とストレージの利用効率が向上しました。
• ベクトル量子化: ベクトル表現のための新しい圧縮技術が作成されたことで、メモリ使用量を削減しつつ、クエリパフォーマンスが向上しました。
その他の改善点には、テキスト/セマンティック検索の統合によるハイブリッド検索の改善、エンジン内パフォーマンスモニタリングの強化などがあります。
protobuf と gRPC によるデータ転送パフォーマンスの向上
OpenSearch 3.0 では、クライアントとサーバー間のデータ転送のパフォーマンスを向上させるため、gRPC トランスポート上のプロトコルバッファ (protobuf)の実験的サポートという大きな一歩を踏み出しました。
基盤となる HTTP/2 インフラストラクチャの恩恵により、gRPC は多重化と双方向データストリームをサポートし、クライアントが同じ TCP 接続上で同時にリクエストを送受信可能としています。JSON を使用する際にリクエストのデシリアライズのオーバーヘッドが複合的に生じる可能性があるような、大規模で複雑なクエリを扱うユーザーにとって特にパフォーマンスの向上が顕著にみられます。
JSON のシリアライズコストを削減したいユーザーや、既存の gRPC エコシステムに OpenSearch を簡単に統合する方法を探しているユーザーは、今後のリリースでの一般提供に向けて、 protobuf と gRPC のサポートが拡大されることにご注目ください。
Pull 型取り込みによるストリーミングデータのインデックス作成
このリリースでは、実験的機能として OpenSearch にPull 型取り込みが導入されました。これにより、ユーザーはストリーミングデータソースからデータを取得するように OpenSearch インデックスを構成するか、これまでどおり REST API を通じて OpenSearch にデータをロードすることができます。
プル型取り込みの主な利点は、バックプレッシャーとデータ取り込みのペース制御を本質的に処理できることで、より安定で回復力のあるデータパイプラインを確保します。このリリースには、Apache Kafka と Amazon Kinesis データソースからのプル型取り込みをサポートするプラグインが含まれています。この機能をプロジェクトにもたらすことに貢献した Uber の Search Platform Team に感謝します。
範囲クエリのパフォーマンスを 25% 向上
OpenSearch 3.0 は、数値フィールドと日付フィールドの範囲クエリに対してよりスマートな戦略を組み込んでいます。マルチレベル間隔ツリーフィルターなどの近似技術を使用することで、OpenSearch は範囲フィルターをはるかに少ない I/O 操作で回答できます。実際には、timestamp >= X AND timestamp
高カーディナリティ集約のレイテンシを最大 75% 削減
非常に高いカーディナリティ(多数のユニークな値)を持つフィールドや広い数値範囲に対する分析クエリを扱う場合、OpenSearch 3.0 は結果を高速化するための新しい最適化を提供します。
一つの改善点は、ユニークな値の数を推定するカーディナリティ集約のための実行ヒントです。何百万ものユニークな用語を持つデータセットでは、カーディナリティ集約子は大量のメモリを消費する可能性があります。この実行ヒントにより、高カーディナリティフィールドでの大量のメモリ使用を避けながら、精度とパフォーマンスのバランスを取るアルゴリズム戦略（precision_threshold など）を選択できるようになりました。
p90 レイテンシへの正味の効果は、OpenSearch 2.19 と比較してベンチマークテストでレイテンシが 75% 削減されました。
フィルター書き換え最適化でのサブ集約のサポート
日付ヒストグラム集約ワークロードのクエリレイテンシを削減する継続的な取り組みの一環として、OpenSearch 3.0 はサブ集約サポートを備えた集約のためのフィルター書き換え最適化を強化します。
以前は、この最適化はサブ集約のない単一レベルの集約にのみ適用されていましたが、現在ではそのパフォーマンス向上がサブ集約にも適用され、より複雑な実世界のユースケースに機能を拡張しています。この最適化により、Big5 ワークロードの関連操作で 30% から 40% の改善が示されました。
ベクトルデータベースと生成 AI
OpenSearch 3.0 には、検索、可観測性、生成 AI ワークロードのための強力なベクトル駆動アプリケーションの構築のパフォーマンスを向上させ、タスクを簡素化する新機能が満載されています。
ネイティブ MCP プロトコルサポートによるエージェント AI の強化
バージョン 3.0 では、OpenSearch はサーバーとクライアント側の両方で実験的機能としてモデルコンテキストプロトコル（MCP）のネイティブサポートを導入し、AI エージェントとのシームレスな統合を可能にします。このオープンプロトコルは、大規模言語モデル (LLM) アプリケーション、データソース、ツール間の通信を標準化します。MCP クライアントサポートにより、ユーザーは既存のツールとシステムを ML Commons エージェントフレームワークに組み込むことができ、より包括的でカス
タマイズ可能な AI 駆動ソリューションを実現します。サーバー側では、OpenSearch はインデックスの検索やインデックス統計の取得などの操作をツールとして公開できるようになり、Anthropic、LangChain、OpenAI などの外部 AI エージェントとの OpenSearch の統合が容易になります。
複雑な分析をサポートするプラン・実行・リフレクトエージェントのデプロイ
ML Commons エージェントフレームワークへのもう一つの追加は、計画と反省を使用して複雑なタスクを自律的に解決できる実験的なプラン・実行・リフレクトエージェントです。
このエージェントは複雑な質問を管理可能なステップに分解し、実行に適したツールを選択し、反省を通じて戦略を反復的に改善します。例えば、サービスエラーを分析する際、エージェントは自動的にログを分析し、関連するインデックスにクエリを実行し、関連する問題についてウェブを検索し、トラ
ブルシューティングを支援するために結果をまとめることができます。
ベクトル用の派生ソースによるストレージコストを最大 3 倍削減
2.19 で実験的機能として最初にリリースされた k-NN ベクトル用の派生ソースは、OpenSearch 3.0 ではすべてのベクトルインデックスで本番環境対応となりました。派生ソースを使用すると、OpenSearch に完全なソースベクトルを保存する必要なく、検索とリインデックス中にベクトル値にアクセスできます。
JSON ソースからベクトルを削除し、必要に応じて動的に注入することで、派生ベクトルはクエリパフォーマンスを向上させ、Lucene エンジンの p90 コールドスタートクエリレイテンシを最大 30 倍改善し、すべてのエンジンでマージ時間を最大 40% 削減します。
この機能は、Faiss、Lucene、NMSLIB ライブラリ全体でストレージコストを 3 倍削減することも実証しており、ベクトルワークロードのさらなる最適化を可能にします。
GPU アクセラレーションによるより高速なベクトルソリューションの構築
ベクトル操作は、特に大規模な場合、計算集約的です。これにより、GPU が優れている並列処理に理想的に適しています。実験的機能として、このリリースでは GPU を展開してインデックスビルドを強化し、インデックス作成を大幅に高速化し、運用コストを削減し、フォールトトレランスを向上させる機能が解放されます。
ベンチマークテストによると、GPU アクセラレーションは CPU ベースのソリューションと比較してインデックス作成速度を 9.3 倍向上させ、コストを 3.75 倍削減できます。
GPU がベクトル検索アプリケーションの最適化にどのように役立つかについての詳細は、ブログ記事 OpenSearch での GPU アクセラレーテッドベクトル検索：新たなフロンティアをご覧ください。この画期的な機能への貢献に対して NVIDIA チームに特別な感謝を表します。
セマンティックセンテンスハイライトによる検索結果全体の関連性向上
セマンティックセンテンスハイライトは、機械学習を使用して関連する文を特定し、キーワードマッチだけでなく意味に基づいてハイライトすることで、検索結果の関連性を向上させるものです。
正確なテキストマッチングに依存する従来のハイライトとは異なり、この機能はコンテキストを捉え、文全体をハイライトすることで完全な思考を保持します。セマンティックハイライトは、従来の検索、ニューラル検索、ハイブリッド検索を含むすべてのクエリタイプで機能し、正確なキーワードが存在しない場合でも検索結果をより意味のあるものにします。
このリリースには、一般的なドメイン全体で意味的に関連する文を特定するために最適化された事前トレーニング済みの opensearch-semantic-highlighter-v1 モデルが含まれています。ユーザーはこのモデルをクラスターに簡単にデプロイし、ハイライト設定で参照できるため、基本的なセマンティックハイライトのユースケースにカスタムモデルをトレーニングする必要がなくなります。
同時セグメント検索による二値量子化（32x）パフォーマンスを 2.5 倍向上
同時セグメント検索は、OpenSearch k-NN クエリでデフォルトで有効になりました。
同時セグメント検索を有効にすると、複数のスレッドにわたってクエリを並列化することで、リコールに影響を与えることなく k-NN クエリのパフォーマンスを最大 2.5 倍加速できます。
このリリースでは、マージポリシーのフロアセグメントサイズ設定の変更も有効になり、よりバランスの取れたセグメントを作成し、テールレイテンシを最大 20% 改善します。
Explain API によるベクトル検索スコアリングの洞察を獲得
このリリースから、explain パラメータを使用して、Faiss エンジンを使用した k-NN クエリでスコアがどのように計算、正規化、結合されるかについての洞察を得ることができます。
この機能は、各検索結果のスコアリングプロセスに関する詳細情報を提供し、使用されたスコア正規化技術、異なるスコアがどのように結合されたか、個々のサブクエリスコアの計算を公開します。この包括的な洞察により、クエリ結果を理解し最適化することがより簡単になります。
検索
OpenSearch 3.0 は、検索操作を強化し検索結果を改善するための新機能も多数提供します。
Z スコア正規化によるハイブリッド検索結果の強化
このリリースでは、ハイブリッド検索におけるスコア正規化の新しい統計的アプローチである Z スコア正規化が導入されました。
デフォルトのスコアベースの正規化方法である min-max 正規化は外れ値に苦戦する可能性がありますが、Z スコア正規化は生のスコアを標準化された単位に変換することで優れています。この技術は各サブクエリのスコア分布を考慮し、外れ値を効果的に処理し、異なるクエリタイプ間でスコアを直接比較可能にします。このアプローチは、外れ値と異なるスコアスケールの影響を減らすことで、ハイブリッド検索の信頼性を大幅に向上させ、より一貫性のある意味のある検索結果をもたらします。
min-max 正規化の下限によるハイブリッド検索結果の関連性向上
このリリースでは、min-max 正規化の下限を追加することで、ハイブリッド検索の関連性における重要な制限に対処しています。
従来の min-max 正規化では、ニューラル検索とキーワード検索の結果を組み合わせる際に、極めて低いスコアのドキュメントが不均衡に昇格し、最適でないランキングにつながる可能性があります。下限を設定することで、正規化中に最小しきい値を確立し、以前は検索結果を支配する可能性があった無視できるスコアの過度な増幅を防ぎ、正規化された値が実際の関連性に対して意味のあるものであり、比例していることを確保します。
スコアが指定された下限を下回る場合、適切なランキング順序を維持するように調整されます。これは、一方の検索方法が最小限の関連性シグナルを生成するクエリに特に有益です。
inner hits サポートによるハイブリッドクエリ結果の改善
このリリースでは、ハイブリッドクエリでの inner hits のサポートが追加されました。
inner hits は、ネストされたフィールドや親結合フィールドで検索操作を実行する際にデフォルトで非表示になる基礎となるヒットです。ハイブリッドクエリの場合、inner hits は最終検索結果に存在する各親ドキュメントに基づいて抽出されます。親ドキュメントはハイブリッドスコアを表示し、inner hits は正規化前の生のスコアを表示します。この機能を使用するには、ユーザーは検索リクエスト
に inner_hits 句を追加する必要があります。
スターツリーインデックス作成による集約のクエリオーバーヘッド削減
集約が多いワークロードでは、OpenSearch 3.0 は 2.19 で導入された スターツリーインデックス作成機能の構築を継続し、特定の集約を劇的に高速化できます。このリリースでは、スターツリーのサポートが拡張され、集約内のメトリック集約とフィルタされた用語クエリを処理できるようになりました。
重い集約（例えば、数十億のレコードにわたるヒストグラムの計算）のためにすべてのドキュメントをスキャンする代わりに、OpenSearch はより小さな事前集約されたセグメントを読み取ることでクエリに回答できます。初期の結果では、スターツリーを活用した集約でクエリ作業が最大 100 倍削減され、キャッシュ使用量が 30 倍低下することが示されており、特に高カーディナリティのグループ化操作とマルチレベル集約に大きな利点があります。
可観測性、ログ分析、セキュリティ分析
このリリースには、可観測性、ログ分析、セキュリティ分析のワークロードをサポートする新しいツールが含まれています。
PPL クエリの進化によるログデータのより効率的な強化と管理
このリリースでは、lookup、join、subsearch コマンドの追加により、OpenSearch の Piped Processing Language（PPL） ツールに強力な機能が追加されました。
これらの機能により、特に可観測性とセキュリティドメインのユーザーは、大規模なデータセット全体でログをより効率的に強化、相関付け、フィルタリングできるようになります。例えば、セキュリティエンジニアは認証ログとアプリケーションログを結合してインシデントを調査したり、lookup を使用してリアルタイムでログに地理的コンテキストを追加したりできるようになりました。Apache Calcite によってバックアップされたこれらの強化は、クエリ計画と実行の改善ももたらし、将来のリリースでより高度な分析機能の基盤を築きます。このリリースは、PPL をよりインタラクティブなデータ探索のためのより表現力豊かで高性能な言語にする重要な一歩を示しています。
クエリモニタリングとパフォーマンス分析の改善
OpenSearch 3.0 は、クエリモニタリングとパフォーマンス分析を改善するいくつかの強力な機能で Query Insights を強化します。
新しい Live Queries API は、クラスター全体で現在実行中の検索クエリをリアルタイムで可視化し、長時間実行されるリソース集約型の操作を発生時に特定するのに役立ちます。これにより、ユーザーはリソース集約型クエリの影響を評価し、システムの安定性と回復力を維持するためにクエリのキャンセルなどの積極的な対策を講じることができます。
verbose パラメータは、完全な詳細が必要ない場合にクエリデータの軽量バージョンを取得できるようにすることで、ダッシュボードのパフォーマンスを最適化し、ペイロードサイズを大幅に削減し、応答性を向上させます。
Query Insights ダッシュボードの新しい動的列は、フィルター選択に基づいてインテリジェントに適応し、クエリ、グループ、または結合ビューに関連するメトリックのみを表示します。
これらの機能を組み合わせることで、何千ものクエリレコードがあってもダッシュボードのパフォーマンスを維持しながら、より効率的なモニタリングとトラブルシューティング機能を提供します。
Discover インターフェースから直接異常を探索
このリリースでは、可観測性とログ分析のワークロードのユーザーエクスペリエンスにさらなる強化が加えられています。
例として、コンテキスト起動により、Discover インターフェースからメインダッシュボードで異常検出器を起動し、Discover ビューに関連するすべてのログを入力できるようになりました。OpenSearch が異常検出後のログクエリを代わりに処理することで、手動作業が削減されます。
モジュラーアーキテクチャ
このリリースには、OpenSearch のモジュラーアーキテクチャへの更新が含まれています。
リモートストアクラスターの読み取りと書き込みを分離してリソース使用率を向上
このリリースから、OpenSearch はリモートストア対応クラスター内のインデックス作成とサーチトラフィックを分離するアーキテクチャをサポートします。クラスター全体でインデックス作成と検索操作を分離することで、障害の分離、独立したスケーリング、パフォーマンスとコスト効率の向上を提供し、特に大量のインデックス作成と集中的な検索操作を必要とするユースケースに適しています。ログ分析などの書き込み一度、読み取り多数のユースケースでは、このリリースでは新しい scale API が導入され、すべてのライターをオフにしてインデックスを検索専用にすることができます。
セキュリティ
OpenSearch 3.0 には、OpenSearch デプロイメントのセキュリティを維持するのに役立ついくつかの重要な更新が含まれています。
OpenSearch 3.0 での Java Security Manager の置き換え
JDK 17 では、Java は Java Security Manager を非推奨とし、最終的に削除することを示しました。JDK 24 では、Java は Security Manager を永久に無効化し、Java 言語のこの部分を廃止しました。OpenSearch は、OpenSearch プロセスと同じ JVM で実行されるプラグインに適切なサンドボックス化を提供するために、これらの Java 機能に依存してきました。
OpenSearch 3.0 では、Java Security Manager が新しい Java エージェントに置き換えられ、低レベルのインストルメンテーションを提供し、OpenSearch が特権呼び出しをインターセプトして、特権アクションを実行する呼び出し元に明示的に権限が付与されていることを確認できるようになりました。新しい Java エージェントは、Security Manager と同じ方法で構成され、実行を許可された特権ア
クションを指定するコードベースに権限を付与するポリシーファイルを使用します。
セキュリティ操作のパフォーマンス向上
OpenSearch 2.19 では、Security プラグインに重要なパフォーマンス最適化が導入され、クラスター内のインデックスとロールの数に応じて特権評価のスケーリングが向上しました。
このリリースでは、[フィールドレベルセキュリティ]
(https://opensearch.org/docs/latest/security/access-control/field-level-security/)、フィールドマスキング、ドキュメントレベルセキュリティの実装に関するさらなるパフォーマンス向上がもたらさました。
これにより、ノード間通信でのデータの内部シリアライズとデシリアライズが減少し、高度なセキュリティ機能を使用するクラスターに大きな利点をもたらします。
3.x バージョン用の新しい PGP キー
OpenSearch バージョン 3.0 以降では、アーティファクト検証のための新しい PGP 公開キー（release@opensearch.org に関連付けられた）が利用可能であることにご注意ください。OpenSearch の現在の PGP 公開キー（opensearch@amazon.com に関連付けられた）は 2.x リリースのみに予約されます。新しい公開キーをダウンロードするには、https://opensearch.org/verify-signatures.html にアクセスしてください。このキーは 2027 年 3 月 6 日に期限切れになる予定です。
OpenSearch 3.0 を始めよう
OpenSearch 3.0 で何ができるか探索する準備はできましたか？お好みのディストリビューションについてダウンロードページにアクセスするか、OpenSearch Playground で最新の可視化ツールをチェックしてください。詳細については、リリースノート、ドキュメントリリースノート、更新されたドキュメントをご覧ください。いつものように、コミュニティフォーラムでのフィードバックを歓迎しています。
OpenSearch 3.0 での皆様の体験についてお聞かせいただくことを楽しみにしています！
Views: 0
