検索エンジンの容量不足を「検索式が不正」と扱っていた応答と、検索失敗時の結果を完全な0件に見せていた応答が改善されました。検索APIを利用するアプリケーションでは、HTTPステータスとpartialの両方を確認します。
容量不足は503とRetry-After
OpenSearchがHTTP 429または503で検索を拒否した場合、Fessのv2検索APIはHTTP 503、エラーコード service_unavailable、Retry-After: 5 を返すようになります。5秒は固定値で、新しい設定項目ではありません。
以前は400 invalid_requestとなり、Fessがエスケープした検索式で再試行して、余裕のないエンジンへさらに検索を送っていました。修正後は検索式の問題と切り分け、WARNにエンジンの状態と理由を記録します。呼び出し側はRetry-Afterを尊重し、再試行回数を制限します。
この扱いはエンジンから429/503の応答を受け取る場合です。接続不能などすべての障害が503になるわけではありません。旧v1 APIやWeb画面にも全く同じ応答形式が追加された変更とは扱いません。
200でもpartialを確認する
複数検索器を使うFess側の融合で、主検索器が失敗した場合も partial=true を設定するようになります。検索エンジン停止中に明示的なsortで検索すると、200・0件・partial=falseとなっていた問題を改善します。
record_count_relation=GREATER_THAN_OR_EQUAL_TO は下限を示します。partial=trueやtimed_outを見ずに、200というだけで「該当文書がない」と表示しないようにします。rank.fusion.engine.enabled のFess本体初期値はfalseですが、Dockerデモがtrueを指定する場合もあります。明示sortや高度検索など、エンジン側の融合を使わない条件にも注意します。
不正な num=0 や start=-1 は検索器を実行する前に検証します。これらの400 invalid_requestという応答は従来どおりで、利用者の入力ミスを検索器の障害としてログに積むことを避ける内部改善です。
Dockerのメモリー設定を確認する
docker-filesearchの文書には、parent circuit breakerの容量不足に対する調査手順が追加されました。初期値のヒープは2gのままです。連続検索の高負荷試験では4gで拒否が解消したため、環境のメモリー余力を確認し、必要なら .env に OPENSEARCH_HEAP=4g を設定して docker compose up -d search01 で反映します。
3gでも試験条件によっては拒否が残り、4gでもどんな負荷にも対応できる保証ではありません。OpenSearch再起動後はモデルの再読み込みがあり、最大1分程度キーワード検索だけになることがあります。閾値やクエリーを変える前に、ログ、ヒープ、モデル状態を確認してください。