Chez Glean, nous avons l’ambition de proposer un produit de recherche de tout premier plan.
Dans un article précédent, nous expliquions comment nous déployons rapidement du nouveau code de ranking. Dans cet article, nous allons nous concentrer sur la manière dont nous testons et déployons le cluster du moteur de recherche.
Même si cette discussion peut être technique, nous veillons à toujours garder en tête notre objectif principal : améliorer l’expérience client. Cela signifie que tous nos travaux d’ingénierie — y compris dans les couches d’infrastructure — doivent se traduire par des mises à jour de fonctionnalités et des performances plus rapides, moins de bugs et d’interruptions, et un renforcement global de la confiance en nous imposant systématiquement des standards plus élevés.
Simulation et tests rapides et fiables
Chez Glean, nous testons intensivement toutes les couches de notre stack de recherche. Chaque qualification de release passe par une batterie de tests de recherche de bout en bout sur des déploiements en charge. En complément, nous avons identifié la nécessité de permettre à tous nos ingénieurs search de simuler la stack de recherche complète en quelques secondes. Chaque jour, nous cherchons à apporter de nouvelles améliorations tout en protégeant rigoureusement la qualité et la robustesse du moteur de recherche.
Dans cette optique, nous avons investi massivement pour pouvoir initialiser rapidement, dans nos tests unitaires, un moteur de recherche multi-nœuds en mémoire. Ce framework nous permet de valider très vite toute modification apportée à notre stack de recherche. Cela peut inclure des évolutions de nos schémas d’index, de la logique de retrieval et de scoring, de la tokenization du texte, et bien plus encore.
Même si, à chaque release, nous exécutons une batterie de tests de bout en bout sur des déploiements en charge, nous avons privilégié cette voie rapide et légère, car :
- Plus les ingénieurs peuvent détecter tôt un bug dans leur environnement local, moins nous aurons de fuites. Nous connaissons tous la pénibilité de devoir isoler un bug sur une configuration en charge.
- Plus les ingénieurs peuvent vérifier rapidement un correctif, plus vite nous pouvons aider les clients à revenir sur de bons rails.
- Plus nous sommes en mesure de simuler la logique de recherche de bout en bout dans notre processus de build habituel, plus nous comprenons réellement notre produit, au lieu de simplement faire des hypothèses sur la façon dont les choses devraient fonctionner.
Nous avons été agréablement surpris par tout ce que nos simulations de bout en bout permettent de détecter. En travaillant à l’optimisation de notre parcours de tokenization du texte, nous avons découvert que même de simples tests de requêtes exécutés sur le cluster embarqué arrivaient à mettre en évidence des problèmes que les tests unitaires de tokenization eux-mêmes n’avaient pas détectés. Nous adorons quand les fuites sont repérées avant même de fusionner le bug dans la codebase !
Des opérations de déploiement rapides et sûres
Nous cherchons à livrer rapidement et de manière fiable des milliers de moteurs de recherche. C’est une déclaration très générale, et en pratique cela signifie que, chaque jour, nous devons évaluer et améliorer nos processus d’exploitation et de maintenance de tous ces moteurs. C’est un chantier permanent, qui continue de porter ses fruits à mesure que nous élargissons notre base clients.
Récemment, nous avons investi dans une refonte de toutes nos opérations de déploiement. Nous avons passé en revue chaque opération et nous nous sommes demandé comment rendre chaque étape plus rapide, plus sûre et plus facilement testable.
- Nous avons refondu nos opérations de setup et de teardown afin de reconstruire les moteurs de recherche plus rapidement et plus sûrement sur l’ensemble de notre base clients. ; Cela nous permet de déplacer facilement les clients vers de nouveaux clusters qui intègrent de nouvelles fonctionnalités de recherche et d’importantes améliorations de performance.
- Nous avons ajouté une batterie de tests unitaires pour chaque opération de déploiement. Découvrir un bug en l’exécutant chez un client n’est pas une situation dans laquelle nous voulons nous retrouver.
- Nous avons mis en place des procédures de vérification importantes pour des étapes sensibles telles que le basculement de cluster (passage d’un ancien moteur de recherche à un nouveau). Nous exécutons des requêtes de test sur tout nouveau moteur de recherche avant de procéder au basculement. Nous appliquons la même procédure de vérification sur le moteur de recherche actif avant de supprimer l’ancien moteur, au cas où nous aurions besoin de rollback.
- Nous avons implémenté une opération de rollback rapide au cas où nous découvririons des problèmes sur le nouveau moteur de recherche. ; Même si nous n’avons jamais eu à l’utiliser sur un déploiement client, nous l’avons mise en place parce que nous préférons prévenir que guérir.
Grâce à ces efforts, nous passons désormais beaucoup moins de temps à monitorer et à « babysitter » des routines de maintenance auparavant laborieuses. Nous détectons également les bugs plus tôt, ce qui contribue à réduire les incidents d’astreinte.
Et pour la suite
Même si ces investissements ont apporté des améliorations significatives et nous ont donné une certaine tranquillité d’esprit, nous réévaluons et itérons en permanence. Dans de futurs articles, nous partagerons plus d’informations sur les autres investissements que nous réalisons pour offrir la meilleure recherche possible. Nous apprenons chaque jour et nous sommes enthousiastes à l’idée de construire un produit qui définira les standards du secteur.
Si construire ou utiliser un produit de recherche de tout premier plan vous intéresse, contactez-nous ! Nous serions ravis d’échanger avec vous.
