Focus sur la Data sur GCP chez Early Birds avec Jonathan Norblin

Google Cloud Platform (GCP) et la Data dans le Cloud sont des axes clés pour cette année 2018 chez Xebia.

Cela tombe bien, Jonathan Norblin intervient chez Early Birds, et pas sur n’importe quoi : un super combo des deux, de la data sur GCP s’il vous plaît !

Pour contextualiser, découvrez l’interview de Samuel Clara, Product Manager Chez Early Birds.

Maintenant, c’est à Jonathan Norblin de nous expliquer sa mission. Nous vous proposons donc un format « interview » inédit sur ce blog.

Au programme : Scala, Google Cloud Platform, Data, Craft et DevOps !

Jonathan, peux-tu nous présenter Early Birds ?

Early Birds propose une plateforme de personnalisation et de recommandation « as a service », qui permet à des entreprises de suggérer à leurs clients des produits ou contenus qui leur correspondent. Leurs clients sont des entreprises telles que la Fnac, Darty, Lacoste, La Redoute, etc. Early Birds propose différents types de personnalisation : recommandation de produits les plus populaires, produits similaires, mais avant tout de la recommandation personnalisée liée aux activités d’un client.

Et que fais-tu chez eux ?

J’interviens chez eux depuis le 22 janvier, notamment sur la partie data engineering, mais aussi sur des sujets craft et architecture sur GCP. Chez Early Birds, la partie technique est décomposée en 2 équipes principales :

• la team Data, dans laquelle je suis, qui réalise toute la partie recommandation en elle-même : création de modèles de machine learning et exposition d’une API proposant des recommandations temps-réel, basées sur ces modèles précalculés
• la team API, qui s’occupe des APIs plus généralistes : notamment celle exposée au public, en NodeJS, qui va appeler la partie « serving » gérée par la team Data. Cette équipe s’occupe aussi des imports des référentiels produits, et de la partie console qui va permettre aux clients de personnaliser leurs recommandations en fonction de règles de merchandising qu’ils définissent

Concrètement, comment se passe la partie Data et quels services de GCP utilisez vous ?

Sur l’aspect data science, un gros travail de création et d’entraînement de modèles de machine learning a déjà été réalisé. Ces modèles sont calculés à une fréquence quasi-journalière par des batchs Spark qui tournent sur du Dataproc (Spark/Hadoop managé). Pour scheduler ces batchs, nous utilisons une solution maison, mais nous sommes en train de regarder du côté de Google Cloud Composer, qui n’est en fait qu’un Airflow managé. Les modèles calculés par ces batchs sont sérialisés et stockés dans Google Cloud Storage. Derrière, notre application Scala de « serving » n’a plus qu’à charger ces modèles et exposer une API de recommandation.

Pour être très efficaces sur les recommandations (entre 2 et 15 ms), nous utilisons des machines Google Compute sur-mesure (64GB de RAM et 48 vCPU). L’application est multi-threadée pour exploiter au maximum le potentiel de ces machines.

Et quid des données desquelles vous dépendez pour les recommandations en plus de ces modèles ?

Nous utilisons principalement BigTable pour stocker les données. C’est sans doute le service de Google qui est le plus mis à contribution. C’est quasiment comme HBase, à quelques différences près, et d’ailleurs nous l’attaquons via la même API.

Quasiment tout est stocké en Protobuf dedans, ce qui permet d’avoir un typage fort car BigTable se base principalement sur des tableaux d’octets. Dans ces données, on retrouve les référentiels produits, mais aussi toutes les informations liées à un utilisateur : profil, activités sur les sites clients, etc. Dans l’application de serving, toutes les données et méta-données intéressantes sont chargées en RAM afin d’avoir des réponses aussi rapides que possible.

Du coup, après ce chargement en RAM, comment es-tu sûr d’avoir quelque chose à jour ?

Depuis peu, l’équipe API utilise Pub/Sub pour mettre à jour tout ce qui est référentiel produit. De notre côté, nous écoutons ces topics Pub/Sub pour savoir quels référentiels produits ont été mis à jour, et cela nous permet de ne réimporter que les données nécessaires depuis BigTable, et réduit ainsi la charge appliquée à ce dernier (auparavant, les référentiels produits de tous les clients devaient être rechargés).

En parlant de Pub/Sub, cet outil peut aussi jouer un rôle très interéssant de « bus de messages » que nous souhaitons exploiter pour faciliter la communication entre les différents services. Avec un intermédiaire aussi fiable, c’est plus simple de se concentrer sur l’applicatif et d’adopter une approche microservices. Un grand chantier est en train de se faire de ce côté.

À propos des services GCP que cette Team API utilise et pas vous côté Team Data, il y en a d’autres ?

Oui, ils ont besoin d’un Redis notamment pour mettre en cache des données souvent requêtées, et qui permet de ne pas surcharger BigTable. Jusqu’ici, ils avaient une machine Redis dédiée sur une instance Compute Engine vu que Google n’en proposait pas en managé. Mais c’est en train de changer : Google a sorti du Redis managé en bêta (MemoryStore) et l’équipe a participé à cette bêta !

Ils ont aussi du Dataflow sur la partie imports, qui permet de concevoir facilement et de scaler automatiquement les tâches qui demandent beaucoup de ressources. L’API d’Apache Beam permet de décrire chaque job.

Pour la partie analytique, ils utilisent également BigQuery qui est plus simple d’utilisation que BigTable, et surtout plus adapté pour ce type de requêtes.

Finalement, ils utilisent aussi GKE (Kubernetes managé). De notre côté, nous ne nous sommes pas encore penchés dessus, mais nous avons tout de même commencé à automatiser les déploiements dans des conteneurs Docker sur des machines tournant sur Container-Optimized OS. Kubernetes est peut-être l’étape suivante pour orchestrer tout cela, mais pour l’instant, nous y allons petit à petit sur cette partie.

Sur quoi travailles-tu au quotidien dans tout ceci ?

Un peu de tout : dans l’équipe Data, même si chacun a ses préférences, tout est fait pour que nous puissions participer à tous les sujets. De mon côté, étant plus attiré naturellement par les parties Craftsmanship et DevOps (notamment le pan automatisation), j’ai essayé d’apporter ces compétences à l’équipe à travers la mise en place de plusieurs choses : des tests bien sûr, à la mise en place d’un repository manager (Artifactory), d’outils de CI (Travis CI), l’automatisation de l’infrastructure (Terraform, Packer) en passant par la partie déploiement et automatisation à base de conteneurs. L’objectif ultime de ce dernier point étant à terme de faire des mises en production en un simple clic !

En parlant de tests, ça donne quoi avec des services de Google Cloud ?

Les tests d’intégration nécessitent des émulateurs de BigTable et Pub/Sub pour pouvoir être lancés localement. Google fournit bien des émulateurs de Bigtable et Pub/Sub via gcloud beta emulator bigtable par exemple, mais ce n’est pas du « vrai » local, et nous ne pouvons donc pas tester sans accès à Internet si on les utilise, ce qui est vite limitant.

En conséquence, nous utilisons des images Docker communautaires pour simuler Bigtable (shopify/bigtable-emulator:0.1.0) et Pub/Sub (knarz/pubsub-emulator:latest). C’est vraiment dommage que Google ne fournisse pas ces images officiellement. Du coup, ce n’est pas vraiment ce qu’on pourrait qualifier de clean, car on se retrouve à dépendre d’un tag latest d’une image Pub/Sub créée par un anonyme, parce qu’il n’y a rien d’autre…. Nous envisageons sérieusement de recréer nos propres images et de les héberger dans notre propre Container Registry pour avoir plus de contrôle.

Pour ce qui est de lancer les tests : nous utilisons Maven sur le projet (nous étions sur sbt avant, mais nous avons jugé que c’était trop lourd à maintenir et qu’il y avait beaucoup de défauts), et nous passons donc par le plugin docker-maven-plugin qui permet de démarrer des conteneurs avant la phase de tests et de les détruire après. C’est très pratique et cela permet de garantir des builds reproductibles, d’autant que le lancement de Maven se fait aussi à travers un conteneur Docker !

C’est la partie tests qui pose le plus de problèmes selon toi ?

Pas nécessairement non. Côté Google, c’est clairement les dépendances.

L’utilisation de tous les produits Google ensemble au sein d’un même projet donne de jolis conflits de dépendances. Entre le connecteur Spark – GCS qui utilise Guava 24 (quand on sait que Spark et Hadoop sont compatibles avec des versions 12 ou 14), les bibliothèques client comme BigTable qui s’amusent à shader des dépendances comme Netty, cela ne peut que causer des soucis ! Certains produits manquent aussi clairement de maturité : par exemple, il n’y a qu’à regarder le dépôt de Pub/Sub sur Mvn Repository : 14 nouvelles versions en bêta entre février et avril… difficile donc d’avoir une API stable dans ces conditions !

Nous avons donc eu une grosse phase de nettoyage du code, et surtout d’éclatement du projet en différents modules pour éviter à tout prix ces conflits de dépendances. C’est désormais stabilisé, mais ça a demandé pas mal de travail au niveau architecture et structure du code.

Autre point : le support de Google, qui est d’une efficacité variable. Cela peut être très rapide pour certaines questions théoriques (réseau dans notre cas), comme cela peut être très lent et fastidieux. Nous avons traîné de janvier à avril une issue sur Dataproc, avec 3 interlocuteurs différents, qui concernait des problèmes de stabilité sur les batchs de calcul des modèles, qui échouaient parfois lors de l’utilisation de nœuds préemptibles. Heureusement que les batchs ne sont pas « critiques » et que l’on peut se permettre dans certains cas de les décaler d’une journée.

C’est aussi le jeu des services managés : d’un côté très pratique car on peut démarrer un cluster Hadoop en 2 minutes, d’un autre côté il est très difficile de détecter un problème sans avoir la main sur l’infrastructure, et encore plus difficile de le corriger ! Mais d’un point de vue général, l’utilisation de services managés nous enlève quand même énormément de contraintes côté infrastructure. Du point de vue d’Early Birds, ils y sont très clairement gagnants.

Par curiosité, vous monitorez tout ça comment ?

Côté monitoring, nous utilisions New Relic, qui permettait principalement de pouvoir tracer tous les calls d’API et de voir combien de temps prenait un appel de bout en bout (à titre d’information, on ne dépasse que très rarement 50ms). Cependant, son utilisation chez Early Birds était plutôt réservée au monitoring des API NodeJS. Depuis peu, nous avons tout basculé sur Dynatrace, qui permet aussi de remonter des métriques sur la partie JVM.

Côté Google, Stackdriver (l’équivalent d’AWS CloudWatch chez Google) est aussi utilisé, dans une moindre mesure. En réalité, cela sert principalement à gérer les coûts, mais on pourrait probablement l’utiliser en complément de Dynatrace pour remonter des métriques basiques (nombre de machines démarrées sur GCE, trafic réseau, stockage utilisé, etc).

Un dernier mot Jonathan ?

En résumé, pour ce qui est des produits Google Cloud Platform, côté Data nous utilisons :

• Dataproc pour lancer des clusters Hadoop à la volée et y lancer des batchs Spark
• Cloud Storage pour le stockage des modèles
• BigTable pour stocker toutes les infos clients et produits
• Compute Engine pour nos instances de Serving (basé sur Container-Optimized OS)

Et côté team API :

• Pub/Sub pour la mise à jour du référentiel
• GKE pour orchestrer leurs services
• Dataflow pour lancer des jobs d’import de référentiel (batch ou temps-réel), entre autres
• Bigquery pour quelques statistiques

Merci Jonathan pour tous ces détails !

Conclusion

La Data dans le Cloud et GCP étant des thématiques en plein essor, vous en entendrez à nouveau parler très bientôt dans les colonnes de ce blog. Ce retour transparent d’un Xebian sur un cas client concret et sur ses aventures du quotidien est également un format que nous répéterons à l’avenir, stay tuned!