OpenSearchについて整理してみた

背景・目的

最近、Amazon OpenSearch Serviceに触れる機会が増えてきました。そこでOpenSearchの知識を整理しようと思います。

まとめ

下記に特徴をまとめます

特徴	説明
OpenSearchとは	Apache Luceneに基づく分散検索および分析エンジン OpenSearch にデータを追加すると、　下記の期待されるすべての機能を使用して、そのデータに対して全文検索を実行できる ・フィールドによる検索 ・複数のインデックスの検索 ・フィールドのブースト ・スコアによる結果のランク付け ・フィールドによる結果の並べ替え ・結果の集計など 優れたパフォーマンスを提供し、アプリケーションのニーズが拡大・縮小するのに合わせてスケールアップ・ダウンできる
Document	ドキュメントは、テキストまたは構造化データを保存する単位。JSONで保存される
Index	・インデックスはドキュメントのコレクション ・検索するときは、インデックスに含まれるデータをクエリする ・インデックスは、従来のDB内のデータベーステーブルを表す
Clusters and nodes	OpenSearch は分散検索エンジンとして設計されており、1 つ以上のノード上で実行できる OpenSearch クラスターはノードの集合
Nodes	下記のノードタイプがある。 ・Cluster manager ・Cluster manager eligible ・Data ・Ingest ・Coordinating ・Dynamic ・Search
Shards	インデックスをシャードに分割する。各シャードにはインデックス内のドキュメントのサブセットが格納される シャードの数が多いほど良いというわけではない 目安としては、シャードのサイズを 10～50 GB に制限する
Primary and replica shard	シャードはプライマリ (オリジナル) シャードまたはレプリカ (コピー) シャードのいずれかになる デフォルトでは、OpenSearch はプライマリ シャードごとにレプリカ シャードを作成する
Inverted index	OpenSearch インデックスは、転置インデックスと呼ばれるデータ構造を使用する 転置インデックスは、単語をその単語が出現するドキュメントにマッピングする
Relevance	ドキュメントを検索すると、OpenSearch はクエリ内の単語とドキュメント内の単語を照合する 各ドキュメントには関連性スコアが割り当てられ、そのドキュメントがクエリにどの程度一致したかを示す OpenSearch は BM25 ランキング アルゴリズムを使用してドキュメントの関連性スコアを計算し、関連性で並べ替えた結果を返す

概要

OpenSearch and OpenSearch Dashboards

Getting started

下記を基に整理します。

• Apache Luceneに基づく分散検索および分析エンジン
• OpenSearch にデータを追加すると、　下記の期待されるすべての機能を使用して、そのデータに対して全文検索を実行できる
  • フィールドによる検索
  • 複数のインデックスの検索
  • フィールドのブースト
  • スコアによる結果のランク付け
  • フィールドによる結果の並べ替え
  • 結果の集計など
• 優れたパフォーマンスを提供し、アプリケーションのニーズが拡大・縮小するのに合わせてスケールアップ・ダウンできる

コンポーネント

下記のコンポーネントが含まれる

• OpenSearch Dashboards
  • データ可視化のUI
• Data Prepper
  • 後続の分析と可視化のために下記が可能なデータコレクター
    • フィルタリング
    • エンリッチング
    • トランスフォーミング
    • 正規化
    • 集約
• Clients
  • 一般的な言語でOpenSearchと通信できるAPI

ユースケース

• Observability
  • PPL=Piped Processing Languageを使用してデータ駆動型イベントを視覚化し、保存されているデータを探索、検索、クエリする
• Search:
  • 語彙検索、機械学習（ML）を活用した会話型検索までアプリケーションに最適な検索方法を選択する
• Machine learning
  • アプリケーションにMLモデルを統合
• Security analytics
  • セキュリティの脅威を調査・検出・分析する

Introduction to OpenSearch

下記を基に整理します。

Document

• ドキュメントは、テキストまたは構造化データを保存する単位。JSONで保存される

Index

• インデックスはドキュメントのコレクション
• 検索するときは、インデックスに含まれるデータをクエリする
• インデックスは、従来のDB内のデータベーステーブルを表す

Clusters and nodes

• OpenSearch は分散検索エンジンとして設計されており、1 つ以上のノード上で実行できる
• OpenSearch クラスターはノードの集合

Creating a cluster

• 単一ノードのクラスタ、または複数ノードクラスタとして動作できる

• 下記は、4 ノード クラスターを含む基本アーキテクチャの例

  • 1 つの専用クラスターマネージャーノード
  • 1 つの専用コーディネーティング ノード
  • クラスター マネージャー対応でデータの取り込みにも使用される
  • 2 つのデータ ノード
  

  ※出典:Creating a cluster

Nodes

いくつかのノードタイプがあります。

Node type	説明	プロダクション向けのベストプラクティス
Cluster manager	クラスターの全体的な操作を管理し、クラスターの状態を追跡する 下記を行う ・インデックスの作成と削除 ・クラスターに参加および離脱するノードの追跡 ・クラスター内の各ノードの状態の確認 ・およびノー​​ドへのシャードの割り当て	3 つの異なるゾーンに 3 つの専用クラスター マネージャー ノードを配置する
Cluster manager eligible	投票プロセスを通じて、その中から 1 つのノードをクラスター マネージャー ノードとして選出する	専用のクラスター マネージャー ノードがあることを確認する。 これには、他のすべてのノードタイプをfalseとしてマークする
Data	データを保存および検索します。ローカル シャードですべてのデータ関連操作 (インデックス作成、検索、集計) を実行する クラスターのワーカーノード。多くのディスク容量が必要	データ ノードを追加するときは、ゾーン間でバランスが取れるようにする 例 ゾーンが 3 つある場合は、ゾーンごとに 1 つずつ、3 の倍数でデータ ノードを追加する
Ingest	データをクラスタに保存する前に、Pre-processを行う。 インデックスを追加する前に、変換する取り込みパイプラインを実行する	大量データや複雑なIngest パイプラインの場合は、専用ノードを推奨 また、データノードからインデックス作成をオフロードし、データノードを検索と集計専用に使用することも可能
Coordinating	クライアントの要求をデータノード上のシャードに委任し結果を収集して、1つの最終結果に集約しクライアントに返す	検索負荷の高いワークロードの場合、コーディネート専用ノードを複数用意する。その際には多くのコアCPUを使用することを推奨
Dynamic	MLタスクなどのカスタムワークロードに特定のノードをアサインすることで、データノードからのリソースの消費を防ぐ
Search	検索可能なスナップショットへのアクセスを提供 頻繁に使用されるセグメントをキャッシュし、最も使用頻度の低いデータセグメントを削除するなど行う	検索ノードには、スナップショット キャッシュとして割り当てられたインデックスが含まれるため、ディスクよりもCPUとメモリが多いノードを推奨

Shards

• インデックスをシャードに分割する。各シャードにはインデックス内のドキュメントのサブセットが格納される
  
  出典：Introduction to OpenSearch

• シャードは、クラスター内のノード間で均等に分散するために使用される

• 例

  • 400 GB のインデックスはクラスター内の単一のノードでは処理できないほど大きい可能性がある
    • 40 GB ずつの 10 個のシャードに分割すると、OpenSearch はシャードを 10 個のノードに分散し、各シャードを個別に管理できる

• 下記はインデックス 1 とインデックス 2 の 2 つのインデックスを持つクラスターの例
  
  出典：Introduction to OpenSearch

• シャードの数が多いほど良いというわけではない

• たとえば、400 GB のインデックスを 1,000 個のシャードに分割すると、クラスターに不必要な負担がかかる

• 目安としては、シャードのサイズを 10～50 GB に制限する

Primary and replica shards

• シャードはプライマリ (オリジナル) シャードまたはレプリカ (コピー) シャードのいずれかになる
• デフォルトでは、OpenSearch はプライマリ シャードごとにレプリカ シャードを作成する
  • インデックスを 10 個のシャードに分割すると、OpenSearch は 10 個のレプリカ シャードを作成する
• 例

  • クラスター内の各インデックスの各シャードにレプリカを 1 つ追加する

  • 下記のようにクラスターにはインデックス 1 に合計 2 つのシャードと 2 つのレプリカ

  • インデックス 2 に合計 4 つのシャードと 4 つのレプリカが含まれる
    
    出典：Introduction to OpenSearch

  • レプリカシャードは、ノード障害が発生した場合のバックアップとして機能する

  • OpenSearchはレプリカシャードを対応するプライマリシャードとは異なるノードに配布する

  • クラスタが検索リクエストを処理する速度も向上する

Inverted index

• OpenSearch インデックスは、転置インデックスと呼ばれるデータ構造を使用する
• 転置インデックスは、単語をその単語が出現するドキュメントにマッピングする

Relevance

• ドキュメントを検索すると、OpenSearch はクエリ内の単語とドキュメント内の単語を照合する

• 各ドキュメントには関連性スコアが割り当てられ、そのドキュメントがクエリにどの程度一致したかを示す

• 検索クエリ内の個々の単語は検索用語と呼ばれます。各検索用語は次のルールに従ってスコア付けされる

  1. ドキュメント内でより頻繁に出現する検索用語は、より高いスコアが付けられる傾向がある
     • 例:犬に関する文書で「犬」という単語を何度も使用している文書は、「犬」という単語をあまり使用していない文書よりも関連性が高いと考えられる
     • the　frequency component of the score
  2. より多くのドキュメントに出現する検索用語は、スコアが低くなる傾向がある
     • 例：「blue」と「axolotl」という用語のクエリでは、より一般的な単語である「blue」よりも「axolotl」を含むドキュメントが優先される
     • the　inverse document frequency component of the score.
  3. 長いドキュメントでの一致は、短いドキュメントでの一致よりもスコアが低くなる傾向がある
     • 完全な辞書を含むドキュメントは、どの単語にも一致しますが、特定の単語とはあまり関連性がない
     • the　length normalization component of the score.

• OpenSearch は BM25 ランキング アルゴリズムを使用してドキュメントの関連性スコアを計算し、関連性で並べ替えた結果を返す

Advanced concepts

Update lifecycle

• 更新操作のライフサイクルは、次の手順で構成される
  1. 更新はプライマリ シャードによって受信され、シャードのトランザクション ログ (トランスログ) に書き込まれる。更新が確認される前に、トランスログがディスクにフラッシュされ、 その後 fsync が実行される
  2. 更新は Lucene インデックス ライターにも渡され、メモリ内バッファーに追加される
  3. 更新操作では、Lucene インデックス ライターはメモリ内のバッファーをディスクにフラッシュし (各バッファーは新しい Lucene セグメントになる)、結果のセグメント ファイルに対して新しいインデックス リーダーが開かれ、更新内容が検索で表示される
  4. フラッシュ操作では、シャードは Lucene セグメントを fsync する。セグメント ファイルは更新の永続的な表現であるため、耐久性を提供するためにトランスログは必要なくなり、更新はトランスログから消去できる

Translog

• インデックス作成または一括呼び出しは、ドキュメントがトランスログに書き込まれ、トランスログがディスクにフラッシュされたときに応答する
• 更新は永続的
• 更新は、更新操作が完了するまで検索要求には表示されない

Refresh

• OpenSearch は定期的に更新操作を実行し、メモリ内の Lucene インデックスからファイルにドキュメントを書き込む
• fsync が実行されないため、これらのファイルの耐久性は保証されない
• 更新すると、ドキュメントが検索可能になる

Flush

• フラッシュ操作は、fsync を使用してファイルをディスクに保存する
• フラッシュにより、トランスログにのみ保存されたデータが Lucene インデックスに記録される
• OpenSearch は、トランスログが大きくなりすぎないように、必要に応じてフラッシュを実行する

Merge

• OpenSearch では、シャードはセグメント (またはセグメント ファイル) で構成される Lucene インデックス
• セグメントにはインデックス化されたデータが保存され、変更できない
• 定期的に、小さなセグメントが大きなセグメントにマージされる
• マージすると、各シャード上のセグメントの総数が減り、ディスク領域が解放され、検索パフォーマンスが向上する
• 最終的に、セグメントはマージ ポリシーで指定された最大サイズに達し、それ以上大きなセグメントにマージされなくなる
• マージ ポリシーでは、マージを実行する頻度も指定する

考察

今回、OpenSearchについて整理してみました。次回はVector Searchについて整理してみたいと思います。

参考