Chez Glean, nous poursuivons un objectif ambitieux : proposer un produit de recherche de premier plan.
Dans un article précédent, nous avons expliqué comment nous déployons rapidement un nouveau code de classement. Dans cet article, nous nous concentrons sur la manière dont nous testons et déployons le cluster du moteur de recherche.
Bien que cette discussion soit de nature technique, nous nous efforçons de toujours garder le cap sur notre objectif principal : améliorer l'expérience client. Cela signifie que tout le travail d'ingénierie que nous réalisons, même au niveau des couches d'infrastructure, doit 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.
Une simulation et des tests rapides et fiables
Chez Glean, nous testons intensivement toutes les couches de notre stack de recherche. Chaque qualification de version passe par une batterie de tests de recherche de bout en bout sur des déploiements entièrement chargés. En plus de cela, nous avons compris la nécessité de permettre à tous nos ingénieurs de recherche de simuler l'intégralité de la stack de recherche en quelques secondes. Chaque jour, nous visons à apporter de nouvelles améliorations tout en veillant scrupuleusement sur la qualité et la robustesse du moteur de recherche.
À cette fin, nous avons beaucoup investi dans la capacité à initialiser rapidement un moteur de recherche multi-nœuds en mémoire au sein de nos tests unitaires. Ce framework nous permet de vérifier très rapidement toute modification apportée à notre stack de recherche. Cela peut inclure des mises à jour de nos schémas d'index, de notre logique de récupération et de scoring, de la tokenisation du texte, et bien plus encore.
Même si, pour chaque version, nous passons par une batterie de tests de bout en bout sur des déploiements entièrement chargés, nous avons privilégié cette approche rapide et légère pour les raisons suivantes :
- Plus tôt les ingénieurs peuvent détecter un bug dans leur environnement local, moins nous aurons de fuites. Nous connaissons tous l'expérience fastidieuse qui consiste à isoler un bug sur un environnement entièrement chargé.
- Plus rapidement les ingénieurs peuvent vérifier un correctif, plus vite nous pouvons aider les clients à reprendre leur activité.
- Plus nous sommes capables de simuler la logique de recherche de bout en bout dans le cadre de notre processus de build habituel, plus nous comprenons réellement notre produit en profondeur, au lieu de nous contenter de faire des hypothèses sur la façon dont les choses devraient fonctionner.
Nous avons été agréablement surpris de constater tout ce que nos simulations de bout en bout permettent de détecter. En travaillant sur l'optimisation de notre chaîne de tokenisation du texte, nous avons découvert que même de simples tests de requêtes de recherche exécutés sur le cluster embarqué permettaient de repérer des problèmes qui n'étaient pas détectés par les tests unitaires de tokenisation eux-mêmes. Nous adorons quand les fuites sont détectées avant même que le bug ne soit fusionné dans le code source !
Des opérations de déploiement rapides et sûres
Nous visons à déployer rapidement et de manière fiable des milliers de moteurs de recherche. C'est une affirmation très générale et, en pratique, cela signifie que nous devons chaque jour évaluer et améliorer nos processus d'exploitation et de maintenance de tous ces moteurs de recherche. Il s'agit d'un travail en constante évolution qui continue de porter ses fruits à mesure que nous élargissons notre base de clients.
Récemment, nous avons investi dans une refonte de l'ensemble de nos opérations de déploiement. Nous avons examiné chaque opération et nous nous sommes demandé comment rendre chaque étape plus rapide, plus sûre et plus facilement testable.
- Nous avons repensé nos opérations de mise en place et de démantèlement afin de reconstruire plus rapidement et plus sûrement les moteurs de recherche de l'ensemble de notre base de clients. Cela nous permet de migrer facilement les clients vers de nouveaux clusters dotés de nouvelles fonctionnalités de recherche et d'importantes améliorations de performances.
- Nous avons ajouté une batterie de tests unitaires pour chaque opération de déploiement. Détecter un bug en production chez un client n'est pas une situation dans laquelle nous souhaitons nous retrouver.
- Nous avons ajouté d'importantes procédures de vérification pour les étapes sensibles telles que le basculement de cluster (passage d'un ancien à un nouveau moteur de recherche). Nous exécutons des requêtes de test sur tout nouveau moteur de recherche avant de procéder au basculement. Nous exécutons cette même procédure de vérification sur le moteur de recherche actif avant de supprimer l'ancien moteur de recherche, au cas où nous aurions besoin de revenir en arrière.
- Nous avons mis en place une opération de retour arrière rapide au cas où nous détecterions des problèmes dans le nouveau moteur de recherche. Même si nous n'avons jamais eu à l'utiliser sur un déploiement client, nous l'avons prévue car mieux vaut prévenir que guérir.
Grâce à ces efforts, nous passons désormais beaucoup moins de temps à surveiller et à superviser des routines de maintenance autrefois fastidieuses. Nous détectons également les bugs plus tôt, ce qui contribue à réduire les incidents nécessitant une intervention d'astreinte.
La suite
Si ces investissements ont apporté de réelles améliorations et nous ont procuré une certaine tranquillité d'esprit, nous ne cessons de les réexaminer et de les faire évoluer. Dans de prochains articles, nous partagerons davantage d'informations sur les autres investissements que nous réalisons pour offrir la meilleure recherche possible. Nous apprenons chaque jour et sommes enthousiastes à l'idée de créer un produit qui redéfinira le secteur.
Si créer ou utiliser un produit de recherche de premier plan vous intéresse, n'hésitez pas à nous contacter ! Nous serions ravis d'échanger avec vous.
