Ballr

D2SI_Blog_Image_Ballr.jpg

Ballr est une nouvelle application de Live Fantasy Sport. Choisissez votre league et vos équipes, un match et un joueur, chacune de ses actions vous fera gagner des points (ou en perdre, si c’est une action ratée!). Le projet Ballr a la particularité d’être porté par une équipe internationale, avec des intervenants à Singapour, à Hong-Kong, en Chine...et D2SI ! Ballr fonctionnant en live pendant les matchs, l’application est un véritable challenge en termes de performance, de scalabilité et de résilience. Mêlant Dev et Ops, le projet a mis à contribution nos meilleurs experts AWS.

Développée par une start-up, l’application Ballr utilise massivement les services AWS comme ECS, Lambda, Kinesis, Elasticache, DynamoDB. Au moment où D2SI rejoint le projet, l’enjeu est triple :

  • Créer une plateforme de production
  • Automatiser la chaîne de déploiement en fonction des environnements
  • Travailler sur la performance et la scalabilité de la solution
D2SI_Blog_Image_LogoBallr.png

La plateforme ne supporte qu’une centaine d’utilisateurs, alors qu’elle doit en accueillir plusieurs dizaines de milliers. Dans un premier temps, l’équipe D2SI se concentre sur la stabilisation de la chaîne de déploiement et son automatisation avec Terraform. L’équipe lance ensuite les tests de performance afin d’analyser le comportement des différents composants Amazon, identifier les points de saturation et optimiser l’architecture pour la performance.

https://www.youtube.com/watch?v=Zw4od3k8BSk

Différents points sont identifiés : certaines API AWS sont trop appelées et génèrent du throttling, il y a des problèmes de bande passante réseau, certains objets volumineux transmis souvent saturent le cache, etc. Une grande partie de l’optimisation consiste également à mieux dimensionner les tables DynamoDB. Les tests sont conduits de manière itérative : un certain volume d’utilisateurs est simulé, et une fois le point de saturation identifié, soit on apporte les corrections du côté des paramètres Amazon, soit le code de l’application est modifié.

S’il n’y a pas eu de modification en profondeur de l’architecture de l’application, le conseil de D2SI s’est focalisé sur l’optimisation des composants AWS : par exemple en plaçant les objets en cache plutôt que dans DynamoDB, en travaillant sur la taille des objets dans le cache, le regroupement des appels d’API quand c’était possible. Plus globalement, les best practices recommandées par AWS ont été appliquées, comme la ségrégation des comptes AWS avec trois comptes, Master, Production et Staging plutôt qu’un seul, et une révision de la gestion des accès.

La particularité de Ballr est de s’appuyer largement sur le Serverless avec AWS Lambda. Si les appels frontaux sont servis par des containers dans ECS, et que le scaling est fait avant les matchs (pré-scaling), Lambda est utilisé pour les processing backend et caching. En effet, les donnés sont stockées dans DynamoDB et cachées dans Elasticache par Lambda; tout le calcul des scores utilisateurs est fait dynamiquement avec Lambda, chaque événement dans le match venant modifier les données de match dans DynamoDB puis les scores des joueurs via Lambda. Etant donné que Ballr repose en grande partie sur AWS Lambda, et que la performance est un point critique, nous avons été amenés à travailler sur le monitoring des Lambdas. Il était en effet essentiel de comprendre comment les fonctions se comportaient : combien de fonctions sont invoquées ? Combien de temps mettent-elles pour s’exécuter ? Si les lambdas s’exécutent trop lentement, cela impacte les coûts et la performance de l’application.

De ce projet, nous avons retiré une connaissance approfondie des services ECS, DynamoDB et Elasticache sous forte charge. A cette occasion, nous avons apprécié l’aide d’AWS, qui nous a mis en contact avec des experts de ces services. C’est en discutant avec eux du détail de fonctionnement de ces services que nous avons pu résoudre les challenges posés par l’architecture de l’application Ballr.

Pour discuter d'architectures Serverless, de migration vers le Cloud AWS ou d'applications Cloud native, retrouvez-nous lors de l'AWS Summit Paris 2017