La plateforme la plus performante du marché

La solution FollowAnalytics permet de comprendre les comportements des utilisateurs sur web et mobile et d’augmenter sensiblement le taux de rétention, grâce à des campagnes marketing finement ciblées (push , In-App). La performance des campagnes repose sur différents niveaux de granularité: type de device, activité au sein de l’application, nombre de pages vues, localisation des téléchargements, crashs etc.

 

Dans un souci continu d’offrir une meilleure segmentation (secret d’une stratégie de personnalisation réussie) et en raison de nos clients présents dans le monde entier, nous récupérons une quantité très importante d’informations basée sur des millions de serveurs web et mobile, aux quatre coins du globe. C’est grâce à cette data qu’il est possible de connaître finement le comportement de chaque utilisateur et de lui adresser la campagne la plus adaptée.

Quelques chiffres 

Au cours des derniers mois, nous avons enregistré des milliards de requêtes sur notre plateforme, permettant à nos clients de mieux comprendre les données générées par les mobinautes (une requête correspondant à une à plusieurs interactions du mobinaute avec son application).

Plusieurs études s’accordent à le dire, l’analytics est un véritable facteur différenciant dans une approche de personnalisation sur web et mobile. Nous clients le savent et nous choisissent en grande majorité pour cette raison.

Sur les 5 derniers mois, nous avons dépassé les 20 milliards de requêtes, avec des pics entre 5 000 et 20 000 requêtes par seconde, ce qui correspond en moyenne à 1 million de requêtes par minute.   

Number of requests per second reaching our AWS ALB

Pour rendre le tout plus compliqué certains de nos clients envoient des millions de notifications push sur une période de 1 à 2 minutes (Ex: app media). Notre infrastructure peut envoyer jusqu’à 100 millions de push par minute. À ce jour, c’est l’un des taux d’envoi le plus puissant du marché. Selon des études, en moyenne 5 à 10% des mobinautes recevant une notification ouvriront l’application dans les prochaines minutes. Constatant que notre plate-forme connaît des pics d’activité considérables lorsque nos clients ciblent des millions d’appareils, nous devons être en mesure de faire évoluer rapidement la plate-forme pour pouvoir traiter les demandes sans problème.

Exemple de pics auxquels nous faisons face
Nombre de demandes reçues dans la minute qui a suivi le pic.

Un de nos clients a couvert la Coupe du Monde cette année, ce qui a représenté également un trafic très important à gérer, comme le montre le graphique.


Basé sur les pics représentés à travers le graphique, je vous mets au défi de deviner de quel match il s’agissait !

Exemple de pics observés durant le match de la finale de la Coupe du Monde 2018
Notre consommation CPU (Central Processins Unit) augmente quand les requêtes arrivent. Par conséquent, le nombre de nos pods fluctue automatiquement en fonction pour être en mesure de prévenir tout éventuel erreur ou blocage.

Avant la migration AWS EKS

En lien avec les graphiques que vous avez pu observer ci-dessus, notre solution face à de tels volumes de données est d’investir dans une technologie de pointe. Par conséquent, nous avons décidé de faire fonctionner notre pipeline de données sur Kubernetes.

Puisque AWS n’offrait pas le service EKS en Europe avant le 5 septembre 2018, il nous a fallu l’héberger nous-même. Nous avons fait tourner Kubernetes pendant un an en utilisant Rancher, un excellent outil pour gérer des conteneurs Docker, que nous utilisons toujours pour gérer nos bases de données distribuées (Cassandra et Kafka).


Ce n’est pas très compliqué de configurer Kubernetes sur Rancher, la plate-forme est très simple, car elle gère l’installation de tous les composants Kubernetes comme etcd, kubelet, etc. Cependant, vous devez toujours vous occuper du plan de contrôle de Kubernetes. Cet aspect est primordial car il sous-tend toute la planification, le routage, etc.


Si votre plan de contrôle est défaillant, vos services peuvent rester actifs mais vous ne pourrez plus déclencher de pods supplémentaires. Si le cluster doit évoluer en fonction de votre stratégie HPA, il ne pourra pas le faire, en raison du dysfonctionnement du plan de contrôle. De plus, si vous devez déployer un correctif en production, cela ne fonctionnera. Enfin, si vous devez supprimer un service de la production, vous ne pourrez pas non plus.


Afin de palier à tout éventuel souci concernant le plan de contrôle et assurer une disponibilité maximale de notre plateforme, nous avons répartis nos nœuds dans 3 différents AWS AZs en Irlande.

 

Rancher appelle /Ceci correspond à une “stratégie de plan de résilience”, la documentation sur le sujet est disponible ici.

Vous devez également être vigilant aux sauvegardes et aux restaurations d’etcd. Cette précaution vous permettra de retrouver votre état initial, dans le cas où vous décidez de migrer vos clusters  kubernetes.

Au sein de FollowAnalytics, nous avons opéré ainsi en utilisant le service AWS EFS et le système de sauvegarde automatique de Rancher pour etcd (insérer des pannes dans le système de production pour s’assurer qu’il réagit comme attendu). Nous avons également simulé à plusieurs reprises la récupération après catastrophe des clusters. Cette méthodologie nous a permis d’être en mesure de savoir comment réagir et quoi faire en cas de problème. Si vous souhaitez gagner en sérénité d’un point de vue de sécurité, nous vous recommandons d’opérer des simulations soit automatiquement (Chaos Engineering), soir manuellement (GameDays). .


Concrètement nous avons eu besoin de redimensionner notre etcd deux fois au cours de la période d’exécution de notre Kubernetes auto-hébergé. À un certain moment, la charge était si élevée que le cluster est devenu très lent, ce qui peut être quelque peu effrayant lorsque vous avez un important trafic. Pour illustrer ce phénomène, nous pourrions paraphraser Andrew Widdowson en disant que cela reviendrait à «Changer les pneus d’une voiture de course à 160 km/h”. C’est ce que vous pouvez ressentir  en mettant à jour votre cluster Kubernetes sans utiliser un service géré tel qu’AWS EKS.

Malgré tous les défis et challenges liés à la gestion de notre propre cluster Kubernetes, nous sommes parvenus à fournir un service performant et de qualité en maintenant la disponibilité de notre infrastructure à 99,99%.

La migration vers AWS EKS

L’année dernière, AWS a rendu EKS disponible globalement. Ce service a d’abord été disponible aux États-Unis puis, quelques mois plus tard, en Irlande. En raison de notre politique de conformité GDPR, nous avons attendu la publication du service en Europe. Bien que nous ayons pu gérer toutes les opérations en maintenant notre propre cluster Kubernetes, cela représentait une tâche très pénible et qui accaparait énormément de temps. De plus, la complexité allait croissante avec la quantité de trafic que nous avions à gérer. La décision la plus pertinente, tant pour nos équipes que pour la performance de notre plateforme, était de passer à EKS. Cette décision permettait toujours de continuer à utiliser Rancher pour approvisionner le cluster EKS à l’aide de Rancher 2.0. Néanmoins  nous avons donc décidé de ne pas l’utiliser pour l’instant. Nous avons toujours Rancher 1.6 en cours d’exécution et nous n’étions pas favorable à ce que deux cluster de versions différentes fonctionnent en même temps.

Opérationnellement, pour le déploiement de notre cluster, nous avons choisi Terraform car nous l’utilisons déjà pour gérer l’ensemble de notre infrastructure. En effet, toute notre infrastructure étant gérée par Terraform cela nous ait apparu parfaitement logique Personnellement, j’aime également la manière dont Terraform est structuré avec HCL. Néanmoins il peut s’avérer judicieux d’utiliser AWS CloudFormation. Si cela est votre cas il n’y a aucune contre-indication. CloudFormation est très puissant et intégré aux services AWS. Choisissez donc la méthode qui correspond le mieux à vos besoins.

Dans notre contexte d’activité quelques minutes d’indisponibilité peuvent s’avérer vraiment critiques. Nous avons donc dû migrer de notre ancien cluster vers le nouveau de sorte que ce soit imperceptible sur notre qualité de service. Nous y sommes parvenus en remplaçant notre alias Route 53 par le nouveau balanceur , attendant que le trafic soit géré à 100% par le nouveau cluster avant de fermer l’ancien. Les graphiques ci-dessous montrent la migration en direct. Au cours de cette migration, notre CI a été configuré pour se déployer en même temps sur les deux clusters au cas où nous aurions besoin d’appliquer un correctif en urgence. À la fin de l’opération, la migration n’a eu aucun impact pour nos clients. Ils étaient capables d’effectuer leurs analyses tout en envoyant des messages push. Nos équipes de développeurs, quant à eux, n’ont pas plus remarqué la transition. La seule nouveauté pour eux a été un moyen de se connecter au nouveau cluster, qui est maintenant plus sécurisé. En effet, désormais pour pouvoir se connecter au tableau de bord Kubernetes, les développeurs doivent générer un jeton qui expire toutes les 15 minutes. De plus, les rôles IAM sont liés aux règles RBAC, ce qui nous permet de limiter leurs accès très facilement, en cas de besoin.

Conclusion 

Le principal avantage de la migration du cluster résidait dans le fait de ne plus avoir à s’occuper du plan de contrôle de Kubernetes et de ne pas penser à l’évolution ni à la fiabilité de ces composants, puisque cette responsabilité est maintenant déléguée à AWS. De plus, il était  moins compliqué de déplacer notre cluster EKS vers une autre région avec notre script Terraform. Cela permet d’augmenter la capacité de notre plate-forme à effectuer une récupération à la suite d’un problème, et par conséquent, notre fiabilité et notre disponibilité.

En termes de coût, nous avions 6 nœuds pour prendre en charge le plan de contrôle (3 pour etcd et 3 pour les autres composants du cluster). Bien que AWS nous facture la gestion du plan de contrôle, le fait de payer environ 140 dollars reste bien moins cher que le déploiement de six machines et leur maintenance (ce qui représente le coût caché).

Avec ce nouveau cluster, nous avons également été en mesure de gérer le contrôle d’accès en fonction de nos rôles IAM rattachés aux développeurs en fonction de leurs besoins et de leurs connaissances. C’est un gain considérable en termes de sécurité. De surcroît, le cluster lui-même est maintenant beaucoup plus rapide.

La prochaine étape nous concernant consistera à transférer notre cluster Kafka vers AWS MSK et à rendre Cassandra encore plus évolutif lorsqu’il fonctionnera en sur EKS. Grâce au pipeline d’ingestion de données volumineuses que nous possédons et au cluster partiellement géré par AWS, nous sommes pleinement en mesure de gérer plus de trafic et d’obtenir un niveau d’analyses jamais atteint auparavant.

 

Auteur: Hugo HENLEY, DevOps Engineer

Traducteur: Naëlle HADJI-BORMANN, Responsable Marketing EMEA

Révision technique: Thomas LECAVELIER, Senior backend Engineer