e コマースの検索/フィード/自動提案/パーソナライズのユースケースに solr を使用しました。

solr クラスターの課題

• solr インフラストラクチャ (zookeeper、JVM、GC 分析など) の管理は課題です。通常、専用の開発者 (SRE/SDE-3) が必要です。
• 新しい安定版へのアップグレード。重大な問題に対するコミュニティ サポートの減少。

ELK にはエラスティック プレミアム ライセンスが付属しています。そこで、オープンソースであるオープンサーチを選択しました。これは、elasticsearch 7.10 バージョンに基づいています。apache ライセンスを持っています。

主な課題

• 既存のコードには設計上の問題がありました。solrと密結合。マイクロサービス アーキテクチャと複数のサービス依存関係。
• 一部の地域および国ごとのローンチでの大きなクラスターサイズ。

1. すべてのリージョンでオープンサーチのクラスター形成に terraform を使用しました。
2. コードには、ファクトリー デザイン パターンとアダプター デザイン パターンを使用しました。
3. opensearch と solr の両方での並列データ取り込み。
4. 当社の再インデックスサービスによる差分データ opensearch & solr の移行。
5. opensearch と solr の両方をサポートするサービスを順次開始
6. 手順 1 ～ 5 の準備ができたら。私たちは、newRelic で国ごとのローンチとモニタリングを計画しました。

主なボトルネック: ノード タイプ c5 AWS マシンの選択にありました。ベンチマークによって修正し、c6g を使用することにしました。

結果

ダウンタイムなしで、1 億を超えるドキュメントを solr から opensearch に移行することに成功しました。移行には、solr と opensearch の 100 以上のノードが含まれていました。また、約 80 万米ドルを節約することもできました。

参照

1. 工場設計パターン
2. テラフォーム
3. オープンサーチ
4. ソル
5. アダプタ設計パターン