Chez Spicy Mango, nous nous efforçons continuellement d'améliorer nos produits pour répondre aux besoins changeants de nos clients. Notre plateforme de données sportives, Gameday, a toujours excellé dans l'ingestion, la transformation et la distribution de données sportives aux entreprises via des API REST et des webhooks. Cependant, face à la demande croissante de mises à jour sportives en temps réel pour les applications destinées directement aux consommateurs (D2C), nous avons reconnu la nécessité d'une solution évolutive à faible latence. Cela nous a amenés à explorer les mécanismes de pub/sub basés sur WebSocket afin de distribuer efficacement les mises à jour en direct, telles que les buts marqués ou la position des voitures/motos de course, à des millions de clients connectés.

Dans cet article, nous vous présenterons :

• L'évaluation des technologies Websocket

• Le travail que nous avons accompli pour l'intégration et les essais

• Les raisons qui nous ont poussés à passer à notre propre implémentation Websocket

• Les défis associés et les avantages que cela a apportés

La nécessité d'une capacité D2C dédiée basée sur WebSocket

Les fans de sport s'attendent à des mises à jour instantanées. La latence ne se mesure plus en secondes mais en millisecondes. Nos méthodes de distribution existantes - API REST et webhooks - sont excellentes pour l'échange de données structurées mais ne sont pas conçues pour des mises à jour push en temps réel à grande échelle. Les WebSockets, quant à eux, offrent un canal de communication bidirectionnel persistant, ce qui les rend idéaux pour fournir des mises à jour instantanées à des millions de clients à travers le monde.

Pour accompagner cette transition, nous avons évalué plusieurs approches, y compris des protocoles prêts à l'emploi comme MQTT, avant de développer notre propre solution pub/sub basée sur WebSocket en Node.js.

Essai de MQTT : une solution puissante mais inadaptée

MQTT est un protocole de publication-abonnement bien établi, largement utilisé dans les applications IoT et la messagerie en temps réel. Sur le papier, il semblait être un candidat solide pour nos besoins. Il prend en charge les environnements à faible bande passante, intègre des niveaux de qualité de service (QoS) et facilite un routage efficace des messages. Cependant, lors de nos essais, nous avons été confrontés à plusieurs difficultés qui l'ont rendu inadapté au cas d'utilisation D2C de Gameday.

1. Configuration et gestion complexes à grande échelle

   1. Le déploiement de MQTT à grande échelle s'est avéré fastidieux. Gérer plusieurs instances de brokers, garantir une haute disponibilité et monter en charge de manière dynamique en réponse aux pics de trafic a nécessité un effort opérationnel important. Notre équipe DevOps a dû investir du temps dans l'ajustement des configurations, la gestion des clusters et l'optimisation de la répartition de charge, ce qui a généré une surcharge de travail inutile.

   2. Nous avons également étudié des solutions gérées par des tiers, comme HiveMQ, au lieu de gérer nos propres instances Mosquitto. Cependant, le coût à grande échelle en a rapidement fait une option non viable pour nos besoins.

      
      

2. Suivi et rapports difficiles

   1. Bien que MQTT prenne en charge le suivi et la journalisation des messages, il repose fortement sur les messages MQTT eux-mêmes pour la surveillance. Les brokers MQTT utilisent souvent des sujets spéciaux, comme le sujet $SYS, pour publier l'état et les métriques internes. La surveillance de ces brokers implique de s'abonner à ces sujets pour recueillir des informations sur la santé et l'activité du broker. Cette approche signifie que les outils de surveillance doivent agir en tant que clients MQTT, s'abonnant à ces sujets internes pour collecter des métriques, ce qui peut complexifier la configuration de la surveillance. Bien que cette méthode soit efficace au sein de l'écosystème MQTT, elle peut ne pas s'intégrer de manière transparente avec des systèmes de surveillance externes qui attendent des métriques via des protocoles standard comme HTTP. Cela a rendu les rapports en temps réel, le débogage et les analyses plus difficiles que prévu. Nous avions besoin d'un système offrant une observabilité plus approfondie de la santé des connexions, des taux de réussite de livraison et des métriques de latence - des fonctionnalités qui étaient soit complexes à mettre en œuvre, soit non disponibles nativement dans MQTT.

      
      

3. Manque de flexibilité dans l'authentification et l'autorisation

   1. L'un des inconvénients les plus critiques était le manque de flexibilité dans la gestion de l'authentification et de l'autorisation. Les brokers MQTT proposent des mécanismes d'authentification, mais la mise en œuvre d'un contrôle d'accès précis pour différentes catégories d'utilisateurs - comme la distinction entre les abonnés premium et les abonnés gratuits - s'est avérée complexe. De plus, notre dépendance à l'égard de plugins tiers au sein de Mosquitto nous mettait mal à l'aise, car elle introduisait une dépendance externe sur laquelle nous n'avions qu'un contrôle limité. En outre, nous avons constaté une baisse des performances, car nos exigences complexes en matière d'authentification et d'autorisation nécessitaient de décharger et de relayer ces processus vers un service distinct développé et maintenu par Spicy Mango. Cela a ajouté une latence et une complexité inutiles, renforçant notre décision de rechercher une solution plus intégrée et plus efficace.

      
      

4. Non aligné avec notre pile de développement

   1. Bien que MQTT soit robuste, son écosystème est principalement orienté vers l'IoT et les applications industrielles, avec des brokers souvent écrits dans des langages comme C (Mosquitto), Erlang (emqttd) ou Java (Moquette). Notre équipe d'ingénierie travaille principalement avec Node.js pour le développement backend, et le maintien d'une solution MQTT nécessitait soit d'introduire une nouvelle technologie dans notre pile, soit de s'en remettre à des brokers tiers, ce qui n'était pas idéal pour la maintenabilité à long terme.

      
      

5. Surcharge inutile pour notre cas d'utilisation

   1. MQTT est conçu pour un large éventail de cas d'utilisation de messagerie en temps réel, y compris ceux impliquant des appareils limités et des réseaux peu fiables. Bien qu'il excelle dans ces scénarios, notre objectif principal était la distribution efficace et évolutive en temps réel de métadonnées sportives sur des connexions Internet stables. Les fonctionnalités supplémentaires de MQTT, telles que la rétention des messages et la gestion complexe de la QoS, ont ajouté une surcharge et une complexité inutiles à notre infrastructure sans apporter de bénéfices proportionnels.

Développement de notre propre solution Pub/Sub basée sur WebSocket

Après avoir évalué minutieusement MQTT, nous avons pris la décision stratégique de construire notre propre système pub/sub basé sur WebSocket à l'aide de Node.js. Cette décision nous a permis d'optimiser le système pour nos besoins spécifiques tout en maintenant notre pile technologique cohérente et facile à entretenir. Voici pourquoi notre solution interne s'est avérée être le bon choix :

1. Intégration transparente avec l'architecture existante de Gameday

   1. Notre plateforme fonctionne déjà sous Node.js, ce qui a permis de développer facilement un service WebSocket qui s'intègre parfaitement à nos microservices existants. Cela a réduit le temps de prise en main pour nos ingénieurs et simplifié la maintenance continue.

      
      

2. Léger et optimisé pour les métadonnées sportives

   1. En contrôlant l'implémentation, nous avons pu optimiser la structure des messages et la taille des charges utiles pour les données sportives. Contrairement à MQTT, qui prend en charge différents niveaux de QoS dont nous n'avions pas besoin, notre solution WebSocket fournit des mises à jour avec un coût de traitement minimal.

      
      

3. Évolutif et plus facile à gérer

   1. Avec notre propre solution, nous pouvons exploiter les services AWS tels qu'Elastic Load Balancing et les fonctionnalités d'auto-scaling pour assurer une mise à l'échelle fluide. Nous avons conçu des outils de surveillance adaptés à nos besoins, générant des informations en temps réel sur la stabilité des connexions, les abonnés actifs et les temps de livraison des messages, tout en les intégrant à notre framework de journalisation standard.

      
      

4. Authentification et autorisation personnalisées

   1. La sécurité était une préoccupation majeure, et notre solution sur mesure nous a permis de mettre en œuvre des contrôles d'authentification et d'autorisation précis. Notre système d'authentification et d'autorisation est alimenté par AuthIDConnect, une solution développée par Spicy Mango. AuthIDConnect permet aux utilisateurs enregistrés de se connecter via des mots de passe ou un TOTP, en émettant des jetons d'accès à courte durée de vie et des jetons de rafraîchissement à longue durée de vie (tous deux des JWT signés). Les utilisateurs peuvent actualiser leurs jetons d'accès à l'aide du jeton de rafraîchissement, maintenant ainsi un accès sécurisé et continu. Le jeton d'accès contient des revendications (claims) définissant les autorisations de l'utilisateur.

   2. AuthIDConnect prend également en charge les utilisateurs anonymes, une fonctionnalité cruciale pour les entreprises tierces qui intègrent les métadonnées sportives de Gameday dans leurs propres solutions. Dans ce modèle, lorsqu'un utilisateur final anonyme est autorisé à utiliser le service tiers, la demande d'authentification est relayée par le tiers à AuthIDConnect avec un identifiant de session. AuthIDConnect émet alors un jeton d'accès anonyme signé contenant l'identifiant de session, que l'utilisateur final utilise pour s'authentifier et autoriser son accès aux API et au service pub/sub WebSocket de Gameday.

   3. Notre solution WebSocket est conçue pour valider ces jetons de manière efficace et rapide, garantissant une latence minimale et une expérience fluide pour tous les clients connectés.

      
      

5. Complexité d'infrastructure réduite

   1. En évitant une couche de protocole supplémentaire, nous avons éliminé les dépendances inutiles et simplifié la charge opérationnelle. Notre service WebSocket s'intègre dans notre infrastructure AWS existante, ce qui réduit le besoin de maintenance supplémentaire et de dépendances tierces.

      
      

6. Répondre aux piliers d'un Well-Architected Framework

   1. Notre solution s'aligne sur les piliers clés du Well-Architected Framework d'AWS :

      1. Excellence opérationnelle : Gestion et surveillance simplifiées grâce à des outils d'observabilité personnalisés.

      2. Sécurité : Authentification et autorisation précises pour contrôler l'accès et empêcher l'exposition non autorisée des données.

      3. Fiabilité : L'auto-scaling d'AWS et les API WebSocket managées garantissent une haute disponibilité et une grande résilience.

      4. Efficacité des performances : La surcharge de traitement minimale et les structures de messages optimisées améliorent la latence et les temps de réponse.

      5. Optimisation des coûts : L'élimination des dépendances tierces réduit les coûts de licence et la surcharge d'infrastructure.

      6. Durabilité : Une complexité opérationnelle réduite et une utilisation efficace des ressources contribuent à maintenir une architecture durable.

Une vue d'ensemble à 10 000 pieds

Une image (très) globale de ce que nous avons créé est présentée ci-dessous. De manière cruciale, nous pouvons gérer et mettre à l'échelle la solution de distribution WebSocket sur plusieurs zones de disponibilité et régions, tandis que l'authentification et l'autorisation sont entièrement gérées dans le jeton AuthIDConnect. Si nous le souhaitons, nous pouvons déployer un modèle de diffusion (fan-out) de serveurs d'origine et de serveurs périphériques (edge), afin de répondre à la demande dans n'importe quelle région - le tout avec la même implémentation de serveur WebSocket.

Leçons apprises et réflexions finales

Notre parcours vers une solution D2C basée sur WebSocket nous a enseigné de précieuses leçons. MQTT est un protocole puissant et polyvalent, bien adapté à l'IoT et à la communication de machine à machine. Cependant, pour les besoins spécifiques de Gameday — évolutivité, messagerie à faible latence, intégration avec notre pile Node.js et contrôles de sécurité précis — notre solution WebSocket personnalisée était la mieux adaptée.

Cette expérience a renforcé l'importance de choisir des technologies en phase avec notre expertise fondamentale et nos objectifs opérationnels. En développant notre propre solution, nous disposons désormais d'un système hautement optimisé, évolutif et sécurisé qui fournit des mises à jour de métadonnées sportives en temps réel à des millions d'utilisateurs avec une latence minimale.

Alors que Gameday continue d'évoluer, nous restons déterminés à explorer de nouvelles façons d'améliorer notre plateforme. Qu'il s'agisse d'optimiser davantage notre infrastructure WebSocket, d'intégrer l'edge computing ou de tirer parti de nouvelles technologies cloud, notre objectif reste le même : fournir la meilleure expérience possible en matière de données sportives en temps réel.