Chez Glean, nous traitons de l'ordre de plusieurs centaines de millions de documents chaque jour. Dans un précédent article de blog, nous avons décrit comment nous utilisons Apache Beam Streaming pour lire efficacement un corpus aussi volumineux depuis MySQL. Alors que nous nous concentrions là sur les détails du pipeline de streaming, cet article entrera dans les détails de nos requêtes MySQL et du monitoring mis en place pour identifier, déboguer et corriger les inefficacités du système. Nous reviendrons également sur un exemple montrant comment nous avons débogué un pipeline dont le débit était faible en raison de lectures lentes depuis MySQL.
Une marge de progression
Sur l'un de nos déploiements les plus importants, nous avons constaté qu'il nous fallait environ 3 jours pour traiter l'intégralité du corpus. Bien que la configuration de streaming décrite précédemment offre une scalabilité horizontale massive, nous avons remarqué que l'utilisation du CPU n'atteignait pas 100 % sur ce déploiement. C'était le premier indice qu'une inefficacité du système pouvait être optimisée sans augmenter les ressources de calcul.
Sur les déploiements multicœurs comme celui-ci, nous émettons plusieurs requêtes de lecture MySQL en parallèle, chacune récupérant un lot de k documents afin d'augmenter le débit. Tous ces documents sont conservés dans un tampon en mémoire d'où ils sont extraits pour traitement. Lorsque le nombre de documents dans ce tampon en mémoire est faible, un nouvel ensemble de requêtes MySQL parallèles est émis pour récupérer davantage de documents.
Sur ce déploiement en particulier, le tampon en mémoire était assez souvent signalé comme vide. Cela signifiait que notre pipeline traitait les documents plus vite qu'ils n'étaient récupérés. C'était le deuxième indice, qui nous a permis de circonscrire l'inefficacité au temps pris par les lectures MySQL.
Supposons que nous ayons n cœurs dans un déploiement ; la requête MySQL pour récupérer un lot de k documents ressemblait à ceci :
Nous avons commencé à surveiller les latences de lecture de cette requête et avons remarqué que plus l'offset (n*k) était grand, plus la requête était lente. C'était le troisième et dernier indice. Alors que le même modèle de requête MySQL était utilisé sur tous nos déploiements, ce qui était propre à ce déploiement était la valeur bien plus élevée de n. En examinant la manière dont MySQL gérait cette requête, nous avons réalisé qu'avec des offsets plus grands, il récupérait un total de (n+1)*k documents avant d'écarter les n*k premiers, ce qui contribuait donc à l'augmentation des temps de requête. Pour forcer MySQL à effectuer des late row lookups et ainsi ne récupérer que les k documents nécessaires, la requête MySQL a été modifiée comme suit :
Bug corrigé, débit triplé
Cela a réduit les latences MySQL sur une requête de test avec k = 1, n*k = 1150 d'environ 4 secondes à environ 0,1 seconde, et a entraîné un triplement du débit du pipeline (voir la figure 1). Ce débit accru se traduit par une fraîcheur améliorée du contenu, des permissions et des statistiques, améliorant ainsi notre ranking pour offrir une meilleure expérience de recherche.
Nous espérons que cet article de blog donne un aperçu non seulement du type de défis techniques que nous rencontrons, mais aussi du monitoring mis en place pour les détecter et du processus suivi pour les déboguer. Si cela vous intéresse de travailler sur des problèmes similaires, consultez notre page Carrières !
