[検索エンジン] Apache Solr のパフォーマンスの向上

これは、検索および相関スタックで安定性とパフォーマンスの問題をどのように克服したかについての短い物語です。

コンテクスト

過去 10 か月間、パーソナライゼーションおよび関連性チームと協力できて光栄でした。私たちは、ランキングと機械学習に基づいて「パーソナライズされた関連性の高いコンテンツ」をユーザーに配信する責任を負います。これは、ホーム フィード API、検索 API、関連アイテム API という 3 つの共通エンドポイントを提供する一連のマイクロサービスを通じて行われます。チームに参加してから数か月後、次の課題は主要な大国に質の高いサービスを提供できるようにすることであったことを覚えています。目標は、小国ですでに実現している完璧なパフォーマンスと安定性を維持することです。

Zookeeper を使用して Openshift 上の AWS で SolrCloud (v 7.7) を使用します。この記事の執筆時点では、API が最大のリージョンで 1 分あたり約 150,000 のリクエストを処理し、1 時間あたり約 210,000 の更新を Solr に送信していることを誇りに思います。

ベースライン

当社の最大の市場に Solr を導入した後、テストする必要がありました。ストレス テストには内部ツールを使用しており、必要なトラフィックを大まかに取得できます。Solr は適切に構成されていると考えているため、チームはクライアントのパフォーマンスを向上させ、Solr に対してより高いタイムアウトを設定することに取り組んでいます。最終的には、トラフィックをもう少し緩やかに処理できるということで合意しました。

移行後

サービスは許容可能な応答時間で応答し、タイムアウトによりいくつかのサーキット ブレーカーが開始されるまで、Solr クライアントは非常に良好に動作していました。タイムアウトは、Solr レプリカの応答に時間がかかりすぎるという一見ランダムな問題によって生成され、情報が表示されずにフロントエンド クライアントに影響を与えることが多くなります。私たちが遭遇したいくつかの問題を次に示します。

• 高い割合のレプリカがリカバリに入り、リカバリに長い時間がかかります

• レプリカ内のエラーは、リーダーが忙しすぎるため、リーダーに到達できません

• リーダーに過度の負荷 (インデックス、クエリ、レプリカ同期による) がかかり、適切に機能できなくなり、シャードがクラッシュします。

• 「インデックス/更新サービス」については、Solr へのトラフィックを減らすことでレプリカが停止したり、回復モードに移行したりすることが防止されるという疑念があります。

• フルガベージコレクタは頻繁に実行されます (古い世代と若い世代)。

• CPU 上で実行される SearchExecutor スレッドとガベージ コレクター

• キャッシュがウォームアップしているときに SearchExecutor スレッドが例外をスローする (LRUCache.warm)

• 応答時間が約 30 ミリ秒から約 1500 ミリ秒に増加しました

• 一部の Solr EBS ボリュームで 100% IOPS が検出されました

問題を解決する

分析する

分析の一環として、次のテーマを思いつきました。

Lucene 設定

Apache Solr は広く使用されている検索およびランキング エンジンであり、バックグラウンドで Lucene を使用して慎重に設計されています (ElasticSearch とも共有)。Lucene はすべての計算の背後にあるエンジンであり、ランキングとファセットの魔法を実行します。Lucene 上で計算を行って設定を確認することはできますか? 広範なドキュメントとフォーラムの閲覧に基づいておおよその結果を共有できますが、Solr の計算ほど構成は重くありません。
ドキュメントの構造を犠牲にしても構わない場合は、Lucene を微調整することが可能です。本当に努力する価値があるのでしょうか？いいえ、読み進めていくとさらに詳しくわかります。

ドキュメントとディスクのサイズ

約 1,000 万件のドキュメントがあるとします。ドキュメントの平均サイズが 2 kb であると仮定します。初期状態では、ディスク容量は少なくとも次のとおりです。

断片化

コレクションに複数のシャードがあるからといって、必ずしも Solr の復元力が高まるわけではありません。1 つのシャードに問題があり、他のシャードがとにかく応答できる場合、時間応答またはブロッカーが最も遅いシャードになります。

複数のシャードがある場合は、ドキュメントの合計数をシャードの数で割ります。これにより、キャッシュとディスクのサイズが削減され、インデックス作成プロセスが改善されます。

インデックス作成/更新プロセス

過剰なインデックス作成/更新プロセスがある可能性はありますか? 私たちの経験を考慮すると、これは過剰ではありません。この問題の分析は別の記事に譲ることにします。そうしないと、範囲が広すぎます。当社の主要市場では、1 時間あたり 210,000 件の更新 (ピーク時のトラフィック) に達しました。

動物園の飼育員

この環境における Apache Zookeeper の唯一の仕事は、クラスターの状態をすべてのノードで可能な限り正確に維持することです。レプリカの復元が頻繁に行われる場合、よくある問題は、クラスターの状態が Zookeeper と同期しなくなる可能性があることです。これにより、実行中のレプリカ間で不整合な状態が生じ、回復しようとするレプリカが数時間続く長いループに陥る可能性があります。Zookeeper は非常に安定していますが、ネットワーク リソース、またはネットワーク リソースの欠如が原因で失敗する可能性があります。

メモリは十分ですか?

仮説

Solr パフォーマンスの最も重要な要因の 1 つは RAM です。Solr には、Java ヒープ用に十分なメモリと、OS ディスク キャッシュ用の空きメモリが必要です。

32 ビット Java は 2GB ヒープに制限されており、より大きなヒープが存在しない人為的な制限が生じる可能性があるため、Solr を 64 ビット Java で実行することを強くお勧めします (この記事で後ほど説明します)。

Solr がメモリをどのように使用するかを簡単に見てみましょう。まず、Solr はヒープ メモリとダイレクト メモリという 2 種類のメモリを使用します。ダイレクト メモリは、ファイル システムから読み取られたブロックをキャッシュするために使用されます (Linux のファイル システム キャッシュと同様)。Solr は、パフォーマンスを向上させるために、ダイレクト メモリを使用してディスクから読み取られたデータ (主にインデックス) をキャッシュします。

公開されると、ヒープ メモリの大部分が複数のキャッシュによって使用されます。

JVM ヒープ サイズは、バッファリングの目的などで、Solr ヒープ要件の見積もりと一致する必要があります。ヒープと OS のメモリ設定のこの違いにより、バックグラウンド マージや高価なクエリなどの散発的なメモリ使用量の急増に対応するための余裕が環境に与えられ、JVM が効率的に GC を実行できるようになります。たとえば、28Gb RAM コンピュータ上に 18Gb ヒープをセットアップします。

Solr 用に改善してきた方程式を覚えておいてください。メモリのチューニングに最も関連する領域は次のとおりです。

以下の説明は長くて複雑ですが、別の投稿を作成するために、私たちが取り組んでいる数学を共有したいと思いました。問題の最初に独自の計算機を使用したのは、後にオンライン コミュニティで共有された同様の問題を実装するためだけでした。
さらに、Solr の起動時にガベージ コレクターが JVM Args で適切に有効になっていることを確認しました。

証拠をキャッシュする

次のように、Solr 管理パネルの証拠に基づいてキャッシュを調整します。

• queryResultCache のヒット率は 0.01

• filterCache のヒット率は 0.43

• documentCache のヒット率は 0.01

ガベージ コレクターとヒープ

New Relic を使用して、インスタンスのメモリと GC アクティビティをチェックすると、メモリしきい値: 20%、ガベージ コレクション CPU しきい値: 10% により、NR エージェントが頻繁にサーキット ブレーカー (薄赤色の縦線) をオープンしていることがわかります。この動作は、インスタンスで使用可能なメモリに問題があることを示す明らかな証拠です。

また、一部の高 CPU インスタンス プロセスを監視すると、searcherExecutor スレッドが CPU を 100% 使用している一方で、ヒープの約 99% を使用していることもわかります。
JMX と JConsole を使用すると、スタック トレースの一部として ...org.apache.solr.search.LRUCache.warm(LRUCache.java:299) ...を含む例外が発生しました。上記の例外は、キャッシュ設定サイズとウォームアップに関連しています。

ディスクアクティビティ - AWS IOPS

問題を解決し始める

検索結果の耐障害性

フロントエンド クライアントに検索結果を提供するための最初のアイデアは、レプリカが回復中または停止状態にあるためにクラスターが不安定になった場合に備えて、Solr レプリカを常に生きた状態にしてクエリに応答できるようにすることです。Solr 7 では、リーダーとそのレプリカの間でデータを同期する新しい方法が導入されています。

• NRT レプリカ: SolrCloud でレプリケーションを処理する古い方法。

• TLOG レプリカ: トランザクション ログとバイナリ レプリケーションを使用します。

• PULL レプリカ: リーダーからのみ複製し、バイナリ レプリケーションを使用します。

簡単に言うと、NRT レプリカは、インデックス作成、検索、ブートストラップという 3 つの最も重要なタスクを実行できます。一方、TLOG レプリカは、インデックス作成、検索、ブートストラップを少し異なる方法で処理します。差別化要因は、SEARCH によるクエリのみを処理する PULL レプリカです。

この構成を適用すると、シャードにリーダーがある限り PULL レプリカが応答することが保証され、信頼性が大幅に向上します。また、このようなレプリカは、インデックス作成プロセスを処理するレプリカほど頻繁にはリカバリされません。

インデックス サービスが完全にロードされ、TLog レプリカが回復状態になると、依然として問題が発生しています。

Solr メモリのチューニング

「多数のドキュメントを保存するのに十分な RAM はありますか?」という質問に基づいています。、実験してみることにしました。当初の懸念は、ドキュメントの「単位」でこれらの値を次のように構成した理由でした。

前に共有した式に基づくと、ドキュメントが 700 万件あることを考慮すると、推定 RAM は約 3,800 GB になります。ただし、5 つのシャードがあると仮定すると、各シャードはレプリカに直接影響する約 140 万のドキュメントを処理することになります。このシャーディング構成では、必要な RAM は約 3420 GB であると推定できます。これでは根本的な違いは生じないので、次に進みます。

結果をキャッシュする

キャッシュの証拠から、filterCache という 1 つのキャッシュのみが最適に使用されていることがわかります。テストされたソリューションは次のとおりです。

以前のキャッシュ構成では、次の結果が得られました。

• queryResultCache のヒット率は 0.01

• filterCache のヒット率は 0.99

• documentCache のヒット率は 0.02

ガベージコレクターの結果

このセクションでは、New Relic によって提供されるガベージ コレクターのメトリクスを確認できます。通常、New Relic プロキシがサーキット ブレーカーを開く (メモリ枯渇) 原因となる古い世代のアクティビティはありません。

ディスクアクティビティの結果

ディスクアクティビティに関しても素晴らしい結果が得られており、インデックスも大幅に低下しています。

外部サービスの結果

Solr にアクセスするサービスの 1 つでは、New Relic の応答時間とエラー率が大幅に低下しました。

Solr クラスターのチューニング

マルチシャード モデルの欠点は、レプリカが破損した場合、シャード リーダーが応答するまでに他のシャード リーダーよりも時間がかかることです。Solr は最終応答を提供する前にすべてのシャードが応答するのを待つため、その結果、シャード間での応答時間が最悪になります。

上記の問題を軽減するために、また前述の結果を考慮して、ノードとシャードの数を段階的に減らし始めることにしました。これにより、内部レプリケーション係数が低下します。

結論は

数週間にわたる調査、テスト、調整を経て、初期の危険性を排除しただけでなく、レイテンシの短縮によるパフォーマンスの向上、より少ないシャードとレプリカの設定による管理の複雑さの軽減、そしてインデックス作成の信頼性を獲得しました。/更新されたトラスト サービスはフル稼働で動作し、AWS EC2 インスタンスのほぼ半分を使用することで経費の削減に貢献します。

この記事: https://architect.pub/improving-solr-performance
ディスカッション: Knowledge Planet [チーフ アーキテクト サークル] または WeChat トランペット [ca_cto] を追加するか、QQ グループを追加します [792862318]
一般公開なし	【jiagoushipro】 【スーパーアーキテクト】 アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。 お待ちしておりますので、ぜひスキャンしてご注目ください。
WeChatのトランペット	[ca_cea] エンタープライズ アーキテクチャ、クラウド コンピューティング、ビッグ データ、データ サイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論する 50,000 人のコミュニティ。
QQグループ	[285069459] エンタープライズ アーキテクチャ、ビジネス アーキテクチャ、アプリケーション アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティ アーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。
ビデオ番号	【スーパーアーキテクト】 建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。
知識の惑星	[チーフアーキテクトサークル] 著名人に質問したり、連絡を取ったり、プライベートな情報を共有したりしてください。
ヒマラヤ	[スーパーアーキテクト] 最新のブラックテクノロジー情報と建築体験を道路や車の中で学びましょう。	[知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります]
知識の惑星	より多くの友人、職場、技術的なチャットに会いましょう。	ナレッジプラネット【職場とテクノロジー】
リンクトイン	ハリー	https://www.linkedin.com/in/architect-harry/
LinkedInグループ	LinkedIn アーキテクチャ グループ	https://www.linkedin.com/groups/14209750/
微博	【スーパーアーキテクト】	賢い瞬間‍
ビリビリ	【スーパーアーキテクト】
チクタク	【cea_cio】スーパーアーキテクト
早い労働者	【cea_cio_cto】スーパーアーキテクト
小さな赤い本	[cea_csa_cto] スーパーアーキテクト
Webサイト	CIO（最高情報責任者）	https://cio.ceo
Webサイト	CIO、CTO、CDO	https://cioctocdo.com
Webサイト	アーキテクトの実践的な共有	https://architect.pub
Webサイト	プログラマーのクラウド開発共有	https://pgmr.cloud
Webサイト	チーフアーキテクトコミュニティ	https://jiagoushi.pro
Webサイト	アプリケーション開発と開発プラットフォーム	https://apaas.dev
Webサイト	開発情報ネットワーク	https://xinxi.dev
Webサイト	スーパーアーキテクト	https://jiagou.dev
Webサイト	企業向け技術トレーニング	https://peixun.dev
Webサイト	プログラマーの本	https://pgmr.pub
Webサイト	開発者チャット	https://ブログ.開発者.チャット
Webサイト	CPOコレクション	https://cpo.work
Webサイト	最高セキュリティ責任者	https://cso.pub ‍
Webサイト	CIOクール	https://cio.cool
Webサイト	CDO情報	https://cdo.fyi
Webサイト	CXO情報	https://cxo.pub

ご清聴、転送、いいね、ご視聴ありがとうございます。