Mon stage chez Zumper Engineering : Jenny Lu

Note de la rédaction : Cet article a été écrit par Jenny Lu (à gauche), l’une des stagiaires en ingénierie de Zumper pour l’été 2017.

On ne sait jamais vraiment à quoi s'attendre lorsqu'on commence un nouveau stage. On espère secrètement ne pas passer tout l'été à corriger des bugs ou à coder un projet qui ne verra jamais le jour. C'est pourquoi j'étais si ravi de pouvoir travailler sur deux gros projets d'ingénierie et de les mener à bien cet été.

J'étais l'un des deux stagiaires en ingénierie chez Zumper grâce au programme KPCB. J'ai travaillé avec Sehmon, un autre boursier KP. Nous avons mené deux projets principaux : le pipeline de données, un système de suivi d'événements ; et la machine de relecture, un outil utilitaire que nous avons développé durant notre dernier mois (et qui fait l'objet de cet article). La création de la machine de relecture était particulièrement intéressante car deux ingénieurs seniors de Zumper, Dan et Rob, passaient plusieurs heures par semaine avec nous pour travailler sur le projet. C'était vraiment passionnant de voir comment des ingénieurs expérimentés abordaient les problèmes, et nous avons également beaucoup appris sur les défis de conception et les compromis à faire.

L'outil de relecture est une commande permettant de rejouer les requêtes issues d'anciens fichiers journaux. Son objectif principal est de tester les nouvelles versions du site ou les nouveaux serveurs en rejouant les requêtes capturées en production. Ceci garantit la cohérence des nouveaux déploiements du site web avec les versions précédentes, et permet de vérifier que les nouvelles fonctionnalités ou corrections n'ont pas introduit de nouveaux bogues. Le processus comprend trois étapes clés : le téléchargement des fichiers journaux, leur analyse et la relecture des requêtes à l'aide de Scrapy.

Pour télécharger les journaux, nous avons écrit un script qui télécharge les fichiers journaux ELB, stockés dans un compartiment S3 de notre compte AWS de production, entre les dates de début et de fin spécifiées par l'utilisateur.

Nous analysons ensuite les journaux et regroupons les URL, un processus en quatre étapes clés que nous avons intégré dans un script shell. L'idée principale est d'extraire les requêtes de journalisation pertinentes et de générer un ensemble d'URL dédupliquées, tout en conservant la trace de toutes les réponses reçues par une URL donnée en production.

Tout d'abord, nous filtrons les entrées qui ne correspondent pas à l'hôte et à la méthode de requête souhaités (hôte=padmapper.com, méthode=GET). Nous normalisons également l'URL à cette étape, en classant les paramètres de requête par ordre alphabétique tout en préservant l'ordre des paramètres répétés, car des URL avec les mêmes paramètres de requête dans un ordre différent mèneront toujours à la même page. Une entrée de journal contient de nombreux champs, dont beaucoup ne nous sont pas utiles. Nous extrayons ensuite les champs pertinents, qui, dans cette version du projet, sont l'URL et le code d'état. Nous redirigeons la sortie vers les commandes Unix `sort` et `uniq -c`, ce qui nous donne le nombre de fois où l'URL a été rencontrée avec chaque code d'état correspondant. Enfin, nous fusionnons toutes les URL dupliquées et les enregistrons dans un fichier CSV. Par exemple, nous pourrions obtenir un résultat similaire à celui-ci :

1 https://www.padmapper.com 201 1 https://www.padmapper.com 301

Dans cette étape, ils se réduisent à :

https://www.padmapper.com {201:1, 301:1} 

Enfin, nous sommes prêts à relancer les requêtes. Lors de la première itération du projet, nous utilisions la bibliothèque requests de Python pour envoyer les requêtes une par une, ce qui, étant donné qu'une journée de logs peut contenir plus d'un demi-million de requêtes, n'était pas optimal. Nous sommes passés à Scrapy, qui nous permet d'effectuer des requêtes simultanées au serveur. Nous exécutons toutes les requêtes sur notre serveur et générons un rapport comprenant un “ score ”, l'URL, le code d'état reçu, l'agent utilisateur (facultatif) et les codes d'état précédemment rencontrés dans les fichiers de logs. Actuellement, nous calculons un “ score ” pour chaque requête en analysant le code de réponse reçu et en déterminant la proportion de réponses précédemment rencontrées auxquelles il correspond, soit un “ pourcentage de correspondance ”.”

Pour les prochaines itérations, nous générerons vraisemblablement des rapports plus détaillés et ajusterons le système de “ notation ” – notamment, nous souhaiterons probablement identifier le code de réponse reçu avec un enregistrement “ réussi ”, et non pas nécessairement avec l’enregistrement majoritaire (s'il en existe un).

Nous avons réalisé tout cela durant le dernier mois de notre stage, et nous avons même réussi à déployer et tester l'outil en production sur une nouvelle infrastructure avant notre départ ! C'était vraiment génial de voir l'équipe d'ingénierie utiliser concrètement un outil que nous, les stagiaires, avions développé.

Vous vous voyez comme un futur stagiaire chez Zumper (en ingénierie ou autre) ? Envoyez votre CV et votre lettre de motivation à jobs@zumper.com.