まず問題になっていたのが、
Solrの select クエリの実行時間が、時間帯によって極端にばらつく点です。
同じ検索処理を繰り返し実行しているにもかかわらず、

というように、明らかな差が発生していました。

調査を進めたところ、
この「遅い時間帯」は、データソース側のSolrに大量データを投入している時間帯と
ちょうど重なっていることが分かりました。

つまりこの時間帯は、

という状態になっていたのです。

もうひとつの大きなボトルネックが、
Solrへの commit 処理に異常な時間がかかっている点でした。

さらに、データソース側のデータ量が多い場合には、
ネットワーク負荷が高まりやすいという問題も見えてきました。

その結果、

といった事象も確認されました。

これらの結果から、単純に「アプリ側の処理が遅い」のではなく、
Solrへの読み書きが集中するタイミングそのものがボトルネックになっている
ということが、はっきりと分かってきました。

ここでは、特定されたボトルネックに対して、どのような対策を講じたかを具体的に記述します。

🛠️ Solrのselectが遅くなる時間帯への対策

データソース側の調査を進める中で、Solr の select クエリが遅くなる原因は、クエリの書き方と Solr の使い方の両面にあることが分かりました。

ここでは、実際に効果があった 2 つの対策を紹介します。

2つ目の対策が、今回もっとも効果が大きかった対応です。

Solr では、
commit が実行されるたびに Searcher の再オープン が発生します。
そのため、

が同時に走ると、select クエリのレスポンスが極端に悪化することがあります。

今回の構成では、

を 同じ Solr サーバーで行っていました。 これが、高負荷時間帯に select が遅くなる
大きな要因になっていたと考えられます。

そこで、Solr の レプリケーション機能を利用し、

という役割分担を行いました。

これにより、

特にこの対応は、処理時間の改善幅が最も大きかった対策でもあり、
Solr の読み書きが混在する構成では、非常に有効なアプローチだと感じています。

commitWithin は、「◯秒以内に commit してほしい」という条件を Solr に伝え、
commit のタイミングを Solr 側に委ねるためのオプションです。

通常の commit では、

という挙動になります。

一方、commitWithin を使うと、

ため、アプリケーション側の待ち時間を大きく減らすことができます。

大量データを投入するバッチ処理では、この差がそのまま全体の処理時間に影響してきます。

次に行ったのが、Atomic Update の導入です。

Solr では、プライマリキー（通常は id フィールド）が同じドキュメントを送信すると、自動的に既存データが上書きされる仕組みになっています。

これまでの実装では、この「全体上書き」を使っていましたが、一部の項目だけを更新したいケースも多く存在していました。

そこで、
「変更が必要なフィールドだけを更新する」
Atomic Update を一部の処理で採用しました。

この対応により、

といった効果が得られ、結果として commit 周りの処理が安定・高速化しました。

ただし、Atomic Update は 常に最速というわけではありません。

一般的には、

という関係になります。

Atomic Update では、内部的に以下の処理が行われます。

一方、全体上書きの場合は、この Read の工程が不要なため、
処理そのものは上書きの方が高速になります。

そのため、

といったケースでは、ネットワーク・メモリ状況を考慮したうえで Atomic Update を選択するのが有効です。