En tant qu’intern chez Glean l’été dernier, j’ai travaillé sur de nombreux projets à fort impact au sein de notre équipe backend Connectors. Notre équipe s’attache à interroger et indexer efficacement des applications SaaS du quotidien, comme Slack, Jira, Confluence, et ainsi de suite. Ces projets m’ont permis de contribuer à notre infrastructure backend afin d’aider à servir des requêtes pour des applications comme Greenhouse et Salesforce, et de mieux comprendre en détail comment Glean maintient les informations aussi à jour que possible.
Travailler comme ingénieure au sein de l’équipe Connectors a multiplié mes apprentissages en un temps très court, et a vraiment correspondu à ce que j’imaginais comme un stage idéal. Apprendre auprès de collègues si soudés et créer des liens avec eux a rendu ce stage très enrichissant, et m’a aidée à comprendre ce que je considère comme important pour la suite de ma carrière. Cela m’amène à un concept essentiel ici 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 tous ses résultats de recherche. Étant donné que Glean est un puissant outil de recherche, 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 à voir. Le respect du modèle d’autorisations de chaque connecteur est un défi important que nous relevons côté backend, d’autant plus que ces autorisations peuvent changer à tout moment ! Nous intégrons ces autorisations via des crawls périodiques, et en intégrant les utilisateurs dans notre propre schéma d’identité de groupes et d’appartenances. ;
Comme ces applications connecteurs servent de grandes entreprises comptant des centaines de milliers d’utilisateurs, ces crawls peuvent parfois être exceptionnellement longs à terminer, en particulier pour les modèles d’autorisations complexes. L’un de ces projets concernait notre connecteur Salesforce, et son crawl d’identité extrêmement inefficace.
Crawl Salesforce : le problème ;
Lors des crawls d’identité pour les applications connecteurs, de nombreuses étapes interviennent, comme le crawl des utilisateurs, des groupes et des membres, ainsi que l’envoi de requêtes API afin de vérifier les autorisations à chacune de ces étapes. La vitesse du crawl dépend du débit auquel nous pouvons envoyer ces requêtes, et du nombre de requêtes que nous devons effectuer. ;
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 documenté méticuleusement la structure actuelle de notre crawl, j’ai pu élaborer un plan d’optimisation fondé sur les différentes étapes qui nécessitaient, ou non, des appels API. Salesforce, en particulier, dispose 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. Toutefois, tous ces groupes ne nécessitent pas d’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 en parallèle 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 certains autres ! En outre, j’ai mis en place un filtrage basé sur les domaines des utilisateurs afin de m’assurer qu’aucun faux utilisateur ni utilisateur obsolète n’était inclus dans le crawl d’identité. Ce type d’amélioration est essentiel dans un système aussi jeune et en constante évolution que le nôtre.
Travailler sur des problèmes aussi intéressants tout au long de mon stage a rendu cette expérience incomparable. Si construire ou utiliser un produit de recherche de référence vous intéresse, contactez-nous !
Autrice : Shreya Shekhar, stagiaire en ingénierie logicielle
