Pinterest abandonne son zoo de profileurs au profit du gProfiler open source d'Intel

Quand vous avez cinq services dans un seul langage, le profilage se règle d'une seule commande. Quand vous avez des centaines de milliers d'instances et cinq langages, le profilage devient un véritable chantier d'ingénierie. C'est précisément ce à quoi Pinterest a été confronté, et la solution est intéressante : plutôt qu'un système interne fermé, l'entreprise a pris le gProfiler open source d'Intel et a commencé à l'améliorer.

Le problème : beaucoup de langages, beaucoup d'outils

Voici l'échelle : 640 millions d'utilisateurs actifs par mois, des centaines de milliers d'instances de calcul. Les services sont écrits en Java, Python, C++, Go et Node.js. Pour chaque langage, les ingénieurs avaient leur outil habituel : perf pour le code natif, async-profiler pour la JVM, py-spy pour Python.

Pris isolément, chacun d'eux est excellent. Ensemble, ils donnent un joyeux désordre. Les formats de données diffèrent, les méthodes de lancement aussi, et reconstituer à la main la chaîne « passerelle Node.js, backend Java, bibliothèque C++ » est fastidieux. Comparer le profil d'un même service sur différentes machines ou à différents jours n'est pas simple non plus si les captures proviennent d'outils différents.

Pour une équipe d'infrastructure, ce n'est pas un problème académique. Le profil sert à comprendre où part l'argent dépensé en matériel et à détecter une régression après une release. Si les données sont éparpillées, on répond à ces questions lentement et sans certitude.

Ce qui a été fait avec gProfiler

gProfiler est un profileur open source à fonctionnement continu. Il est lancé par un agent sur la machine et collecte des profils pour plusieurs langages à la fois, puis présente le résultat sous forme de flame graphs. Pinterest, avec Intel, a étendu ses capacités et reversé les correctifs au projet open source. Parmi les améliorations :

• Profilage dynamique. Le profilage peut être activé et configuré en cours d'exécution, au lieu de rester actif en permanence sur toutes les machines.
• Collecte de télémétrie au niveau matériel. Le profileur voit non seulement où le code passe son temps, mais aussi les données des compteurs du processeur.
• Profilage en wall-time. Il montre où un thread attend physiquement, et pas seulement où il sollicite le processeur.
• Flame graphs fondés sur les compteurs de performance. Au lieu de l'axe habituel « temps CPU », on peut construire des graphes selon les événements matériels.

La différence entre CPU-time et wall-time se comprend le mieux avec un exemple. Supposons qu'un endpoint réponde en 300 ms, mais que le profil CPU montre que le processeur ne travaille que 40 ms. Où sont passées les 260 ms restantes ? Très probablement, le thread attend la réponse d'une base de données, du réseau ou d'un verrou. Le profil CPU ne montrera pas du tout cette partie, alors que le wall-time la révélera immédiatement.

Quant aux compteurs de performance, ils permettent d'aller plus loin. Deux fonctions peuvent prendre le même temps, mais l'une d'elles rate constamment le cache du processeur. Un profil classique ne les distinguera pas, un profil basé sur les événements matériels si.

Ce qui compte ici, et ce que nous ignorons

Le message d'origine ne contient aucun chiffre : combien de ressources de calcul ont été économisées, à quel point les régressions sont détectées plus vite, combien d'instances ont déjà été migrées. Il est donc trop tôt pour parler d'effet mesurable. C'est davantage l'annonce d'un choix d'architecture qu'un rapport de résultats.

Ce choix reste néanmoins révélateur. Une entreprise de cette taille aurait pu construire sa propre plateforme, mais elle a préféré un projet ouvert et y a reversé ses améliorations. C'est un plus pour les autres : les améliorations du profilage dynamique et en wall-time seront accessibles à tous ceux qui utilisent gProfiler.

Que faire en pratique

1. Comptez votre zoo. Si vous avez plus de deux langages en production et plus de deux profileurs différents, vous avez le même problème, en plus petit.
2. Essayez gProfiler dans un environnement de test. C'est un projet ouvert, conçu justement pour le profilage continu sans modifier le code des services.
3. Prenez l'habitude du wall-time. Si un service « ralentit mais que le CPU est libre », c'est exactement ce qu'il vous faut.
4. Suivez l'amont. Les améliorations de Pinterest et d'Intel doivent arriver dans le dépôt principal, et il vaut la peine de vérifier ce qui est déjà disponible dans les releases.

La conclusion principale est simple : à grande échelle, un profileur unique compte plus qu'un outil idéal pour chaque langage. Des données comparables sur l'ensemble du parc de machines apportent plus que la meilleure précision sur un seul service.