docker-fessのOpenSearch 3.9.0向けCompose定義に、検索処理の低レベルキャンセルを無効にする設定が追加されました。検索中のキャンセル確認に伴う性能低下を避けるための暫定的な対策です。
docker-fess #91を紹介します。Fessの最新リリースとして確認したのは15.8.0で、15.9のリリースを意味するものではありません。以下は変更を含むCompose定義と対応するOpenSearch環境を利用する場合の説明です。
変更された設定
OpenSearchノードのenvironmentに、次の項目が追加されています。
environment:
- "search.low_level_cancellation=false"OpenSearch側の初期値はtrueです。今回のCompose定義ではfalseへ変更します。標準のcompose-opensearch3.yaml、vanilla版、multi-instance版、snapshotの5ノード構成が対象です。変更済み定義を使えば項目は含まれています。独自にComposeファイルを管理している場合は、利用する各OpenSearchノードの設定を確認してください。
環境変数として指定する場合、Compose定義を編集しただけでは稼働中のコンテナへ反映されません。通常のCompose更新手順で対象コンテナを再作成して反映します。反映後はOpenSearchのノード設定APIで、各ノードのsearch.low_level_cancellationがfalseになっていることを確認できます。
どのような遅延への対策か
OpenSearch 3.7〜3.9では、Luceneの検索処理を包むキャンセル確認の実装が、一括処理の高速経路や処理オブジェクトの再利用を妨げることが指摘されています。高頻度語のAND・OR件数集計、前方一致、ワイルドカードなど、一致候補を広く走査する検索が影響を受ける場合があります。
背景と修正内容はOpenSearchのIssue #23107とPR #23117で説明されています。利用者の検索条件やデータ量によって影響は異なるため、この設定による高速化の倍率を一律に保証するものではありません。docker-fessのPRで確認されているのは設定の反映であり、Fess環境での性能測定は行われていません。
キャンセルの応答性との引き換え
falseにすると、Lucene内部を走査している最中のキャンセル確認が行われなくなります。キャンセルやタイムアウトした検索は、次の処理フェーズの境界で停止するため、停止までに時間がかかる場合があります。
検索のキャンセルを全面的になくす設定ではありませんが、重い検索をすぐ止めたい運用ではこの違いを考慮してください。検索時間だけでなく、タイムアウト後の処理継続時間や負荷も検証する必要があります。
今回の対策は、修正を含まないOpenSearch 3.9.0に対する回避策です。Composeのコメントでも、上流の修正を含むリリースがイメージへ取り込まれた後に設定を外すよう記載されています。OpenSearchを更新するときは修正の収録状況を確認し、初期値trueへ戻すか再評価してください。