En tant que stagiaire chez Glean l'été dernier, j'ai travaillé sur de nombreux projets à fort impact au sein de notre équipe backend Connecteurs. Notre équipe s'emploie à interroger et à indexer efficacement les applications SaaS du quotidien, telles que Slack, Jira, Confluence, et bien d'autres. Ces projets m'ont permis de contribuer à notre infrastructure backend afin de traiter les requêtes pour des applications comme Greenhouse et Salesforce, et de comprendre en détail comment Glean maintient les informations aussi à jour que possible.
Travailler en tant qu'ingénieure au sein de l'équipe Connecteurs a décuplé mes apprentissages en si peu de temps, et correspondait parfaitement à l'idée que je me faisais d'un stage idéal. Apprendre auprès de collègues aussi soudés et créer des liens avec eux a rendu ce stage enrichissant, et m'a aidée à comprendre ce qui compte vraiment pour la suite de ma carrière. Cela m'amène à un concept essentiel chez Glean : l'identité.
L'identité est le concept central qui détermine ce qu'un utilisateur voit chaque jour sur sa page d'accueil Glean, ainsi que dans l'ensemble de ses résultats de recherche. Compte tenu de la puissance de l'outil de recherche qu'est Glean, il est impératif que les utilisateurs puissent voir les résultats les plus pertinents pour leur travail, et uniquement ceux qu'ils sont autorisés à consulter. Respecter le modèle d'autorisations de chaque connecteur est un défi majeur que nous relevons côté backend, d'autant plus que ces autorisations peuvent être modifiées à tout moment ! Nous intégrons ces autorisations grâce à des crawls périodiques, et en intégrant les utilisateurs dans notre propre schéma d'identité de groupes et d'appartenances.
Étant donné que ces applications de connecteurs servent de grandes entreprises comptant des centaines de milliers d'utilisateurs, ces crawls peuvent parfois prendre un temps exceptionnellement long, en particulier pour les modèles d'autorisations complexes. L'un de ces projets concernait notre connecteur Salesforce et son crawl d'identité incroyablement inefficace.
Le crawl Salesforce : le problème
Lorsqu'on effectue des crawls d'identité pour des applications de connecteurs, de nombreuses étapes sont impliquées, telles que le crawl des utilisateurs, des groupes et des membres, et l'exécution de requêtes API afin de vérifier les autorisations à chacune de ces étapes. La vitesse du crawl est déterminée par le rythme auquel nous pouvons effectuer ces requêtes, et par leur nombre.
Dans le cas de Salesforce, le crawl était limité par ces deux facteurs, et mon travail consistait à étudier comment l'optimiser.
Notre solution
Après avoir méticuleusement documenté notre structure de crawl actuelle, j'ai pu élaborer un plan d'optimisation fondé sur les différentes étapes nécessitant ou non des appels API. Salesforce dispose en particulier d'un grand nombre de groupes d'autorisations différents, basés sur les documents, les types de documents, les profils, les réseaux, les rôles, et bien plus encore. Tous ces groupes ne nécessitent toutefois pas le recours à des appels API pour être créés, car certains sont des groupes internes que nous utilisons pour filtrer les résultats destinés aux utilisateurs de Glean.
En exécutant simultanément les tâches qui n'en nécessitaient pas, et à un rythme plus rapide que les tâches liées aux API, j'ai pu obtenir jusqu'à 98 % d'amélioration du temps de crawl d'identité pour l'un de nos clients, et au moins 22 % d'amélioration pour d'autres ! J'ai par ailleurs mis en place un filtrage basé sur les domaines des utilisateurs afin de m'assurer qu'aucun utilisateur fictif ou obsolète n'était inclus dans le crawl d'identité. Ce type d'améliorations est crucial dans un système jeune et en constante évolution comme le nôtre.
Travailler sur des problématiques aussi intéressantes tout au long de mon stage a rendu l'expérience incomparable. Si concevoir ou utiliser un produit de recherche de premier plan vous intéresse, contactez-nous !
Autrice : Shreya Shekhar, stagiaire en ingénierie logicielle
