Retour d'expérience sur la technologie Solr

1. Retours d'expérience
31/05/2016

2. CrossKnowlegde
Qui sommes nous ?
CrossKnowledge est un leader mondial de la formation à distance pour le développement des
compétences en leadership et en management, en s'appuyant sur les nouvelles technologies.
Fondée en 2000, CrossKnowledge est une société internationale avec plus de 350 personnes.
Le département R&D se trouve à Sophia et compte près de 100 personnes.
Nous avons des bureaux en Belgique, Brésil, France, Allemagne, Italie, Pays-Bas, Espagne, Suisse,
Royaume-Uni, États-Unis, et des partenariats stratégiques au Maroc, la Finlande, l'Inde, la Chine, le
Japon, le Canada et beaucoup d'autres.
Depuis le 1er mai 2014, CrossKnowledge fait partie du groupe Wiley.

3. CrossKnowlegde
Notre mission
"We empower the transformation
of individuals, and entire
corporations with learning"

4. CrossKnowlegde
Notre produit
CrossKnowledge fournit une suite elearning en mode ‘Software As A Service’.
Il s'agit d'une application PHP basée sur LAMP permettant d’établir des parcours et des sessions pour
des apprenants, avec mise à disposition de contenus fournis par CrossKnowledge ou par le client.

5. Besoins
Le moteur de recherche inclu dans l'application CKLS s'appuyait, avant 05/2015, sur des requêtes SQL
effectuées directement dans la base de données dédiée au client. Il existait, en option, un moteur de
recherche basé sur un backend Solr standalone.
Pour accompagner notre croissance nous devions satisfaire certains critères :
➢ Respecter un environnement multi langues (19 langues officiellement supportés et en tout une 40aine de
langues ou localisations existantes sur le parc de clients) et une haute disponibilité du service car il
devait être implémenté non plus sous forme d'option mais comme une fonctionnalité du coeur de
l'application.
➢ Le cloisonement entre chaque client devait lui aussi être satisfait. Il existe des restrictions de visibilités
(certains contenus ne doivent pas être vus par certains apprenants (Ex. la stratégie de licenciement de
3000 personnes).
➢ La pertinence des recherches.

6. Choix de la solution
Audit
Nous avons effectué un audit des solutions disponibles sur le marché :
CloudSearch (Amazon): choix orienté SaaS qui a vite été éliminé pour des raisons de
limitations.
Elasticsearch: produit éliminé pour sa jeunesse (v1.0 sortie 2014) et sa communauté peu
développée à cette époque.
SolrCloud: choix final car la solution répondait à nos exigences en terme de HA et profitait par
ailleurs d’une communauté conséquente.

7. Proof Of Concept
Une fois le choix établi, nous avons donc élaboré une plateforme de POC en partant du principe que
notre base client (~500) devait doubler assez rapidement.
Le POC a donc eu lieu sur un maximum de 1200 collections chacune chargée dans un premier temps
à vide et ensuite avec les données de notre plus gros client en terme de contenus.
Nos infrastructures s’appuyant essentiellement sur des fournisseurs d’IaaS, notre choix s’est porté
vers AWS d’Amazon repondant déjà à nos exigences de disponibilité, de certification et de
géolocalisation.

8. Proof Of Concept
Problématiques rencontrées
➢ Obligation de passer par le mode asynchrone pour créer ou effacer des collections en masse (à
cause des timeout ).
➢ Temps de chargement des collections (d'un node) > 20min.
➢ Le reload de collections avec un nombre important de collections n'est pas préconisé car cela est
très gourmand et créé des timeout. Du coup il est impossible de savoir quelles collections ont été
rechargées.
➢ Lors d'un redémarrage des box certains shards restent en état « down » : obligation de faire une
requête WS (REQUESTRECOVERY) sur les shards impliqués. Ceci engendre l'ecriture de scripts.
(problème de cohérence du fichier clusterstate.json)

9. Proof Of Concept
Problématiques rencontrées
➢ Il y a une des situations où Zookeeper a déconnecté des cores. Dans cette situation particulière
ce qui peut se passer est que la taille de l'objet de l'overseer est devenu trop grande et
Zookeeper déconnecte toute connexion tentant de regarder cet objet, dans ce cas là il a fallu:
- se connecter au leader ZK.
- augmenter la taille du buffer (znode = 1M par défaut) de la JMV « -Djute.maxbuffer » pour
pouvoir lire le fichier /overseer/queue et ensuite l'effacer (rmr /overseer/queue).
- redémarrer les solr.

10. Proof Of Concept
Problématiques rencontrées
➢ Fonctionalités internes de type « status » du quorum (ZK) indisponibles à cause du trop grand nombre de collections.
➢ Beaucoup d'opérations manuelles lors de l'ajout d'un node :
- requête WS (addreplica) * le nombre de collections * nombre de shards.
- obligation de scripter l'ajout d'un node.
➢ Crash du quorum lorsque la JVM avoisine 95% d’utilisation.
➢ Problématique sur l'utilisation de dictionnaires, celui-ci n'est pas mutualisé entre les collections, donc chaque
collection charge le/les dictionnaires ce qui abouti à un crash de la JVM. Cependant les dictionnaire sont très difficiles
à obtenir surement très chers et très lourds ( problématique au niveau znode) et non partagés sur le web.
➢ Problématique au niveau des requêtes sur Solr, nous avons été obligé d'augmenter la valeur du paramètre
« maxBooleanClauses » (maximum number of clauses in a boolean query).

11. Architecture
Architecture finale de production :
1 x Elastic Load balancer qui porte le certificat et assure l’équilibrage de
charge.
3 x t2.medium (2 x vCPU + 4G RAM) assurant les fonctions Zookeeper.
3 x m4.4xlarge (16 x vCPU + 64G RAM) assurant les fonctions Solr (JVM 32G).
614 collections, entre 200 et 300 r/s en moyenne.

12. Solr cloud architecture
SOLR 2SOLR 1
Zone 1 Zone 2 Zone 3
SOLR 3
http http
ZK1 ZK2 ZK3
Quorum
zookeeper
Load Balancerinternet
http http
https
Clients requests
http http

13. Tests de charge

14. Tests de stabilité

15. Tests d'indexation

16. Conclusion
Malgré les problématiques rencontrées tout au long du POC, la solution SolrCloud répond à nos besoins :
➢ Séparation des données
➢ Performances (beaucoup de clients)
➢ Haute disponibilité

17. Merci !
On recrute :)
Contacts
olivier.damiot@crossknowledge.com
stephane.malinet@crossknowledge.com
yannick.milanetto@crossknowledge.com
Job offers
https://careers.smartrecruiters.com/CrossKnowledge

18. C’est l’heure du Quiz !
Combien de collections avons-nous
sur le Solr Cloud en production ?
A) 1200
B) 614
C) 514
D) 9999
Répondez vite en tweetant sur @TechConfQuiz