Glovo gère 2 To de données par jour avec AWS

Glovo, leader mondial dans le secteur de la livraison, reçoit actuellement 2 To de données par jour des offres et des commandes en ligne de ses fournisseurs. Pour la multinationale espagnole, il est important que ces volumes élevés de données contribuent le plus possible à fournir le meilleur service à la clientèle. Cela a été rendu possible grâce aux solutions Amazon Web Services.

Glovo a été fondée en 2015 à Barcelone et s'occupe essentiellement de la livraison à domicile des commandes de nourriture en ligne. Aujourd'hui, l'application est présente dans 25 pays et plus de 1 300 villes, et compte plus de 150 000 restaurants et établissements partenaires. En plus des meilleurs restaurants, elle propose toute sorte d'établissements à ces utilisateurs, tels que des supermarchés, des magasins d'électroménager, des pharmacies et parapharmacies, et des boutiques de cadeaux par exemple.

Glovo possède une forte composante technologique et une plateforme qui connecte les clients, les entreprises et les coursiers via son site Web et son application mobile. Elle gère un volume de données de 2 To sur une journée. « En tant qu'entreprise en pleine croissance, avec des demandes de données (cas d'utilisation et quantités) qui augmentent rapidement, il est essentiel pour la réussite de Glovo d'avoir une structure solide de la façon dont nous collectons, rassemblons et exploitons les données pour avoir le plus grand impact possible sur l'entreprise, » explique Oliver Fenton, directeur de plateforme de données chez Glovo.

La protection des données personnelles des utilisateurs est très importante pour Glovo et cela permet de toujours garantir une sécurité maximale. « AWS nous permet d'atteindre l'objectif de stockage sécurisé des données en cas de besoin et d'y accéder tout en restant conforme aux règlementations en vigueur, » déclare Oliver Fenton. 

Glovo s'est tournée vers Amazon Web Services pour la première itération de sa plateforme de données. Cette décision a été prise suite aux recommandations de certains membre de l'équipe de données qui sont d'anciens utilisateurs des solutions AWS. Le produit choisi pour commencer la création de cette plateforme de données était Amazon Redshift, un service d'entrepôt de données géré dans le cloud. « Ce produit nous a permis de démarrer facilement et était assez puissant pour nous permettre de répondre à tous nos besoins, » reconnaît Fenton. Cette couche d'analyses de données qui s'exécute sur Amazon Redshift a été rapidement suivie par des cas d'utilisation ETL : « Le premier a été le compilation de données brutes (près de 100 Go de données brutes par jour). Nous utilisons la plateforme de big data Amazon EMR pour répondre à ce besoin. En particulier, la technologie Apache Spark sur les clusters éphémères Amazon EMR qui s'exécute sur les instances Amazon EC2, avec l'objectif de traiter les données brutes dans Amazon S3 et de créer des tableaux d'analyses, également stockée dans S3 et enregistrée dans le catalogue de données AWS Glue. »

Cependant, « peu de temps après cela, les personnes ont commencé à créer leur propre processus ETL sur ces données. Le traitement a également été réalisé dans Spark sur Amazon EMR (EC2) et a été orchestré à l'aide du module Luigi, un orchestrateur en open source développé par Spotify, déployé sur une instance EC2. Nous avons dû rendre certains résultats de ces ETL disponibles dans Looker, notre outil d'informatique décisionnelle, et en raison de certaines limites dans nos processus de l'époque, nous avons également dû créer des copies dans Amazon Redshift. »

Comme l'activité de Glovo grandissait de manière exponentielle, sa plateforme de données continuait de se mettre à l'échelle et avait besoin de couvrir une variété de cas d'utilisation. Un besoin d'augmentation du taux d'actualisation a été détecté pour améliorer la disponibilité des données opérationnelles, et Importer a été créé, un outil d'ingestion de données qui tire parti des capacités d'Apache Spark sur Amazon EMR (s'exécutant sur EC2) pour extraire les données des bases de données transactionnelles qui s'exécutent sur Amazon Aurora et d'autres types de sources, et les diffuser vers DataLake dans Amazon S3. Cela garantit que ces données restent disponibles sous forme de tableaux. « Ces tableaux sont créés à l'aide de données dans le format Delta et de tout le processus d'extraction et l'utilisation d'Importer est orchestrée par le biais de Luigi qui s'exécute sur une instance EC2, » continue le responsable de la plateforme de données de l'entreprise de livraison.

En parallèle au travail des équipes de données chez Glovo, les développeurs d'applications ont commencé à adopter des architectures de microservices, ce qui a généré de nouveaux cas d'utilisation pour gérer les données : « Nous avons commencé à diviser le backend en microservices. La communication inter-processus s'est faite à l'aide des flux Amazon Kinesis. Ces événements, au format Avro, ont été nécessaires pour certains cas d'analyses. Pour les télécharger dans S3, nous avons créé un cadre que nous appelons Rivers, à l'aide de la technologie Apache Beam et l'infrastructure du service géré Amazon pour Apache Flink, qui donne une structure de répertoires particulières aux événements qui simplifie un autre processus pour les collecter et les intégrer dans les tableaux d'analyses en utilisant Importer. »

Tous les cas décrits ci-dessus sont exécutés sur une plateforme monolithique de données, « qui ne met pas à l'échelle » précise Oliver Fenton, ce qui ralentit l'augmentation des cas d'utilisation et de la prise de décision opérationnelle autour de l'utilisation des données de l'entreprise. Pour cette raison, Glovo a commencé à s'orienter vers un data mesh qui lui permet de répartir les responsabilités et de donner une plus grande autonomie aux équipes en fonction de l'utilisation des données. « Dans le cadre de ce cheminement, nous avons commencé à créer ce que nous appelons des pipelines de données en libre-service (SSDP). Pour cela, nous utilisons toujours Spark sur Amazon EMR (EC2) pour le traitement, mais nous avons également inclus une instance Amazon Managed Workflows pour Apache Airflow (MWAA) par domaine de données, pour que les équipes de données aient plus de contrôle sur leur propre code et leurs déploiements. Les applications Spark et non Spark sont placées dans des conteneurs Docker et téléchargées dans l'Amazon Elastic Container Registry (ECR). Les applications non Spark s'exécutent sur Amazon Elastic Container Service (Amazon ECS) sur Fargate, tandis que les applications Spark s'exécutent sur Amazon EMR (EC2) et profitent de la prise en charge de YARN pour Docker. »

De plus, Glovo a mis Starburst en tant que moteur de requêtes pour son Data Mesh. « Nous avons commencé à utiliser Amazon Elastic Kubernetes Service (Amazon EKS) avec les équipes de données chez Glovo pour exécuter notre moteur de requêtes Starburst, supprimant éventuellement le besoin d'avoir Amazon Redshift en tant que moyen pour exécuter certaines requêtes utilisateurs de Looker. Nous avons également commencé à enquêter sur EMR dans EKS pour que nous n'ayons pas à payer le temps d'activation des clusters EMR (EC2), » raconte Oliver Fenton.

Grâce aux solutions AWS, Glovo a gagné en flexibilité dans la mise à l'échelle de sa plateforme dans le cadre du data mesh : « Dans le cas d'Amazon EMR, nous pouvons allouer des clusters qui ne seront actifs que pendant le temps de traitement nécessaire. Chaque groupe peut être dimensionné indépendamment. Ces différents clusters nous ont également permis d'isoler facilement les différents cas d'utilisation, » explique ce responsable technique de Glovo.

De plus, l'équipe de données a exprimé son intérêt pour les nouvelles fonctionnalités sans serveur disponibles dans les services AWS, tels qu'Amazon EMR ou Amazon EKS : « Parce qu'ils nous ont permis de commencer quelque chose, de le rendre opérationnel et de l'exécuter plus facilement sans avoir à connaître tous les détails sous-jacents. Cela a également réduit les efforts nécessaires pour le déploiement et le fonctionnement. » Même sans implémenter des modèles purement sans serveur (puisqu'ils ont été lancés que récemment par AWS), l'utilisation d'une combinaison de services s'exécutant sur AWS et l'adoption de Data Mesh « ont permis à Glovo de réduire le temps nécessaire pour créer des produits de données de 5 à 2 semaines. Grâce à la multitude de services axés sur l'ingestion, le traitement et l'utilisation des données dans AWS, nous, chez Glovo, avons pu créer et mettre à l'échelle une plateforme de données qui prend en charge l'ensemble de notre entreprise et qui évolue au fur et à mesure que nous nous rapprochons d'un modèle organisationnel Data Mesh. »

À l'avenir, l'entreprise veut migrer ses applications existantes vers Amazon Elastic Kubernetes Services (EKS) et investit déjà dans l'implémentation d'une couche de gouvernance, de sécurité et de contrôle de l'accès des données pour améliorer la gestion de l'accès aux données nécessaires pour chaque cas d'utilisation : « Nous exécutons Starburst sur EKS et nous travaillons maintenant pour que l'outil de gestion de l'accès des données Privacera s'exécute sur Amazon EKS. »  Glovo implémente également une solution Notebooks sur Amazon EKS (selon JupyterHub) « pour une collaboration en temps réel dans cet environnement de développement intégré. Ainsi, les analystes et les autres profils ayant un accès aux données dans Glovo pourront travailler plus efficacement, » conclut Fenton.