Si il y a encore peu de temps les architectures Serverless se limitaient à des POC, on voit aujourd’hui de plus en plus de projets en production s’appuyer sur Serverless et AWS Lambda. Et notamment dans les problématiques Big Data, où la scalabilité et la capacité de parallélisation de Lambda ouvre de nombreuses possibilités, comme des traitements MapReduce. Pour approfondir le sujet, nous vous proposons un focus sur la track « Patterns et bonnes pratiques des architectures Big Data en Serverless », présentée lors du dernier AWS Summit Paris par Rudy Krol, Solutions Architect AWS.

Pour ouvrir le sujet, Rudy Krol a commencé par poser le cadre du Serverless et du Big Data sur AWS. Pour déployer des architectures sur AWS, on peut en effet utiliser EC2 pour créer et gérer des VMs, les déployer de façon élastique, puis utiliser des produits Big Data, Open Source ou commerciaux, pour exécuter des batchs, et de supprimer les instances une fois les traitements effectués. L’autre approche consiste à utiliser des services managés, et plutôt que de gérer un cluster Spark sur EC2, on utilisera un service comme Elastic MapReduce pour créer un cluster sur lequel Spark est déjà installé et configuré. L’objectif étant d’automatiser le plus possible les taches d’infrastructure pour se concentrer sur la réalisation des applications.

En poussant cette logique, on en arrive au Serverless, qui en faisant abstraction des serveurs, permet d’utiliser des services au travers de leurs API. On se dispense ainsi de gérer la couche infrastructure, de se préoccuper de la scalabilité et des auto-scaling groups, de la disponibilité et des configurations d’ELB ou de la redondance. On accélère ainsi le time to market, à l’instar des équipes de 20 Minutes qui ont ainsi développé un skill Alexa.

Bonnes pratiques AWS Lambda

Plusieurs bonnes pratiques sont recommandées par Rudy Krol. Tout d’abord, la fonction doit être stateless. Lambda se charge en effet de déployer dans des conteneurs, mais à tout moment un conteneur existant peut être supprimé. Il est donc recommandé de stocker les données persistantes dans un datastore externe comme S3 ou DynamoDB.

Second point abordé, l’effet Cold Start, qui peut être défini comme le temps de latence mesuré à la première exécution de la Lambda. En effet Lambda déploie la fonction dans un conteneur, initialise l’environnement d’exécution (la JVM par exemple), puis exécute le code, initialise les objets, etc. Dans l’exemple ci-dessous, on peut voir le cas d’une fonction Python : en bleu, ce qui est exécuté à l’initialisation, et en vert ce qui est exécuté à chaque événement traité par la fonction. Pour gagner en performance, il est préférable d’éviter de réinitialiser les connexions à chacun des traitements d’appel.

Rudy Krol a ensuite abordé la question du déploiement dans un VPC, qui n’est conseillée que lorsqu’on souhaite accéder à des ressources privées. Lors du déploiement dans un VPC, Lambda va créer une interface réseau, ce qui peut prendre jusqu’à dix secondes, à ajouter au cold start global.

Enfin sur le sujet du Monitoring des Lambdas, on peut utiliser AWS X-Ray pour voir les dépendances entre Lambdas et analyser les causes d’erreurs. Pour une requête donnée, il est également possible de mesurer quel est le temps passé dans chacun des composants du système distribué.

Il également important de s’assurer que l’on choisisse le bon profil de puissance pour ses Lambdas. Le service est facturé à la durée d’exécution, et cette durée est proportionnelle à la mémoire allouée au conteneur (de 128 Mo à 1,5 Go). La mémoire est également associée aux capacités de CPU et de bande passante. La bonne pratique recommandée ici est d’utiliser Lambda Power Tuning, un outil Open Source qui crée un workflow Stepfunctions et l’exécute avec plusieurs profils de puissance. On obtient un rapport simplifié aidant à estimer le temps d’exécution, et donc d’établir le bon équilibre entre performance et coût. Sans cet outil, il est nécessaire de faire manuellement le test pour chaque profil de puissance.

Le Big Data en Serverless

Durant cette partie, Rudy Krol a effectué un rapide rappel des principaux services AWS destinés aux analyses en temps réel :

• S3 comme datalake, le service AWS le plus adapté au stockage d’une grande quantité de données. S3 est scalable (plusieurs Po peuvent être stockés), hautement disponible, hautement durable. Différentes options sont possibles pour ingérer les données dans S3.
• Athena pour exécuter des requêtes SQL sur S3 en mode Serverless
• Quicksight, outil Serverless pour visualiser les données et générer des dashboards
• Kinesis Streams pour l’analyse en temps réel. Ce service fonctionne comme un buffer conçu pour ingérer des données en continu

Refonte d’un pipeline Analytics en Serverless

Alexandre Ignjatovic et Benoit Tigeot, de la société Appaloosa, sont ensuite venus présenter leur retour d’expérience sur la migration d’un pipeline d’analytics. Appaloosa est un store d’applications mobiles, avec 7000 clients, 60 000 applications et 300 000 utilisateurs. Un nombre d’utilisateurs en plein croissance qui a rapidement posé des problèmes au pipeline initialement conçu alors que la société était encore une start-up en cours de lancement. L’architecture n’avait pas été conçue pour supporter une montée en charge, et la qualité du service s’est dégradée : lenteur de l’affichage des pages, volumes de données qui ne sont plus traités dans les temps, etc. Une situation difficile pour les développeurs qui passent en mode pompier, et qui n’ont plus le temps de concevoir des solutions à plus long terme. D’où la nécessité d’une refonte.

Cette refonte est contrainte pas plusieurs impératifs :

• Pas de devops, de DBA ou de Sysadmin dans l’équipe pour maintenir une base de données
• Besoin de répondre à une croissance constante
• Service disponible 24/7, pas de downtime possible
• Rester dans les limites d’un budget de 900$/mois

La solution retenue s’articule autour de Redshift, un datawarehouse managé et massivement processé. Alexandre Ignjatovic a profité de l’occasion pour partager des bonnes pratiques : être attentif sur le schéma de données (clé de tris, clés de filtrage, compressions…); ne pas interroger le cluster Redshift en parallèle par plusieurs processus, les performances ne seront jamais aussi bonnes que si les requêtes se font de façon séquentielle.

La première architecture mise en place faisait appel à Firehose, Redshift, DynamoDB et plusieurs fonctions Lambas. Cette architecture présentait l’avantage d’être facile à mettre en place et de ne pas nécessiter d’administration, mais également plusieurs inconvénients, comme une duplication aléatoire  sur une infime partie des données, l’impossibilité d’ajouter un consommateur à un flux Kinesis Firehose, ou la complexité de l’alimentation par batch en Lambdas.

La seconde architecture était plus complexe, avec un pipeline de collection d’événements faisant appel à Kinesis pour l’ingestion des données, la Lambda Stream to Firehose pour lire les événements sur Kinesis et les transférer sur Firehose, puis sur S3. L’accès aux données sur fait avec Postgres et Reshift.

Cette architecture est utilisée en production depuis 6 mois. Elle présente l’avantage de rester efficace quelle que soit la charge en écriture/lecture, de ne demander aucune action d’administration. Il est également possible d’ajouter des consommateurs sur le flux Kinesis et l’architecture est modulaire de façon à permettre de nombreuses évolutions. La contrainte de budget est largement respectée puisque les coûts fixes sont de 240$/mois, et les coûts variables de moins de 10$. Parmi les évolutions envisagées par l’équipe, l’utilisation d’Athena en tant qu’outil de BI, et de Stepfunctions pour matérialiser le workflow du pipeline. Pour en savoir plus sur ce projet, nous vous recommandons la lecture du post « Migrating our analytics stack from MongoDB to AWS Redshift » .