Jira Data Center 向け OpenSearch
このページでは、OpenSearch と Lucene 検索プラットフォームの違いについて説明します。Jira では Lucene が既定で使用されます。OpenSearch は Jira 11.2 以降で使用できます。
Lucene の代わりに OpenSearch を使用することで、Jira を高速化し、必要な Jira ノードの数を減らし、より安価なハードウェアを使用できるようになります。OpenSearch のハードウェアに関する推奨事項については、こちらをご確認ください。
Jira インスタンスの拡大に伴って、チームのペースに遅れずに対応できる検索機能が必要になります。そのため、Jira Data Center では、既定の Lucene 検索エンジンに代わるオプトインの代替手段として OpenSearch が提供されるようになりました。OpenSearch は組織に合わせて拡張できるように設計されており、マルチノード インスタンスを使用して最もプロセス集約的なインデックス化にも対応できます。インスタンスがどれだけ大きくなっても、ユーザーの検索エクスペリエンスはこれまでと変わらず、速度や信頼性は向上しています。
本ページの内容:
Jira での OpenSearch
Jira での OpenSearch は単なる検索機能ではありません。ボードの読み込みやバックログの表示、レポートの生成、課題への対応まで、あらゆる操作をサポートします。非常に多くのコア アクションが検索を利用しているため、OpenSearch のスピード、一貫性、信頼性はチームの生産性とエクスペリエンスに直接影響します。
OpenSearch とは
OpenSearch は、オープンソースで分散型の検索および分析スイートです。これは、Elastic がライセンス モデルを変更した後に Amazon Web Services (AWS) によって作成された、Elasticsearch 7.10 のコミュニティ主導のフォークとして始まりました。OpenSearch は、高度な検索機能とリアルタイム分析を提供します。
OpenSearch を使用すると、次のことが可能になります。
インスタンスのパフォーマンスを向上させる(パフォーマンス テストの結果を見る)。
分散型アーキテクチャにより、増大するデータ量とユーザー負荷に対応し、確実に拡張する。
インデックス管理を簡素化し、Jira 全体のリソース消費量を削減する。
クラスター化された OpenSearch インスタンスにおいて、インデックスの再作成中であっても中断なく検索の実行を継続する。
完全テキスト検索機能を使用して必要なコンテンツをすばやく見つける。
データと検索パターンに関するリアルタイムのインサイトを取得する。
プラグインと API を使用して、検索機能をカスタマイズおよび拡張する。
組み込みのセキュリティ、アラート、監視機能でデータを安全に保ち、常に最新情報を入手する。
OpenSearch と Lucene の相違点
OpenSearch は Jira インスタンスに運用上のメリットをもたらし、検索および分析機能を強化します。
OpenSearch | Lucene | |
|---|---|---|
運用上の相違点 | ||
新しいノードの起動 | すべてのノードが単一の最新インスタンスに接続されるため、新しいノードはすばやく起動し、すぐに検索リクエストに対応できます。 | 新しいノードを Lucene クラスターに参加させる場合、検索インデックス全体をコピーまたは再構築し、最近の変更を再現する必要があります。 |
検索結果 | すべての変更をすべてのノードで利用できるため、検索結果が古くなったり、矛盾したりするリスクが軽減されます。最新情報は短い更新間隔 (既定では 1 秒) の後にクラスター全体で共有されるため、サイトのインデックスを完全に再作成する必要性が最小限に抑えられます。 | クラスター内のノードによって Lucene ドキュメントに変更が加えられると、その変更はまずローカル インデックスに対して行われ、次にクラスター内の他のノードに伝播されます。つまり、ノードを拡張または追加するときに、結果が古くなったり、オーバーヘッドが増大したりするリスクが高まります。 |
インデックスのスケーラビリティ | すべてのノードが専用の OpenSearch クラスターに接続されるため、Jira クラスターとは別に検索インデックスを拡張できます。つまり、必要に応じて検索インフラストラクチャを拡張しながら、より小規模で費用対効果の高い Jira ノードを使用できます。 | すべてのノードでインデックスの完全なコピーを保存する必要があるため、大量のディスク容量とメモリが必要になります。 |
検索と分析の相違点 | ||
組み込みの検索機能 | 分散型アーキテクチャにより、高速で信頼性の高い検索が維持されます。プラグインとモジュールを使用して機能を拡張できます。 | 拡張性のための組み込みプラグインやモジュール システムはありません。カスタム Java コードを記述することで拡張できます。 |
トレース分析 | 検索インデックスをアプリとは別に監視できます。トレース分析は、分散したトレース データを詳細に分析して視覚化するため、ボトルネックを特定したり、パフォーマンスを最適化したりすることができます。この機能は、マイクロサービス アーキテクチャのデバッグと最適化に役立ちます。 | 組み込みのトレース分析や分散型トレースの視覚化には対応していません。 |
インデックス管理 | OpenSearch は、削除ポリシーに基づいてインデックス処理を自動化します。よりスマートなリソース活用と効果的なデータ ライフサイクル管理が可能になり、管理タスクが簡素化され、整理された検索環境を維持できます。 | インデックス管理は手動で行うため、削除とクリーンアップは自分で処理する必要があります。 インデックス ライフサイクルの監視やポリシー主導の自動化は組み込まれていないため、データが増加するにつれて多大な労力がかかり、エラーが発生しやすくなります。 |
パフォーマンス テストの結果
OpenSearch により、Jira 全体のパフォーマンスと信頼性が向上します。内部テストの結果、特にインスタンスが大きくなったときに、OpenSearch によってスケール関連のパフォーマンスの問題を大幅に改善できることがわかっています。
ベンチマーク結果によると、応答時間の 95 番目のパーセンタイル (P95) に基づいた場合、OpenSearch を使用すると、Lucene ベースのインスタンスに比べて全体的なパフォーマンスが 38% 向上しています。これは、測定されたすべての応答時間の 95% がこの値よりも速いことを意味しており、高負荷条件でのシステムのパフォーマンスを示す良い指標となります。
テストの詳細: 社内の 5 ノード Jira Data Center インスタンスで 14 GB の Lucene インデックスをベンチマークし、Lucene と OpenSearch を比較しました。テストのワークロードは、約 25% の書き込み操作と 75% の検索操作 (JQL 検索、ボード、バックログ、課題の表示を含む) で構成され、210 人の仮想ユーザーが同時に使用されました。同じテストを 2 つの別々のインスタンスで実行しました。一方では Lucene を使用し、もう一方では OpenSearch を使用しました。Jira 向け OpenSearch ハードウェア推奨事項の詳細については、こちらをご確認ください。
応答時間
ベンチマークの結果によると、OpenSearch の応答時間は Lucene よりも約 38% 速いことがわかりました。このパフォーマンス ギャップは、データセットが大きくなるにつれて広がります。
メトリック | Lucene | OpenSearch |
|---|---|---|
P95 応答時間 (低いほど良い) | 813ms | 500ms |
P90 応答時間 (低いほど良い) | 472ms | 348ms |
エラー率 | 0% | 0% |
インデックスの完全再作成のパフォーマンス
完全なインデックス再作成を手動でトリガーしたところ、OpenSearch が Lucene よりも速くプロセスを完了したことがわかりました。しかし、OpenSearch の真の利点は、インデックス再作成を頻繁に行う必要がないことです。すべてのノードで更新が迅速に共有されるため (既定では毎秒)、OpenSearch がデータの整合性を維持し、サイト全体のインデックス再作成の必要性を低減します。
検索プラットフォーム | 時間 (低いほど良い) |
|---|---|
Lucene | 102 分 |
OpenSearch | 47 分 |
Jira ノードのリソース使用量
内部ベンチマークによると、OpenSearch はメモリー消費とガベージ コレクションのオーバーヘッドを削減し、スレッドの競合を大幅に減らし、Lucene で見られる I/O の異常を排除します。
OpenSearch では、より少ない数の Jira ノードで同じレベルのパフォーマンスを実現できます。たとえば、Lucene ベースのクラスターが最適なパフォーマンスを維持するには、通常 5 つのノードが必要です。一方、OpenSearch では 3 つのノードだけで同様の結果を得られます。つまり、Jira クラスターをスケール ダウンして、インフラストラクチャ コストを削減しながら、高速かつ信頼性の高い検索する体験をユーザーに提供できます。
メトリック | Lucene (5 ノード) | OpenSearch (3 ノード) | 注意 |
|---|---|---|---|
CPU 使用率 (ピーク) | 72.6% | 50% | OpenSearch では、CPU 使用率が約 31% 減少しています。 |
メモリ使用率 (ピーク) | 8.87 GB | 4.42 GB | OpenSearch では、CPU 使用率が大幅に減少しています。 |
ガベージ コレクション |
|
| OpenSearch ではイベント数が減少して、一時停止時間が短縮されます。 |
ソケット入出力の異常 (ネットワーク データ読み取り操作における予期せぬ長時間の遅延) | 5B の読み込み: 4.17 秒 | なし | OpenSearch では異常なし。 |
スレッド競合 |
|
| OpenSearch を使用すると、ブロックされたスレッドが減少して、処理時間が大幅に短縮されます。 |
Jira ノード数 | 5 | 3 | OpenSearch は、より少ないノード数で同様のパフォーマンスを実現します。 |
切り替えのご相談や、
OpenSearch は、チームやデータがどんなに大きくなっても、Jira インスタンスの成長、パフォーマンス、信頼性の維持に役立つように設計されています。より高速な検索、簡単なスケーリング、回復力のあるプラットフォームを利用する準備ができたら、Jira Data Center インスタンス向けに OpenSearch を有効にすることをご検討ください。