Nous avons utilisé solr pour nos cas d'utilisation de recherche/flux/autosuggest/personnalisation e-commerce.

Défis avec le cluster Solr

• La gestion de l'infrastructure solr (zookeeper, JVM, analyse GC, etc.) est un défi. En général, nous avons besoin d'un développeur dédié (SRE/SDE-3) pour cela.
• Mise à niveau vers une version stable plus récente. Moins de soutien communautaire pour les problèmes critiques.

ELK est désormais livré avec une licence premium élastique. Nous avons donc opté pour opensearch car il est open source. Il est basé sur la version 7.10 d'elasticsearch. Il a une licence apache.

Défis majeurs

• Le code existant avait des problèmes de conception. Étroitement couplé avec solr. Architecture de microservice et dépendance de plusieurs services.
• Grande taille de cluster dans certaines régions et lancements par pays.

1. Nous avons utilisé terraform pour la formation de clusters d'opensearch dans toutes les régions.
2. Pour le code, nous avons utilisé le modèle de conception d'usine et le modèle de conception d'adaptateur.
3. Ingestion de données parallèle dans opensearch et solr.
4. Migration des données delta opensearch & solr par notre service de réindexation.
5. Lancement de service un par un avec la prise en charge d'opensearch et de solr
6. Une fois les étapes 1 à 5 terminées. Nous avons prévu un lancement et une surveillance par pays sur newRelic.

Goulot d'étranglement majeur : C'était autour du choix de la machine AWS de type nœud c5. Nous l'avons corrigé par analyse comparative et avons choisi d'utiliser c6g.

Résultat

Nous avons réussi à migrer plus de 100 millions de documents de solr vers opensearch sans temps d'arrêt. La migration a impliqué plus de 100 nœuds sur solr et opensearch. Nous avons également réussi à économiser environ 0,8 million USD.

Référence

1. Modèle de conception d'usine
2. Terraforme
3. Ouvrir la recherche
4. Solr
5. Modèle de conception de l'adaptateur