OpenSearch Magazine Vol. 1

みなさん、こんにちは。ソリューションアーキテクトの榎本です。OpenSearch Magazine の第 1 号をお届けいたします。本号では OpenSearch Service の最近のアップデート情報と、OpenSearch 最適化インスタンスタイプのご紹介、OpenSearch Project で現在開発が進められている OSS 版 OpenSearch 3.x 系のロードマップアイテムについてお話いたします。

OpenSearch Magazine は、HAQM OpenSearch Service およびオープンソース版 OpenSearch の最新動向をキャッチアップいただくべく開設されました。開設の経緯や HAQM OpenSearch Service の概要につきましては、「OpenSearch Magazine 開設のお知らせ」よりご確認いただけます。

サービスアップデート

直近でリリースされた、 HAQM OpenSearch Service に関する重要なアップデートについて解説していきます。

マネージドクラスターにおいて、OR2 および OM2 インスタンスタイプを新たにサポート

HAQM OpenSearch Service に、新たに OR2 と OM2 インスタンスタイプが加わりました。OR2 は東京リージョンを含む 10 リージョンで利用可能です。OM2 は記事執筆時点では、東京・大阪リージョンでは未提供です。

OR2 / OM2 は OpenSearch 最適化インスタンスファミリーのメンバーであり、2023 年 11 月に提供が開始された OR1 インスタンスタイプの後継といえます。OR2 はメモリ最適化インスタンスタイプと同様の vCPU:メモリ比率が 1:8 のインスタンスタイプです。OM2 は汎用インスタンスタイプと同様の、vCPU:メモリ比率が 1:4 のインスタンスタイプです。OR2 / OM2 ともに、 OR1 と同様、 S3 ベースのマネージドストレージとローカルストレージを組み合わせた独自のインフラストラクチャを採用しています。従来のインスタンスファミリーと比較してインデックス作成スループットに優れており、ログ分析といった、大量のデータを効率よく取り込む必要のあるユースケースに適しています。OR2 は R7g からの移行で最大 70%、OR1 からの移行で最大 26% のスループット向上が期待できます。OM2 は M7g からの移行で最大 66%、OR1 からの移行で最大 15% のスループット向上が期待できます。

OR2 は OR1 と比較して 4.3% コストが低く、コストパフォーマンスにも優れています。OR1 ほどのメモリが不要な場合は、OM2 に移行することで 27.21% のコスト削減が期待できます。詳細な料金については、「HAQM OpenSearch Service の料金」をご確認ください。

OpenSearch 最適化インスタンスタイプは、特性を理解し適切なユースケースで採用することで大きな力を発揮します。本号では、Hot Topic のセクションにて、最適化インスタンスタイプの効果的な活用方法について解説していきます。

HAQM Bedrock Knowledge Bases が OpenSearch マネージドクラスターをサポート

HAQM Bedrock Knowledge Bases は、HAQM Bedrock が提供する基盤モデルを活用した、RAG (検索拡張生成)を実行するフルマネージドサービスです。HAQM S3 などに格納されたデータのクロールおよび取得、変換、埋め込みの生成、ベクトルストアへの保存、LLM と連携した検索および回答生成まで、一連のフローをフルマネージドで提供します。

従来、Bedrock Knowledge Bases は HAQM OpenSearch Serverless をベクトルストアとしてサポートしていましたが、この度 HAQM OpenSearch Service のマネージドクラスターもサポートされました。OpenSearch Serverless では対応できなかった Sudachi プラグインの利用やカスタムパッケージ機能(辞書、シノニム)による、ハイブリッド検索における全文検索周りの精度改善を図ることができます。また、ディスクベースのベクトル検索や UltraWarm上のベクトルインデックスに対するベクトル検索といったコスト最適化のための機能も活用することが可能です。OpenSearch マネージドクラスターは利用者がインスタンスタイプ、インスタンスサイズ、ノード数といったスケール設定をコントロールできるため、ベクトルストアにかかるコスト制限にも役立ちます。

なお、本号執筆時点では、HAQM S3 のみをデータソースとしてサポートしています。既存の OpenSearch Serverless への切り替えについては、事前に検証してから臨まれることをお勧めいたします。その他利用上のポイントについては、「ナレッジベース用に作成したベクトルストアを使用するための前提条件」および「HAQM Bedrock ナレッジベースで OpenSearch マネージドクラスターを使用するために必要な前提条件とアクセス許可」をご確認ください。

HAQM OpenSearch Service ワークショップを公開

HAQM OpenSearch Service 検索ワークショップを公開しました。検索ワークショップは、日本語ユーザーをターゲットとした、OpenSearch の基本から最新の検索機能まで、段階的に学習することが可能なコンテンツです。Jupyter Notebook 形式で提供される「ラボ」を実行していくことで、OpenSearch を使用した検索機能の使い方を無理なく身に付けることができます。ノートブック中の解説は全て日本語で記載されており、使用するデータセットの多くも日本語を含む多言語対応のものを採用しています。Jupyter Notebook の内容はこちらよりご確認いただけます。ワークショップの詳しい紹介については、「HAQM OpenSearch Service による検索ワークショップ(日本語版)のご紹介」をご覧ください。

OpenSearch Project Tokyo が発足

OpenSearch コミュニティの拡大を受けて、「OpenSearch Project Tokyo」が発足しました。このユーザーグループは、OpenSearch に関心を持つエンジニアが集まり、知識や経験を共有する場です。Meetup.com を通じて定期的なミーティングを開催する予定です。OpenSearch に興味のある方は、ぜひご参加ください。

Hot Topic

OR2/OM2 リリースを記念して、OpenSearch 最適化インスタンスの特性を振り返る

OpenSearch 最適化インスタンスタイプは、インデックス作成スループットに特化した OpenSearch Service 独自のインスタンスタイプです。現在、OR2/OM2/OR1 の 3 種類のインスタンスタイプが利用可能です(東京では OR2/OR1 のみ)。OpenSearch 最適化インスタンスは、インデックス作成スループットの向上に加えて、以下のメリットを提供します。

レプリカ保持にかかるコストの削減
インデックス障害時の自動リカバリ
ノードリカバリ時、構成変更によるシャードリバランシングの抑制
自動スナップショット取得の高速化

これらのメリットは、OpenSearch の機能である Remote Backed Storage および Segment Replication によるものです。

Remote Backed Storage は、OpenSearch に格納されたドキュメントをニアリアルタイムに HAQM S3 などのオブジェクトストレージに同期する機能です。従来型のインスタンスは、データの冗長性を確保するためには、最低 1 つのレプリカをノード上のストレージに配置する必要がありました。最適化インスタンスタイプは S3 にレプリカを配置することでデータの冗長性を担保できるため、レプリカ保持にかかるコンピューティングリソースのコストを削減することが可能となりました。

また、S3 に常に最新のデータが保持されることで、リカバリ処理やシャードのリバランス処理、スケール処理も最適化されました。従来型のインスタンスタイプでは、ノード間でデータコピーを行うことでリカバリやリバランスを行っていました。対して最適化インスタンスタイプでは、S3 から最新のデータを取得する形でリカバリやリバランスを実行することで、データコピーの負荷を削減しています。

Remote Backed Storage と Segment Replication を併用することで、ノードと S3 間のデータコピーを効率化しています。従来型のインスタンスタイプでは、ノードに書き込まれたデータは、ドキュメント単位の論理同期の仕組みを採用していました。対して、最適化インスタンスタイプでは、セグメントと呼ばれる物理ファイル単位でデータを同期します。この仕組みにより、データ同期を効率よく行えるようになりました。最適化インスタンスタイプのスループットの高さは、S3 へ Segment Replication の仕組みで効率よくレプリカデータをコピーするアーキテクチャーに支えられているものです。

これまでに説明した通り、最適化インスタンスファミリーは従来型と比較して優れている点が多く存在します。一方で、インスタンスファミリー固有の制約には注意が必要です。最適化インスタンスタイプを使用する場合、データ登録から実際に検索可能になるまでに 10 秒程度要す場合があります。これは、refresh_interval パラメーターの最低値が 10 秒であるところからきています。この制約は、データ更新が頻繁に行われる検索ユースケースにおいて、採用可否を慎重に検討すべきポイントとなります。

逆に、秒単位での取り込み要件がないユースケース、例えばニアリアルタイムデータ分析や RAG などでは、採用しやすいといえます。直近で公開された株式会社タップルの事例でも、OR1 インスタンスがインフラストラクチャのコスト削減に貢献しました。

また、開発環境や社内業務で使用する検索エンジンといった、ノード障害によるダウンタイムが許容できるようなユースケースでは、最適化インスタンスタイプを思い切ってシングルノード構成で使う選択肢もあります。従来型のインスタンスタイプは、シングルノード構成は障害時のデータロスリスクがあり、障害時はスナップショットを用いた人手による復旧操作が必要です。一方、最適化インスタンスタイプは S3 上のデータを使用したデータリカバリ処理機能が備わっているため、データの復旧処理も自動で行われるなど、運用上のメリットがあります。

最適化インスタンスタイプの特性を理解し活用することで、コストパフォーマンスと運用の省力化を最大化することができます。現状のワークロードに適用することができないか、一度検討してみてください。

OpenSearch Project の最新動向 – 3.x でアーキテクチャーはどう変わるか？

OpenSearch Service のコアエンジンである OpenSearch は、3/18 に 3.0.0-alpha1 がリリースされました。現在 3.0.0-beta1 のリリース準備を進めており、4 月後半から 5 月前半にかけて GA となる予定です。 OpenSearch 3.x 系ではアーキテクチャーにかかわる重要なアップデートが予定されています。本号では、重要なアップデートにフォーカスして、OpenSearch Project のロードマップ情報をベースに解説していきます。

注意: 以降の案内は、 HAQM OpenSearch Service の今後の計画ではなく、オープンソース版 OpenSearch の開発ロードマップについてのものであることをご承知おきください。

アーキテクチャーのアップデート

OpenSearch 3.x ではアーキテクチャーの大幅なアップデートが予定されています。コンピュートとストレージの分離、インデックス作成と検索ワークロードの分離など、コンポーネントの疎結合化が進められています。ロギングやルールベースのフィルタリング機能を提供する Traffic Gateway といったコンポーネントの開発も始まっており、よりクラウドネイティブなアーキテクチャーに変化していく予定です。

また、コストパフォーマンス向上のための改善も行われる予定です。書き込み可能な Warm インデックス (Writable Warm Index)はその筆頭といえます。先に紹介した Remote Backed Storage はプライマリストレージをノードのローカルディスク、レプリカストレージをオブジェクトストレージとしていますが、Writable Warm Index はプライマリストレージをオブジェクトストレージにしています。ノードのローカルディスクは、ノードに送られたデータをオブジェクトストレージに同期するまでのバッファ、あるいは検索実行時のキャッシュとして活用することで、より柔軟な構成を実現可能です。

また、GRPC [#16710 / #16711] や Protobuf [#6844 / #10684] のサポートといった、内部的な改善も行われています。

データ取り込みパイプラインの拡充

OpenSearch 3.x では、インデックス構築やデータの取り込みを効率化する仕組みが導入される予定です。

ベクトルデータベースとしては、Remote Vector Index Build 機能が追加される予定です。同機能を活用すると、OpenSearch クラスターからリポジトリにアップロードされたベクトルデータをもとに、専用のビルドサービスでグラフの作成を実施することができます。本体のクラスターの負荷を削減するだけでなく、リモートサービスのノードを GPU インスタンスなどで構成することで、ベクトルインデックスの構築処理を高速化することも可能です。

更に、より効率よくデータを取り込むために、従来の Push 型のデータ取り込みに加えて、Apache Kafka や HAQM Kinesis Data Streams などのストリーミングプラットフォームからデータを取り込む Pull 型のデータ取り込みもサポートする予定です。Pull 型のデータ取り込みでは OpenSearch クラスターの内部でストリームのコンシューマーを実行する方向で設計が進められています。これにより、ストリームデータの取り込みをより容易に行うことが可能となります。

異なるデータストアからのデータ取り込みも計画されています。Data Prepper と呼ばれる ETL パイプラインツールでは、HAQM Aurora および RDS の MySQLと PostgreSQLエンジンをソースとしてサポートする計画があります。本機能のサポートによって、リレーショナルデータベースから OpenSearch へのデータ同期パイプライン構築のハードルが下がることが期待できます。

OpenSearch Project ロードマップの確認方法

こうしたアーキテクチャーの改善の他、シャードのオンライン分割やポイントインタイムリカバリの実現を見据えたスナップショットの改善、検索における Joinのサポートやクエリの最適化、Star Tree インデックスの改善による分析処理のパフォーマンス向上など、機能やパフォーマンスにかかわるアップデートも予定されています。

OpenSearch Project のロードマップは、OpenSearch Project サイトおよび Github 上で公開されています。OpenSearch のロードマップについてご興味がございましたら、是非これらの情報をご確認ください。

まとめ

本号では、HAQM OpenSearch Service の最新アップデートとして、OR2/OM2 インスタンスタイプの追加、Bedrock Knowledge Bases のマネージドクラスターサポート、検索ワークショップの公開、そして OpenSearch Project Tokyo の発足についてお伝えしました。また、OpenSearch 最適化インスタンスタイプの特性と活用法、そして OpenSearch 3.x で予定されているアーキテクチャーのアップデートについて解説いたしました。

次号でも、新機能のご紹介や実践的な機能解説をお届けしてまいります。どうぞご期待ください。

著者について

ソリューションアーキテクト榎本貴之(Takayuki Enomoto) (X: @tkykenmt)

2015 年に AWS Japan にクラウドサポートエンジニアとして入社し、HAQM OpenSearch Service を中心に顧客の課題解決を担当していました。2021 年より現職のスペシャリスト SA として、HAQM OpenSearch Service および HAQM MSK を中心とした、お客様システムにおける検索、分析、ストリーミング処理の導入および活用を支援しています。

HAQM Web Services ブログ