Faciliter les rencontres, c’est la vocation d’Happn, une application de dating 100% mobile. En permettant à ses utilisateurs de retrouver ceux qu’ils ont croisé, cette application basée sur la géolocalisation a séduit plus de 14 millions de personnes depuis son lancement en 2014. Mais derrière la magie du rapprochement des âmes soeurs et esseulées, il y a aussi celle d’une autre rencontre… entre Happn et le Cloud.

Présente dans plus de 35 villes majeures, de Paris à Londres, New York, Los Angeles, Istanbul, Sao Paulo, Buenos Aires, Hong Kong et Tokyo… l’application Happn a dû rapidement relever les challenges liés à son succès. Marc Falzon, Lead Operations Engineer chez Happn a commencé à réfléchir à l’évolution technique de la plateforme courant 2015. A ce moment, l’infrastructure était concentrée en un seul point géographique, et face à la croissance internationale de la société, il était nécessaire d’envisager une décentralisation de l’infrastructure, afin d’améliorer l’expérience utilisateur notamment en Asie et en Amérique du Sud. Le choix d’une infrastructure Cloud s’est rapidement imposé : elle offre une flexibilité et une facilité de déploiement sans commun avec une infrastructure physique.

C’est dans le cadre de cette réflexion autour d’une migration sur le Cloud que Happn a sollicité l’expertise de D2SI, afin de faire une étude approfondie de l’offre cloud public : quelles sont les forces et faiblesses de chaque acteur, quel service est le plus à même de répondre au cahier des charges d’Happn ?

Les besoins d’une migration vers le Cloud public

Dans son contexte de croissance rapide, Happn souhaite être présent physiquement dans les régions du globe où sont ses plus importants marchés (Europe, Amerique du Nord et Sud, Asie). Ce qui signifie déployer au plus près des utilisateurs, et assurer la fiabilité des performances et du service d’une manière générale. Enfin, au vu de la nature du service proposé par Happn, qui doit être accessible 24h/24 et 7 jours/7, la solution retenue doit aussi pouvoir répondre à des impératifs de budget. En effet, le service Happn traite de gros volumes de données, notamment puisque les données d’un utilisateur parisien doivent par exemple être disponibles lorsqu’il est en voyage à New-York, ou ailleurs. Cela implique que les clusters de bases de données Cassandra soient allumés en permanence. Globalement, les composants stateful représentent une forte part de l’infrastructure… et donc de la facture.

Une première série de tests est initiée avec l’aide de D2SI, et notamment un Proof of Concept faisant appel à Terraform, afin d’établir un modèle permettant de déployer des unités d’infrastructure auto-suffisantes. La réflexion porte également sur le choix des services managés proposés par chacun des trois grands acteurs du cloud : quels services confier, et quels services traiter en interne ?

Pour cette raison, l’objectif de départ était de migrer d’une infrastructure centrale assurant l’ensemble du trafic vers une infrastructure distribuée sur des relais servant le trafic et les données des usagers locaux. Chaque relais doit cependant disposer de l’ensemble des données du monde entier, d’où l’importance du volume de données. Les bénéfices attendus de cette migration sont essentiellement liés à l’expérience utilisateur : moins de latence réseau, meilleure réactivité de l’application qui se connecte à une infrastructure plus proche… Cela permet aussi à Happn de répondre aux besoins de scalabilité, par exemple pour répondre à un pic d’utilisation suite à une campagne TV.

Dans le cadre de cette réflexion initiale, pour Happn le conseil apporté par D2SI a été déterminant, comme nous l’explique Marc Falzon : “Bénéficier de l’expertise de Laurent Bernaille sur le Cloud nous a fait gagner beaucoup de temps. En adoptant d’emblée les meilleures pratiques, nous avons pu obtenir des résultats probants en une seule journée, qui nous auraient pris des semaines à obtenir si nous avions fait ces tests sans aide extérieure.”

Le choix de Google Cloud Platform

L’équipe technique Happn a finalement porté son choix sur Google Cloud Platform. Ce choix s’est fait sur une étude approfondie et complète de l’offre : accessibilité et disponibilité des services managés, régions proposées par les fournisseurs, performance, retour d’expérience, soutien de la communauté… “Tous ces critères ne viennent pas forcément à l’esprit quand on compare les offres Cloud, et le conseil de D2SI a été précieux”, nous confirme Marc Falzon. “Nous avons ainsi pu évaluer les outils déjà crées, les ressources disponibles et la documentation fournie par la communauté”. Après avoir comparé les services et coûts des principaux fournisseurs d’hébergement cloud, au vu des contraintes des composants stateful de Happn le prix a été un critère de choix non négligeable : dans le cas de Happn, l’offre de Google était 30 à 40% moins chère que ses concurrents.

Suite à ce choix, l’équipe Happn réalisé un premier POC avec Terraform sur Google Cloud Platform, avant d’envisager avec D2SI les différentes options possibles pour l’architecture. L’usage de Terraform est notamment en question, et finalement l’équipe Happn préfère capitaliser sur le Cloud Deployment Manager de Google. “Nous construisons en interne des outils qui utilisent le Deployment Manager, ce qui nous permet de raisonner avec des briques simples (des scripts qui utilisent l’API), sur lesquelles on a une maîtrise. Pour nous, c’est une façon de capitaliser et de construire des outils adaptés à nos besoins. Et ces outils sont faciles à prendre en main pour les nouveaux arrivants dans l’équipe”, nous explique Marc Falzon.

Une infrastructure industrialisable

L’infrastructure Happn étant pensée pour être industrialisée, l’équipe a fait le choix de Salt comme outil de gestion de configuration. Qualités de l’outil, large communauté, langage Python…les raisons de choisir Salt sont nombreuses. Et notamment, Salt permet la gestion de configuration et l’orchestration : l’équipe Happn peut ainsi reproduire la même stack d’une région sur l’autre, et ouvrir très facilement de nouveaux sites en fonction de ses besoins. Marc Falzon s’interroge néanmoins sur l’opportunité d’utiliser Salt Cloud pour manipuler ses ressources dans le cloud, créer des instances et les redémarrer. Est-ce que ce n’est pas outrepasser le domaine fonctionnel de l’outil ? La question reste ouverte, dans tous les cas il est toujours possible pour l’équipe de créer ses propres outils pour manipuler ses instances de façon industrialisée.

Côté containers, Happn utilise Docker en production, mais pas de façon automatisée. Les applicatifs sont écrits en microservices, chaque service tourne dans une instance Docker, et le déploiement de nouvelles instances de services se fait dans des containers. Cependant Happn réfléchit avec l’aide de D2SI à la mise en place d’un pipeline de déploiement continu, du développement jusqu’à la production. Dans ce cas, la question de continuer à utiliser Docker pourrait se poser : Docker a été très utile pour fournir de la containerisation et isoler les processus dans un contexte d’infrastructure où de nombreux serveurs étaient mutualisés, mais sur le Cloud où il est possible de lancer des centaines d’instances spécialisées, c’est différent. Une option serait par exemple d’utiliser Jenkins et Packer pour construire des images Google Cloud Platform contenant la nouvelle version de l’application à déployer.

Côté stockage, Happn a fait le choix de Google Cloud Storage pour stocker les fichiers liés à son infrastructure. L’équipe utilise également Docker Container Registry, Consul pour exposer les microservices. Enfin, comme on peut aisément l’imaginer, le Big Data est un sujet stratégique pour Happn : l’équipe en charge de ce sujet utilise Google BigQuery depuis quelques temps déjà, et a commencé à utiliser DataFlow à des fins d’analyse.

Enfin, au vu du flux de données à traiter par l’application en temps réel, Happn utilise également RabbitMQ comme système messaging. En fonction de l’évolution des volumes, ce choix pourrait se porter PubSub, voire Kafka quand il faudra traiter des milliers d’événements par seconde. Mais pour l’heure, l’équipe technique Happn se consacre essentiellement à rôder son infrastructure de façon à ce qu’elle soit prêt à scaler en un éclair face aux pics d’activité. Prochain chantier : la mise en oeuvre d’un pipeline de déploiement continu, avec l’aide de D2SI.