Confluence Data Center 向け OpenSearch
このページでは、OpenSearch と Lucene 検索プラットフォームの違いについて説明します。既定では、Confluence は Lucene を使用します。
Lucene よりもパフォーマンス、スケーラビリティ、信頼性が向上するため、OpenSearch に切り替えることをお勧めします。OpenSearch は Confluence 9.2 以降で使用できます。
Confluence サイトの拡大に伴って、チームのペースに遅れずに対応できる検索機能が必要になります。そのため、Confluence Data Center では、既定の Lucene 検索プラットフォームに代わるオプトインの代替手段として OpenSearch が提供されるようになりました。OpenSearch は組織に合わせて拡張できるように設計されており、マルチノード インスタンスを使用して最もプロセス集約的なインデックス作成にも対応します。サイトがどれだけ大きくなっても、ユーザーの検索エクスペリエンスはこれまでと変わらず、速度や信頼性は向上しています。
On this page:
OpenSearch とは
OpenSearch は、オープンソースで分散型の検索および分析スイートです。これは、Elastic がライセンス モデルを変更した後に Amazon Web Services (AWS) によって作成された、Elasticsearch 7.10 のコミュニティ主導のフォークとして始まりました。OpenSearch は、高度な検索機能とリアルタイム分析を提供します。
OpenSearch を使用すると、次のことが可能になります。
インスタンスのパフォーマンスを向上させる。パフォーマンス テストの結果を見る
インデックス管理を簡素化し、Confluence 全体のリソース消費量を削減する。
クラスター化された OpenSearch インスタンスにおいて、インデックスの再作成中であっても中断なく検索の実行を継続する。
完全テキスト検索機能を使用して必要なコンテンツをすばやく見つける。
データと検索パターンに関するリアルタイムのインサイトを取得する。
アプリと API を使用して、検索機能をカスタマイズおよび拡張する。
組み込みのセキュリティ、アラート、監視機能でデータを安全に保ち、常に最新情報を入手する。
OpenSearch は Confluence インスタンスに運用上のメリットをもたらし、検索および分析機能を強化します。
OpenSearch | Lucene | |
|---|---|---|
運用上の相違点 | ||
新しいノードの起動 | すべてのノードが単一の最新インスタンスに接続されるため、新しいノードはすばやく起動し、すぐに検索リクエストに対応できます。 | 新しいノードを Lucene クラスターに参加させる場合、検索インデックス全体をコピーまたは再構築し、最近の変更を再現する必要があります。 |
検索結果 | すべての変更をすべてのノードで利用できるため、検索結果が古くなったり、矛盾したりするリスクが軽減されます。最新情報は短い更新間隔 (既定では 1 秒) の後にクラスター全体で共有されるため、サイトのインデックスを完全に再作成する必要性が最小限に抑えられます。 | クラスター内のノードによって Lucene ドキュメントに変更が加えられると、その変更はまずローカル インデックスに対して行われ、次にクラスター内の他のノードに伝播されます。つまり、ノードを拡張または追加するときに、結果が古くなったり、オーバーヘッドが増大したりするリスクが高まります。 |
インデックスのスケーラビリティ | すべてのノードが専用の OpenSearch クラスターに接続されるため、Confluence クラスターとは別に検索インデックスを拡張できます。つまり、必要に応じて検索インフラストラクチャを拡張しながら、より小規模で費用対効果の高い Confluence ノードを使用できます。 | すべてのノードでインデックスの完全なコピーを保存する必要があるため、大量のディスク容量とメモリが必要になります。 |
検索と分析の相違点 | ||
組み込みの検索機能 | 分散型アーキテクチャにより、高速で信頼性の高い検索が維持されます。プラグインとモジュールを使用して機能を拡張できます。 | 拡張性のための組み込みプラグインやモジュール システムはありません。カスタム Java コードを記述することで拡張できます。 |
トレース分析 | 検索インデックスをアプリとは別に監視できます。トレース分析は、分散したトレース データを詳細に分析して視覚化するため、ボトルネックを特定したり、パフォーマンスを最適化したりすることができます。この機能は、マイクロサービス アーキテクチャのデバッグと最適化に役立ちます。 | 組み込みのトレース分析や分散型トレースの視覚化には対応していません。 |
インデックス管理 | OpenSearch は、削除ポリシーに基づいてインデックス処理を自動化します。よりスマートなリソース活用と効果的なデータ ライフサイクル管理が可能になり、管理タスクが簡素化され、整理された検索環境を維持できます。 | インデックス管理は手動で行うため、削除とクリーンアップは自分で処理する必要があります。 インデックス ライフサイクルの監視やポリシー主導の自動化は組み込まれていないため、データが増加するにつれて多大な労力がかかり、エラーが発生しやすくなります。 |
パフォーマンス テストの結果
OpenSearch により、Confluence 全体のパフォーマンスと信頼性が向上します。内部テストの結果、特にインスタンス数が増加したときに、OpenSearch によってスケール関連のパフォーマンスの問題を大幅に改善できることがわかっています。
ベンチマーク結果によると、OpenSearch は同等の Lucene ベースの検索よりも約 4.5 倍高速です。このパフォーマンス ギャップは、データセットが大きくなるにつれて広がります。
テストの詳細: 内部の 3 ノード Confluence インスタンスで 36GB のインデックスを評価し、Lucene (8 CPU、32GB RAM) と OpenSearch (2 CPU、16GB RAM) を比較しました。
CQL 検索のパフォーマンス
GitHub DC アプリ パフォーマンス ツールキットを使用して、200 人の同時ユーザーによる 1 時間あたり 20,000 アクションをシミュレートしました。結果は次のようになりました。
検索プラットフォーム | 応答時間の中央値 (低いほど良い) |
|---|---|
Lucene (ベースライン) | 2.34 秒 |
OpenSearch | 0.66 秒 |
インデックスの完全再作成のパフォーマンス
インデックスの完全再作成を手動でトリガーしたところ、OpenSearch は Lucene よりも速くプロセスを完了したことがわかりました。
OpenSearch のインデックス再作成はそれほど高速ではないかもしれませんが、最新情報は短い更新間隔 (既定では 1 秒) の後にクラスター全体で共有されます。このアプローチにより、Lucene と比べて、サイトのインデックスを完全に再作成する必要性が軽減されます。
検索プラットフォーム | 時間 (短いほど良い) |
|---|---|
Lucene | 4 時間 59 分 |
OpenSearch | 4 時間 36 分 |
切り替えのご相談や、
OpenSearch は、チームやデータがどんなに大きくなっても、Confluence サイトの成長、パフォーマンス、信頼性の維持に役立つように設計されています。より高速な検索、簡単なスケーリング、回復力のあるプラットフォームを利用する準備ができたら、Confluence Data Center インスタンス向けに OpenSearch を有効にすることを検討してください。