Songkick harmonise son infrastructure avec Memorystore

Songkick est une plate-forme de musique en direct doublée d'un service permettant aux utilisateurs de découvrir des concerts. Basée au Royaume-Uni, cette entreprise du Warner Music Group aide les amateurs de musique à trouver des événements en direct. Chaque année, grâce à Songkick, plus de 175 millions de mélomanes du monde entier peuvent suivre leurs artistes favoris, découvrir des concerts et diffusions en direct, et acheter des places en ligne (sur le site Web ou via l'application mobile), en toute sérénité. 

Nous travaillons avec une quinzaine de développeurs répartis dans quatre équipes basées à Londres. Mon rôle consiste à les aider à prendre des décisions techniques et à concevoir des solutions. Une fois la migration vers Google Cloud effectuée, nous souhaitions disposer d'une solution de mise en cache entièrement gérée capable de s'intégrer aux autres outils Google que nous utilisons. Nous voulions par ailleurs limiter la charge de travail de nos développeurs pour leur permettre d'élaborer des produits innovants qui plairont à nos clients. Grâce à Memorystore, le service de stockage en mémoire évolutif, sécurisé et à disponibilité élevée développé par Google pour Redis, nous sommes parvenus à atteindre ces objectifs.

Les services entièrement gérés de Memorystore éliminent les difficultés

Notre infrastructure d’origine de mise en cache s'appuyait intégralement sur des instances Memcached sur site. Et à l'époque, cette solution nous semblait facile à utiliser. Avec le temps, nous nous sommes tournés vers Redis afin d'exploiter ses fonctionnalités avancées (les dictionnaires et les incréments, par exemple). Notre architecture orientée services intégrait donc ces deux datastores en Open Source. Par ailleurs, nous possédions deux clusters Redis : le premier était réservé aux données persistantes, tandis que le second nous servait simplement de couche de mise en cache entre notre frontend et nos services.

Au moment de déterminer comment nous allions utiliser Google Cloud, nous avons réalisé qu'exploiter deux technologies de mise en cache (à savoir Memcached et Redis) n'offrait aucun avantage. Nous avons donc décidé de n'utiliser que Redis, qui répondait à tous nos besoins (éliminant ainsi le besoin d'apprendre à maîtriser les deux bases de données). Nous savions que Redis était plus difficile à utiliser et à gérer, mais cela ne nous a pas inquiétés outre mesure, car Google Cloud s'en chargerait entièrement une fois que nous serions passés à Memorystore. Ce dernier automatise les tâches complexes de Redis, comme l'activation de la haute disponibilité, le basculement, l'application de correctifs et la surveillance, ce qui nous a permis de nous concentrer sur de nouvelles opportunités d'ingénierie.

Nous avons tenu compte du nombre d'heures passées à réparer les clusters Redis défectueux et à déboguer les problèmes réseau. Les membres de notre équipe étant plus habitués à développer des infrastructures qu'à en gérer, ils passaient beaucoup de temps à résoudre les problèmes liés à Redis, ce qui les empêchait de se concentrer. Nous savions aussi qu'un outil autogéré entraînerait sans doute des temps d'arrêt côté utilisateur. Memorystore représentait donc une option sécurisée, économique et entièrement gérée qui nous éviterait tous ces désagréments. Il offre tous les avantages de Redis, sans les difficultés liées à sa gestion. Le choix s'est donc imposé de lui-même. 

Notre utilisation de Memorystore

Étudions quelques-uns de nos cas d'utilisation de Memorystore. Nous avons deux niveaux de mise en cache sur Memorystore : le frontend met en cache les résultats des appels d'API vers nos services, et certains services mettent en cache les résultats des bases de données. En règle générale, l'URL et toute valeur primitive transmise constituent la clé de mise en cache pour nos services frontend. À l'aide de l'URL et des paramètres de requête, le frontend détermine s'il possède déjà un résultat correspondant ou s'il doit contacter le service.

Certains de nos services intègrent une couche de mise en cache qui communique avec Redis avant de décider si elle doit contacter les bases de données, puis appelle notre logique métier et contacte les bases de données. Cette couche de mise en cache se trouve devant le service et fonctionne sur le même principe que la mise en cache frontend. 

Nous utilisons également Fastly comme couche de mise en cache devant nos interfaces. Pour une page individuelle, l'intégralité du contenu est donc susceptible d'être mise en cache dans Fastly. C'est le cas des pages de classement des meilleurs artistes sur notre plate-forme, par exemple.

Memorystore intervient pour les contenus côté utilisateur (lorsque la page dédiée à un événement récupère des informations sur l'artiste et sur l'événement, voire des recommandations pour l'artiste, par exemple). Si le cache Fastly de la page de l'artiste a expiré, Memorystore se tourne alors vers le cache frontend, qui communique avec les différents services pour afficher toutes les informations demandées sur la page. Dans ce cas, trois ensembles de données distincts se trouvent dans le cache Redis. Les pages de nos artistes contiennent des éléments qui ne sont pas mis en cache dans Fastly. Nous nous appuyons donc plus largement sur Redis. 

La valeur TTL (time-to-live) de notre cache Redis est assez limitée : il nous arrive parfois d'avoir un cache de 10 minutes seulement. En revanche, si les données sont particulièrement statiques, la mise en cache dans Redis peut durer quelques heures. Pour chaque élément de données, nous déterminons une durée de mise en cache raisonnable, puis nous définissons la valeur TTL en conséquence. Certains artistes peuvent enregistrer jusqu'à 100 000 appels par jour. Dans ce cas, une mise en cache de 10 minutes seulement influence déjà grandement le nombre d'appels que nous devons intégrer à notre service. 

Pour ce cas d'utilisation, nous disposons d'un cluster Memorystore à disponibilité élevée d'environ 4 Go de mémoire, et nous utilisons une règle d'éviction du cache allkeys-lru (le moins récemment utilisé). À l'heure actuelle, nous recevons environ 400 requêtes par seconde sur ce cluster lors des pics d'activité (pour une journée typique). Mais dans certaines circonstances, ce nombre peut augmenter sensiblement. 

Nous avions deux clusters Redis différents dans notre ancienne infrastructure. Le premier correspond à ce que je viens de décrire, et le second était un service Redis persistant. Lorsque nous avons envisagé de migrer vers Google Cloud, nous avons décidé d'exploiter les aspects de Redis dans lesquels ce service excelle. Pour cela, nous avons simplifié et redéfini les quatre ou cinq fonctionnalités utilisant le service Redis persistant à l'aide de Cloud SQL pour MySQL ou de BigQuery. Il nous arrive d'utiliser Redis pour agréger des données. Maintenant que nous sommes passés à Google Cloud, nous pouvons le faire simplement avec BigQuery, et les options d'analyse sont bien meilleures que celles dont nous disposions sur Redis.

Memorystore nous sert également de mutex distribué. Nous ne voulons pas que certaines actions soient réalisées simultanément dans notre système. Par exemple, nous ne voulons pas que deux administrateurs tentent de migrer les données associées à un événement spécifique au même moment. Si la migration de ces données s'effectuait de manière simultanée, notre système pourrait en être affecté. Nous utilisons donc un verrou mutex entre les différents processus pour nous assurer qu'ils ont lieu de façon consécutive, et non simultanée. 

Memorystore et Redis : une combinaison gagnante

Depuis notre migration, nous n'avons pas rencontré de problème avec Redis. Nous sommes ravis des fonctionnalités de contrôle prêtes à l'emploi de Memorystore. Lorsque nous déployons une nouvelle fonctionnalité, nous pouvons facilement vérifier si elle remplit subitement le cache, ou si notre taux de succès est très bas (ce qui indiquerait une erreur de mise en œuvre de notre part).

Autre avantage de Memorystore : son interface fonctionne exactement comme si l'on communiquait directement avec Redis. Nous utilisons le service Redis standard dans un conteneur Docker dans nos environnements de développement. Ainsi, lorsque nous l'exécutons localement, nous pouvons facilement vérifier que notre code de mise en cache se comporte comme prévu.

Nous disposons d'un environnement de production et d'un environnement de préproduction, et de deux clouds privés virtuels. Chacun d'eux bénéficie de son propre cluster Memorystore. Nous avons également des tests unitaires qui n'entrent jamais vraiment en contact avec Redis, ainsi que des tests d'intégration qui communiquent avec un serveur MySQL local et un service Redis, l'un comme l'autre situé dans Docker. Nous possédons aussi des tests de validation, c'est-à-dire des tests automatiques du navigateur qui s'exécutent dans l'environnement de préproduction. Ils communiquent avec Cloud SQL et Memorystore.

Aller plus loin avec Memorystore

En prévision d'un éventuel cas d'utilisation futur de Memorystore, nous allons sans doute ajouter Pub/Sub à notre infrastructure. Nous utiliserons Redis pour dupliquer des messages provenant de Pub/Sub (pour éviter d'envoyer le même e-mail deux fois de suite, par exemple). Nous sommes impatients de découvrir les services entièrement gérés de Pub/Sub. En effet, nous exécutons actuellement RabbitMQ, et nous sommes fréquemment amenés à le déboguer. Nous avons testé Pub/Sub dans les mêmes circonstances, et il s'est révélé très efficace. Cette fois encore, nous n'avons pas eu de mal à prendre une décision.

Memorystore fait partie des solutions cloud de données de Google que nous utilisons au quotidien. Nous employons aussi Cloud SQL, BigQuery et Dataflow pour un pipeline ELT, l'entreposage de données et nos produits d'analyse. Nous agrégeons ensuite les données qui intéressent l'artiste, nous les transmettons à MySQL, puis nous les faisons apparaître dans nos produits destinés aux artistes. Lorsque nous aurons intégré Pub/Sub, nous disposerons de presque tous les types de bases de données Google Cloud possibles. Cela prouve à quel point nous apprécions les outils Google Cloud !

Pour en savoir plus sur les services et les produits pour la musique de Songkick, cliquez ici. Vous souhaitez en savoir plus sur Memorystore ? Consultez le blog Google Cloud et découvrez nos bonnes pratiques de réglage des performances pour Memorystore pour Redis.