Les leçons d’une migration multicloud chez Groupon
Il y a un an, Groupon finalisait sa migration vers AWS et GCP. Quel bilan en tire-t-il, plus spécifiquement en matière d’optimisation des coûts ?
Appréhender ses systèmes sous la perspective des services qu’ils hébergent est une chose. Les penser sous le prisme de leurs utilisateurs en est une autre. Un constat qui ne mange pas de pain… et que Groupon a pu vérifier lors de sa migration cloud.
Voilà près d’un an que la démarche a abouti. Le décommissionnement des datacenters a suivi. L’essentiel du front-end réside aujourd’hui sur AWS ; le back-end, principalement sur GCP.
Chaque ressource a son tag, de type « service » (ce qui permet de l’attribuer à une équipe). Il fut question d’ajouter des tags « environnement » et « propriétaire », mais Groupon a déterminé que les données potentiellement générées ainsi pouvaient être réunies par d’autres moyens. Notamment parce que son architecture séparait les environnements au moyen de comptes (AWS) et de projets (GCP). Et que la gestion des propriétaires faisait l’objet d’un mapping distinct.
Certains de ses services exploitant les deux clouds, Groupon a opté pour un outil de reporting tiers : Cloudability, d’Apptio. L’équipe FinOps y a greffé un ensemble de rapports standardisés.
Des optimisations sur Keyspaces…
Le passage dans le cloud a donné davantage de visibilité sur l’usage des ressources. Il y eut quelques quick wins en matière d’optimisation des coûts, comme la suppression de ressources non utilisées dans des environnements de dev et de diverses données qui n’étaient plus nécessaires (parmi elles, des logs vieux de sept ans).
Dans cette lignée, on a, notamment, appliqué des politiques de cycle de vie sur les buckets S3 et GCS. Mais aussi mieux configuré, sur GCP, les paramètres d’extinction et de scaling des VM.
Les travaux ont également impliqué la refonte de structures de données. Exemple sur le service stockant les événements utilisateur (impressions, clics, achats…). L’information est stockée à trois échelles temporelles (heure, jour, mois), avec Cassandra comme data store primaire.
AWS Cost Explorer et CloudWatch ont permis d’évaluer les coûts que représentaient les opérations de lecture et d’écriture. L’une des mesures alors prises a consisté à ne générer plus qu’un événement pour un certain nombre d’actions des utilisateurs (contre parfois une douzaine, voire une quinzaine). Une autre a induit la définition d’un niveau de cohérence plus faible pour les opérations de lecture sur AWS Keyspaces (Cassandra).
… comme sur Dataproc
Sur la partie data warehouse, une grosse portion des traitements se faisaient initialement dans Dataproc, sur des VM N1. Or, bien des tâches ne nécessitaient pas une telle config. On est donc passé à des E2, réduisant de 30 % le coûts mémoire et CPU. En parallèle, l’usage de Terraform s’est développé, avec des modules partagés.
Les travaux ont aussi englobé les bases de données RDS, pas pleinement utilisées. Pour ce qui est du traitement des topics et des événements Kafka, l’infrastructure était bien dimensionnée. Le problème était plutôt l’obsolescence – ou en tout cas l’absence d’usage – de certains événements de reporting. C’est à ce sujet que Groupon met l’accent sur la « perspective utilisateur »…
Illustration © bilal ulker – Adobe Stock
