高可用性で検索を維持する：並行再インデックスモードと同期再インデックスモード（BETA）

ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

ハイライト

機能

1. 複数の再インデックスモード: Full Reindex, Concurrent Reindex (Blue/Green), and Sync Reindex.
2. 高可用性: セレクトモードによるインデックス再作成作業中もサービスを継続。
3. System Configuration Options: デフォルトの再インデックス・モードを設定する。
4. ユーザーインターフェースの強化: 関連するタイプのグループ化、人間にとって使いやすい名前。
5. タイムスタンプの実装: Elasticsearchのすべてのドキュメントにはタイムスタンプが付与されています。
6. リソース管理: Elasticsearchのコンカレントモードにおけるディスク容量の見積もり。
7. エラー管理: コンカレント・リインデックスに失敗した場合、元のインデックスにフォールバックする。

能力

1. Clean Slate Reindexing: Full Reindex mode deletes and recreates indexes.
2. Parallel Index Creation: Concurrent mode creates a new index alongside the old one and populates it.
3. 更新優先のアプローチ：  同期 モードでは、最初の削除を行わずに既存の文書を更新します。
4. 設定のカスタマイズ: デフォルトの再インデックス・モードを設定する機能。
5. 簡単な識別と操作: より良いナビゲーションのための改良されたユーザーインターフェース。
6. Staleness Detection: タイムスタンプは、古くなった文書を識別するのに役立つ。
7. Preventive Resource Management: ディスク容量が不足する可能性がある場合、ユーザーに警告を発する。
8. Continuous Operation: インデックス再作成に問題が発生しても、システムは運転を継続する（コンカレント・モード）。

メリット（特典）

1. ダウンタイムの削減: ユーザーは、再インデックス操作中もコンテンツの検索とアクセスを継続できる。
2. 柔軟性: 管理者は、シナリオに最も適した再インデックス作成モードを選択できる。
3. オペレーションの効率化： リソースの制約による潜在的な停止や減速を防ぎます。
4. Efficient Resource Utilization: 高度な警告により、リソース不足によりシステムがクラッシュする可能性のある操作を防止（コンカレントモード使用時）。

コンテキスト

検索は、コンテンツや商品（今後は、 コンテンツ）を発見するための、現代のあらゆるサイトの基本的な機能である。

これを正しく行うには、コンテンツを（全文）検索用に最適化された特別なフォーマットで保存する必要がある。このフォーマットは、Elasticsearchのような検索エンジンの中にある、 検索インデックス と呼ばれる。 ウェブコンテンツ記事、オブジェクトエントリとそのカテゴリやタグのようなコンテンツ、ユーザー、組織などのような他のタイプは、デフォルトですべてLiferayでインデックス化されています。

 

検索インデックスは、 Search Bar を通してユーザーの検索を提供するためだけのものではありません。フードの下では、ユーザーがUI上やヘッドレスAPIを通してやりとりする、Liferayのすぐに使えるアプリケーションや機能の多くも動かしています。

変更を反映させ、データベースと検索インデックスが同期していることを確認するために、Liferayは  コントロールパネル - 設定 - 検索 > インデックスアクションで reindex と呼ばれる操作を実行する機能を提供しています。

 

問題点

再インデックス

時間の経過とともに、検索インデックスはメンテナンスを必要とする。 Liferayの機能が進化するにつれて、アップグレードによってデータがインデックスされる方法が変更されたり、ステージングパブリケーションの失敗やLiferayとElasticsearch間の接続の停止によってインデックスデータが古くなったりすることがあります。

再インデックスの方法

検索インデックスの完全性を維持することは課題である。 インデックスの再作成は改善策ですが、Liferayの伝統的な "delete-first & index again"（後述）のアプローチは、リソースを大量に消費し、顕著なダウンタイムを引き起こし、ユーザーエクスペリエンスとシステム運用に悪影響を及ぼします。

ビジネスインパクト

1. ユーザーの混乱： 従来の再インデックス作成方法では、大幅なダウンタイムが発生し、ユーザーが関連コンテンツに効率的にアクセスできなくなります。
2. 運用上のオーバーヘッド: インデックス再作成作業は、最適化されていない場合、多大なリソースを消費し、システムの遅延や停止につながる可能性がある。
3. データの完全性: 定期的かつ効率的な再インデックス作成が行われないと、検索インデックスに古いデータや無関係なデータが表示され、プラットフォームの信頼性が損なわれる可能性がある。
4. スケーラビリティに関する懸念: データ量が増大するにつれ、高可用性モードを使用しないインデックス再作成の管理はますます困難になり、スケーラビリティに影響を与える可能性があります。
5. 事業継続リスク: 古い検索インデックスやずれた検索インデックスは、検索機能に依存する重要な事業運営に支障をきたし、潜在的な収益損失につながる可能性がある。
6. メンテナンス・コスト: 頻繁で非効率的な再インデックス作成は、メンテナンス・コストの増加につながる。

望ましい成果

目標は、ビジネス継続性と高可用性を提供するために、本番環境の検索およびインデックス作成機能への影響を最小限またはゼロに抑えて再インデックスを実行する方法を提供することであった。

私たちがしてきたこと

U98 からは、 two new reindex execution modes が Betaとして利用可能になる：

•  コンカレント
•  同期

Liferay が Elasticsearch を検索エンジンとして使用している場合。

新しい再インデックスモード は、さまざまなシナリオで便利です 管理者が Liferay の検索データを 高可用性で運用・管理するためのより良い選択肢を提供します。

その利点と使用するタイミングを理解するために、 Full reindexがどのように機能するのか（デフォルトモードとして使用可能なままである）をまず復習しておこう。

 コントロールパネル - 設定 - 検索 > U98の実行モードを持つインデックスアクション。

完全再インデックス・モード

一言で言えば、 デフォルトの完全再インデックス・モード は、「最初に削除し、 & インデックスを再作成する」戦略に従っている。

つまり、アクションを実行するときに

• Reindex All Search Indexes: インデックスが削除され（すべてのコンテンツ／データが消去され）、その後プロセスの最初に再作成され、コンテンツが再びインデックスされる；

• Reindex Individual Types (つまり、ユーザー): 選択されたタイプに対応するドキュメントは、プロセスの最初にインデックスから削除され、その後、コンテンツは再びインデックスされます。

削除を優先する動作のため、このモードは混乱を招き、操作の実行中にダウンタイムが発生したり、結果が出なかったりする。

すべてのデプロイメントが破壊的な性質の悪影響の影響を等しく受けるわけではないので、デフォルトのままである。

同時再インデックス・モード

このモードは、Reindex All Search Indexes アクションでのみ使用できる。 ブルー／グリーンの再インデックスとしても知られている。 BETA

( Elasticsearch のみ)

プロセスの最初に、2つ目の新しい（"green"）インデックスが、最新のストレージ命令（別名、フィールドマッピング）で作成され、コンテンツがインデックス化される。

一方、現在のオリジナルの（"blue"）インデックスは、全作業を通じて使用され続け、高い可用性を提供する暫定的な検索に対応する。

更新（コンテンツの作成/更新/削除やユーザーのアクションに起因する）は、操作中に元のインデックスと新しいインデックスの両方に同時に送信される（これが concurrent の性質に由来する）。

新しいインデックスが作成されると、プラットフォームは元のインデックスを削除し、リクエスト（検索と書き込みの両方）を新しいインデックスに向ける。

同期再インデックス・モード

このモードは、Reindex All Search IndexesとReindex Single Typeの両方のアクションで利用できる。 ソフト・リインデックスとも呼ばれる。 BETA

( Elasticsearch のみ)

一言で言えば、シンクの再インデックス・モードは、"index again & delete-last" 戦略に従う。 このモードは、インデックス内の文書を削除せずに更新することから始まる。 プロセスの最後に、DXP 7.4 U90からすべての文書に入力される タイムスタンプ フィールドに従って、古くなった文書が削除されます。

インデックス・モードの比較

この比較は、さまざまなモード、その主な特徴、そしてどのような場合に使用することが推奨されるかを理解するためのものである。

	Full	Concurrent	Sync
Feature Status	GA	BETA	BETA
Provides High-Availability		☑	☑
Available with Action:  Reindex All Search Indexes	☑	☑	☑
Available with Action: Reindex   Single Type	☑		☑
Available with Action: Reindex   Spell-Check Dictionaries	☑
Behavior: Index Deleted/Created	☑	☑
Behavior: Field Mappings Updated	☑	☑
Behavior: Documents Updated	☑	☑	☑
Recommended After: Liferay   Upgrades	☑	☑
Recommended After:   Elasticsearch Upgrades1	☑	☑	☑
Recommended After: Connection   Outages			☑
Recommended After: Other   Uptime Search Issues		☑	☑

¹ 7.xから8.xへ。 技術的には、 Full reindexが必要なのは、Liferayを新しい空のElasticsearchクラスタに接続するときだけです。 その他のケースでは、Elasticsearch が アップグレードされた場合 （従って、以前の Elasticsearch クラスタのインデックスデータもアップグレードされます）、 Sync reindex で十分です。

 

考察

コンカレント モード より多くの リソース （プライマリディスクスペース）が必要 Elasticsearch. TElasticsearchの空き容量が不足する事態を防ぐため、管理者ユーザはreindexを実行する際に、Elasticsearchで利用可能なディスク容量の見積もりが操作を完了するのに十分でない可能性がある場合、警告確認ダイアログが表示されます。

 インデックスアクションの同時再インデックスモードで警告ダイアログが表示される。

インデックス関連のI/O操作とディスク使用率に関しては、Elasticsearchの内部的な問題であるため、推定はベストエフォート計算に過ぎません。

その他の最新情報

実行モード・セレクタの他に、 インデックス・アクション のレイアウトが、視覚的にしっかりと刷新された：

• 再インデックスを実行する前に確認ダイアログが表示されるようになり、不用意に重作業を引き起こすことを防げるようになった：

インデックス・アクションの確認ダイアログ。

• 関連する個々のタイプはグループ化され、管理者が正しいタイプを以前よりも簡単に見つけられるように、（特にオブジェクト定義の場合）それぞれに（エントリー・クラス名の他に）人間にとって使いやすいローカライズされた名前も表示されます。

インデックス・アクションにおいて、関連する単一タイプや人にやさしい名称をグループ化。

 

index.on.startup が有効になっている場合（推奨されません）、  コントロールパネル - 設定 - システム設定 > 検索でデフォルトの再インデックスモードを設定することが可能です： Reindex Configuration、デフォルトは  Full です。

システム設定のデフォルトの再インデックス実行モード設定。

OSGi コンフィグファイル経由: com.liferay.portal.search.configuration.ReindexConfiguration.config.

プロパティ： defaultReindexExecutionMode="full"

どのようにしてきたか

同時再インデックス・モード（技術的な詳細を含む）

企業 イ ンデ ッ ク ス の標準的な命名規則は、 接頭辞 + companyIdです。 現在の」インデックスはこのような名前になるか、このような名前のエイリアスにリンクされる。

再インデックスが開始されると、「次の」インデックスが作成される。その命名規則は、 prefix + companyId + timestamp （タイムスタンプの形式は、 yyyyMMddHHmmss 、インデックスが作成された時点を表す）。 Company データベース・テーブルには、 indexNameNext というカラムがあり、この値で更新される。

再インデックス操作の間、ドキュメントは「現在」と「次」の両方のインデックスにインデックスされます（再インデックス操作と通常のアセット/コンテンツ更新の両方に対して）。 再インデックス操作中も、検索は「現在の」インデックスに対して実行される。

再インデックスが終了すると、"現在の "インデックスは削除され、"次の "インデックス名にリンクする標準の プレフィックス + companyId 名に対して、新しい エイリアス が作成される。 データベース列 indexNameCurrent が "next "インデックス名で更新され、 indexNameNext 列値がクリアされる。 この処理によって、「次」のインデックスは「現在」のインデックスに移行する。

CompanyConcurrentReindexManager は、次のインデックスの作成と、現在のインデックスを次のインデックスに置き換える処理を行うコンポーネントです。 SearchEngineInitializer は、 CompanyConcurrentReindexManagerを呼び出すクラスです。 これら2つのクラス でログINFOを有効にすると、処理の詳細が表示されます。 処理中にエラーが発生した場合、 CompanyConcurrentReindexManager は「次の」インデックスの削除を試み、「現在の」インデックスは運用を継続する。

シンク再インデックス・モード（技術的な詳細を含む）

Sync reindexの実装のステップ1は、Elasticsearchにインデックスされた全てのドキュメントにタイムスタンプを追加することでした。 タイムスタンプフィールドの値は、ドキュメントが最後に更新/インデックス付けされた時刻を表す。 これは、Elasticsearchの インジェストパイプライン 機能を使って行われました。 パイプラインの作成は、ポータルの起動時に ElasticsearchSearchEngine._putTimestampPipeline()で行われます。

ステップ2は、与えられたインデックス内の「古くなった」文書を削除できるコンポーネントを作成することだった。 このコンポーネントは、 SyncReindexManager。 SyncReindexManagerによって、指定された日付より前のタイムスタンプ (つまり、再インデックスが開始された日付) を含むドキュメント、あるいはタイムスタンプを全く含まないドキュメントを削除することができます。

SyncReindexManager の使用は、企業インデックスの再インデックス時に2つの異なる場所で発生する。

Reindex Search Indexes」実行時 - SearchEngineInitializer

Reindex Single Type」実行時 - ReindexSingleIndexerBackgroundTaskExecutor

SyncReindexManager は、サポート/実装されていれば、アプリケーション・インデックス、すなわち RankingIndexReindexer および SynonymSetIndexReindexerとともに使用することもできる。 これらすべてのクラスでINFOログを有効にすると、プロセスの詳細を知ることができる。

 

 トラブルシューティング/診断ポインタ、ログレベル、クラスなどを追加。 JCordsより LPS-192784：サポートの観点からカバーされると便利なものについてフィードバックを提供する

「最後に、何か問題が起きたときにどうなるかは、どこにも書かれていない。 例えば、コンカレント再インデックスに失敗した場合、システムは元のインデックスを使い続けるだけだと伝えるべきだ。"

 

デモ & その他のリソース

• Concurrent (aka. Blue/Green ) Reindex (技術的な詳細を含む)：

[ビデオはこちら］

• Sync (別名. Soft ) Reindex (技術的な詳細を含む)：

[ビデオはこちら］