OpenSearch の構成要素
はじめに
業務で OpenSearch を使う機運が高まってきたので、OpenSearch の構成要素や用語をまとめてみました。
OpenSearch とは
OpenSearchは、Elasticsearch 7.10.2 をフォークして開発された、オープンソースの全文検索・分析エンジンです。
OpenSearchは、Elasticsearch と同様に大量データの検索や解析を高速に行うことができます。
OpenSearch と Amazon OpenSearch Service
サービス名が似ているので混乱しやすいですが、OpenSearch とは前述の通りオープンソースの全文検索・分析エンジンです。
Amazon OpenSearch Service は、AWS が提供する OpenSearch を簡単にデプロイ・管理、スケール可能なフルマネージドサービスです。
OpenSearch の論理的構成要素
Index
ドキュメントの集合、RDBMS でいうところのデータベース。
余談ですが、インデックスをドキュメントに登録することを「インデックスする」と言います。
Document
データを格納する最小単位。JSON 形式で保存され、複数のフィールドを様々なデータ型で持つことができる。
RDBMS でいうところのレコード。
{
"name": "John Doe",
"age": 25,
"email": "[email protected]"
}
Field
ドキュメント内のキーと値からなる要素。RDBMS でいうところのカラム。
Mapping
インデックスに格納されるデータの構造と型を定義するもの。RDBMS でいうところのスキーマ定義。
OpenSearch の物理的構成要素
Cluster
クラスターとは、複数のノードを1つのユニットとして管理し、検索や管理を行う分散システムです。
Node
OpenSearch のプロセスが動作する単一のサーバーを指します。
基本的には、1つのノードは1つの OpenSearch プロセスで構成します。
1つのノードで複数の OpenSearch プロセスを動作させる事は一般的には推奨されていないようです。
以下は、Elasticsearch ディスカッションの内容ですが、OpenSearch でも同様の考え方が適用されると思われます。
Unless you have a large bare-metal server with 128 GB RAM or more, having multiple nodes on the same host does not makes much sense.
You will have multiple small nodes competing for the same resources, elasticsearch is more bound to the disk and memory than to the CPU cores and in the end if your host fails, your entire cluster fails. In this case is better to have a larger node instance.
But to run multiple nodes in the same hosts you need to have a different elasticsearch.yml for every node with separated data and log folders, there isn't a way to use the same elasticsearch.yml to run multiple nodes at the same time.
Even if you have large servers with 128 GB or more, I would recommend to use docker to run the instances instead of configure multiple nodes in the same host.
意訳
大きなベアメタルサーバー（128GBのRAM以上）を持たない限り、同じホストで複数のノードを実行することにはあまり意味がありません。
なぜなら、複数の小さなノードがリソースを争い、Elasticsearch は CPU コアよりもディスクとメモリに依存しているためです。ホストが故障した場合には、クラスター全体がダウンします。その場合、より大きなノードインスタンスを使用する方が良いでしょう。
同じホストで複数のノードを実行するには、各ノードごとに異なる設定ファイル（elasticsearch.yml）と分離されたデータおよびログフォルダーが必要です。同じ設定ファイルを使って複数のノードを同時に実行する方法はありません。
128GB以上の大きなサーバーを持っている場合でも、同じホストで複数のノードを設定する代わりに、インスタンスを実行するためにDockerを使用することをお勧めします
Node Roles
ノードロールとは、ノードがクラスター内でどのような目的と責任を持つかを定義するものです。
クラスタの設定に基づいて、各ノードに複数のロールを割り当てることができます。
明示的にロールを指定しない場合、自動的にデフォルトのロールとして Cluster Manager Eligible、Data、Ingest、Coordinating が付与されるようです。（OpenSearch 2.13）
※ 下記は一部です。その他のノードロールについては公式ドキュメントを参照してください。
Cluster Manager
クラスタ全体の運用を管理するノード。
インデックスの作成と削除、クラスターへのノードの参加と離脱の監視、各ノードのヘルスチェック（pingリクエスト）およびシャードの割り当てを含みます。
Elasticsearch で使われる master node という用語は、OpenSearch では cluster manager node に置き換えられています。
恐らくですが、よりニュートラルな用語として変更されたのだと思われます。（Splunk でも同様に master node という用語は使用されなくなっています。manager node）
Cluster Manager Eligible
クラスタマネージャーに障害が発生した際に、クラスタマネージャーとして機能することができる資格を持ったノード。
Data
クラスタ内でデータを格納し、検索および索引付けなどのデータ関連操作を実行するノード。
ロールから予想はつきますが、他のどのノードタイプよりも多くのディスク容量を必要とします。
Ingest
ドキュメントをインデックスに保存する前処理を行うノード。
データの形式を変更したり、不要な情報をフィルタリングしたり、データに追加の情報を付与などができる。
Coordinating
クラスターの HTTP(S) リクエスト、インデックス作成リクエストと検索リクエストを処理するノード。
Coordinating ロールを持つノードが Cluster Manager Eligible、Data ではない場合、Coordinating Only（CO）ノードと呼ばれます。
CO はデータノードとマスターノードを、HTTP(S)リクエストのリソース要求から隔離することができるため、クラスタのパフォーマンスを向上させることができるようです。（OpenSearch Coordinating Node）
Shard
シャードはインデックスを分割したものです。これらノードから成るクラスターで並列処理や分散ストレージを可能にしています。
シャードには、プライマリーシャードとレプリカシャードの2つの種類があります。
プライマリーシャードはオリジナルのデータを保持し、レプリカシャードはプライマリーシャードのコピーを保持します。
レプリカシャードは何かしらの障害でプライマリーシャードが利用できなくなった場合に、データの可用性を高めるために使用されます。
また、検索リクエストをプライマリーシャードとレプリカシャードに分散することで、検索のパフォーマンスを向上させることができます。
シャードは内部的には Lucene のインデックスであり、それぞれが独自の Lucene プロセスとして動作します。
シャードの数が増えると、それぞれのプロセスがリソースを消費するため、全体的なシステムのオーバーヘッドが増加します。
そのため、シャード数は適切に分割することが重要のようです。
OpenSearch では、理想的なシャードサイズとして1シャードあたり10～50GBを推奨しています。
シャードあたり10～30GBは、アプリケーションの検索や読み込みの負荷が高い場合に推奨され、30～50GBは、ログ分析のような書き込み負荷の高いワークロードに適しているようです。
Discussion