BetCity ou le besoin de gérer la haute disponibilité

BetCity : le contexte

En cette période pré-estivale de 2018, que vous aimiez ou non le sport et que vous aimiez ou non le football, vous avez surement entendu parler de l’événement de l’année ! Allez, on fait un effort, c’est une fois tous les 4 ans, c’est l’événement le plus suivi en France depuis 1998, et vous ne pourrez pas y échapper à la machine à café d’ici quelques jours …. Et oui, vous l’aurez reconnu, c’est la coupe du monde de football qui se déroule cette année en Russie !

FIFA_World_Cup_2018_Logo

BetCity : l’Application

Pour faire court, car le site est déjà en ligne sur BetCity.fr et explique tout en détails : l’idée est de pouvoir parier sur les matchs de la coupe du monde en mode team building (pas d’argent, seulement des Betcoins, la monnaie virtuelle :), et d’avoir une compétition grâce aux classements inter/intra entreprise, par équipe et individuel. Grâce à une expérience utilisateur soignée et un concept ludique, l’application s’adresse à toutes et tous, de Mme Michu de la compta à Mr Robert de l’entretien.

Une de nos accroches commerciales est la suivante :

Avec Betcity, vous disposez d’une plateforme clé en main, disponible H24, sécurisée et personnalisable aux couleurs de votre entreprise! Il ne vous reste plus qu’à inventer l’événement interne qui vous ressemble, en profitant de cet engouement naturel! Vos salariés vont A-DO-RER!

Ce qui nous amène donc vers le vif du sujet technique de ce billet, comment assurer la disponibilité et la sécurité de cette application, sachant que le traffic utilisateur va se concentrer sur les quelques minutes avant le début du match….

BetCity : L’architecture

En terme d’architecture logicielle et de stack logicielle, la solution retenue est la suivante :

Une brique logicielle front-end, : HTML 5/ CSS (UIKit) / Javascript (AngularJS)
Une brique logicielle back-end, API RESTfull : Node.js, Express framework, Sequelize (ORM)
Une base de donnée MySQL

L’avantage du découpage entre front-end et back-end et de pouvoir déployer chaque brique logicielle indépendamment de l’autre, et donc sur des serveurs différents si besoin.

La base de donnée est un élément indépendant lui aussi, et elle peut donc être hébergée aussi sur un serveur dédié, différent de celui utilisé pour le front et/ou pour le back.

Côté Back-end, nous utilisons une API Rest totalement stateless, ce qui est indispensable pour garantir la scalabilité horizontale permettant la haute disponibilité (HA). En effet, on peut avoir trois serveurs back-end qui tournent en parallèle, avec un load balancer (équilibrage de charge) qui répartit les requêtes de l’application vers 1 des 3 serveurs, sans avoir à adapter le code de l’application. Cela se fera de manière transparente grâce à la conception Stateless de l’API, Stateless veut dire qu’on ne garde pas d’états ou d’informations entre deux appels à l’API (pas de session, pas de variable globale qui s’incrémente, etc…). Chaque appel de l’API avec une entrée A donnera toujours le même résultat B, quelque soit la machine (serveur 1, 2 ou 3) sur laquelle il est exécuté.

BetCity : Ressources matérielles

Nous travaillons habituellement avec des serveurs VPS OVH, mais ne connaissant pas le trafic exact que nous allons avoir, la solution d’une architecture matérielle basé sur plusieurs VPS apparaît contraignante. En effet, pour tout ce qui est scalabilité verticale (upgrade du serveur), cela est non réversible chez OVH, si on upgrade un serveur pour un pic de charge, on ne peut plus revenir à sa configuration antérieure et donc à son coût initial.

La solution est de faire appel à un fournisseur de service cloud, et nous avons choisi AWS, avec lequel nous sommes le plus familier. AWS offre un double avantage :

Possibilité d’avoir un service managé Node.js : Avec le service Elastic Beanstalk d’AWS, on peut se concentrer uniquement sur son applicatif, et le déployer en quelques clics. Aws s’occupe de provisionner le serveur, d’installer l’environnement d’execution, et de rendre le service disponible.
Possibilité de gérer la haute-disponibilité : Là encore en quelques clics, on peut configurer un load balancer et un nombre min-max de serveur et des triggeurs (déclencheurs) pour le provisionning d’un serveur. Par exemple : Si CPU > 90% pendant 3 minutes, alors ajout d’un serveur à mon déploiement … Si CPU < 5% pendant 10 minutes, alors suppression de ce serveur … On peut ainsi passer de 1 à 4 serveurs déployés pour le service, en toute transparence, sans intervenir, et en ne payant que ce qui est consommé.

Ci-dessous : un exemple de configuration avec un équilibreur de charge et 1 à 2 instances.

ebs_conf_blog

En ce qui concerne la base de donnée, Elastic Beanstalk offre la possibilité de connecter une base de donnée à votre service, là encore en quelques clics, mais celle-ci sera uniquement disponible pour la durée de vie de votre service EBS. Si vous coupez votre service, la base de donnée est supprimé … Mais pas de panique, on peut créer une base de donnée indépendante sur AWS, avec le service AWS RDS, il faudra ensuite configurer les groupes de sécurité de votre application EBS pour qu’elle ait accès à cette base de donnée.

Un autre problème qui s’est posé à nous avec le déploiement vers AWS et qui est similaire au problème de la base de donnée : le stockage des fichiers.
En effet, l’application stocke les avatars des utilisateurs, et les logos des entreprises participantes. Or si on ne stocke pas ces fichiers sur un File System séparé de l’applicatif, lorsque le service s’arrête ou redémarre, on perd les fichiers qui ont été poussés sur l’application. Là encore, il existe un moyen, c’est de créer un file system « partagé » en dehors d’EBS, le service AWS s’appelle EFS (elastic file system). Là par contre c’est un peu plus compliqué, il faut être dans le même VPC pour y avoir accès, et on doit réaliser le montage du FS au sein de l’applicatif avec un fichier de conf dédié.

Les deux points précédents feront l’objet d’un post plus détaillé sur le sujet d’ici quelques semaines.

BetCity : Conclusion

Nous sommes prêts à absorber les pics de charge d’avant match, nous partons sur une configuration avec un load balancer et 1 à 4 serveurs max, de type t2.large (2vCPU, 16GB de mémoire), ainsi qu’une base de donnée AWS RDS Aurora avec cluster de serveur, et enfin un File System AWS EFS pour le stockage des images le tout réparti dans trois zones de disponibilité en Irlande (EFS n’est pas encore disponible dans la zone Paris).

On vous attend donc nombreux sur la plateforme pour la mettre à mal et devoir passer à 5 ou 6 serveurs t2.2xlarge 🙂

A vos paris ! BETCITY-PARI