En Spicy Mango, nos esforzamos continuamente por mejorar nuestros productos para satisfacer las necesidades cambiantes de nuestros clientes. Nuestra plataforma de datos deportivos, Gameday, siempre ha destacado en la ingesta, transformación y distribución de datos deportivos a empresas a través de APIs REST y webhooks. Sin embargo, a medida que crecía la demanda de actualizaciones deportivas en tiempo real para aplicaciones directas al consumidor (D2C), reconocimos la necesidad de una solución escalable y de baja latencia. Esto nos llevó a explorar mecanismos de publicación/suscripción (pub/sub) basados en WebSocket para distribuir eficientemente actualizaciones en directo, como goles marcados o la posición de un coche/moto de carreras, a millones de clientes conectados.

En este artículo, te explicaremos:

• La evaluación de las tecnologías Websocket

• El trabajo que realizamos para la incorporación y la fase de pruebas

• Los argumentos para optar por el cambio a nuestra propia implementación de Websocket

• Los desafíos asociados y los beneficios que ha aportado

La necesidad de una capacidad D2C dedicada basada en WebSocket

Los aficionados al deporte esperan actualizaciones instantáneas. La latencia ya no se mide en segundos, sino en milisegundos. Nuestros métodos de distribución existentes (APIs REST y webhooks) son excelentes para el intercambio de datos estructurados, pero no están diseñados para actualizaciones push en tiempo real a gran escala. Los WebSockets, por otro lado, proporcionan un canal de comunicación bidireccional y persistente, lo que los hace ideales para ofrecer actualizaciones instantáneas a millones de clientes en todo el mundo.

Para respaldar esta transición, evaluamos múltiples enfoques, incluidos protocolos listos para usar como MQTT, antes de desarrollar finalmente nuestra propia solución pub/sub basada en WebSocket en Node.js.

Probar MQTT: una solución potente pero inadecuada

MQTT es un protocolo de publicación-suscripción consolidado, ampliamente utilizado en aplicaciones de IoT y mensajería en tiempo real. Sobre el papel, parecía un candidato sólido para nuestras necesidades. Soporta entornos de bajo ancho de banda, tiene niveles integrados de calidad de servicio (QoS) y facilita un enrutamiento de mensajes eficiente. Sin embargo, durante nuestra prueba, nos encontramos con varios desafíos que complicaron su uso para el caso de uso D2C de Gameday.

1. Configuración y gestión complejas a gran escala

   1. Desplegar MQTT a escala resultó ser engorroso. Gestionar múltiples instancias de bróker, garantizar una alta disponibilidad y escalar dinámicamente en respuesta a picos de tráfico requirió un esfuerzo operativo significativo. Nuestro equipo de DevOps tuvo que invertir tiempo en ajustar configuraciones, gestionar clústeres y optimizar el equilibrio de carga, lo que añadió una sobrecarga innecesaria.

   2. También investigamos soluciones gestionadas de terceros, como HiveMQ, en lugar de gestionar nuestras propias instancias de Mosquitto. Sin embargo, el coste a gran escala la convirtió rápidamente en una opción inviable para nuestras necesidades.

      
      

2. Dificultad de monitorización e informes

   1. Aunque MQTT admite el seguimiento y el registro de mensajes, depende en gran medida de los propios mensajes MQTT para la monitorización. Los brókeres MQTT suelen utilizar temas especiales, como el tema $SYS, para publicar el estado interno y las métricas. Monitorizar estos brókeres implica suscribirse a estos temas para recopilar información sobre la salud y la actividad del bróker. Este enfoque significa que las herramientas de monitorización deben actuar como clientes MQTT, suscribiéndose a estos temas internos para recopilar métricas, lo que puede añadir complejidad a la configuración de la monitorización. Aunque este método es eficaz dentro del ecosistema MQTT, es posible que no se integre de forma nativa con sistemas de monitorización externos que esperan métricas a través de protocolos estándar como HTTP. Esto hizo que los informes en tiempo real, la depuración y las analíticas fueran más difíciles de lo previsto. Necesitábamos un sistema que proporcionara una observabilidad más profunda de la salud de las conexiones, las tasas de éxito en la entrega y las métricas de latencia, características que eran complejas de implementar o que no estaban disponibles de forma nativa en MQTT.

      
      

3. Falta de flexibilidad en autenticación y autorización

   1. Uno de los inconvenientes más críticos fue la inflexibilidad en la gestión de la autenticación y la autorización. Los brókeres MQTT ofrecen mecanismos de autenticación, pero implementar un control de acceso detallado para diferentes clases de usuarios (como diferenciar entre suscriptores premium y de nivel gratuito) resultó complejo. Además, nuestra dependencia de plugins de terceros dentro de Mosquitto nos hacía sentir incómodos, ya que introducía una dependencia externa sobre la que teníamos un control limitado. Por otra parte, observamos una disminución del rendimiento ya que nuestros complejos requisitos de autenticación y autorización requerían descargar y delegar estos procesos a un servicio independiente desarrollado y mantenido por Spicy Mango. Esto añadió latencia y complejidad innecesarias, reforzando nuestra decisión de buscar una solución más integrada y eficiente.

      
      

4. No alineado con nuestra pila de desarrollo

   1. Aunque MQTT es robusto, su ecosistema está orientado principalmente al IoT y a aplicaciones industriales, a menudo con brókeres escritos en lenguajes como C (Mosquitto), Erlang (emqttd) o Java (Moquette). Nuestro equipo de ingeniería trabaja principalmente con Node.js para el desarrollo del backend, y mantener una solución MQTT requería introducir una nueva tecnología en nuestra pila o depender de brókeres de terceros, ninguna de las cuales era ideal para la mantenibilidad a largo plazo.

      
      

5. Sobrecarga innecesaria para nuestro caso de uso

   1. MQTT está diseñado para un amplio conjunto de casos de uso de mensajería en tiempo real, incluidos aquellos con dispositivos limitados y redes poco fiables. Aunque sobresale en esos escenarios, nuestro objetivo principal era la distribución eficiente y escalable en tiempo real de metadatos deportivos a través de conexiones estables a Internet. Las características adicionales de MQTT, como la retención de mensajes y la gestión compleja de QoS, añadían una sobrecarga y una complejidad innecesarias a nuestra infraestructura sin proporcionar beneficios proporcionales.

Desarrollo de nuestra propia solución Pub/Sub basada en WebSocket

Tras evaluar minuciosamente MQTT, tomamos la decisión estratégica de crear nuestro propio sistema pub/sub basado en WebSocket utilizando Node.js. Esta decisión nos permitió optimizar para nuestras necesidades específicas manteniendo nuestra pila tecnológica coherente y fácil de mantener. He aquí por qué nuestra solución interna demostró ser la elección correcta:

1. Integración perfecta con la arquitectura existente de Gameday

   1. Nuestra plataforma ya funciona con Node.js, lo que facilitó el desarrollo de un servicio WebSocket que se integra perfectamente con nuestros microservicios existentes. Esto redujo el tiempo de incorporación de nuestros ingenieros y simplificó el mantenimiento continuo.

      
      

2. Ligero y optimizado para metadatos deportivos

   1. Al controlar la implementación, pudimos optimizar las estructuras de los mensajes y los tamaños de las cargas de pago para los datos deportivos. A diferencia de MQTT, que admite varios niveles de QoS que no requeríamos, nuestra solución WebSocket ofrece actualizaciones con una sobrecarga de procesamiento mínima.

      
      

3. Escalable y más fácil de gestionar

   1. Con nuestra propia solución, pudimos aprovechar los servicios de AWS, como Elastic Load Balancing y las funciones de escalado automático, para garantizar un escalado fluido. Creamos herramientas de monitorización adaptadas a nuestras necesidades, generamos información en tiempo real sobre la estabilidad de las conexiones, los suscriptores activos y los tiempos de entrega de mensajes, y también nos integramos con nuestro marco de registro estándar.

      
      

4. Autenticación y autorización personalizadas

   1. La seguridad era una preocupación primordial, y nuestra solución a medida nos permitió implementar controles granulares de autenticación y autorización. Nuestro sistema de autenticación y autorización está impulsado por AuthIDConnect, una solución desarrollada por Spicy Mango. AuthIDConnect admite que los usuarios registrados inicien sesión mediante contraseñas o TOTP, emitiendo tokens de acceso de corta duración y tokens de actualización de larga duración (ambos JWT firmados). Los usuarios pueden actualizar sus tokens de acceso utilizando el token de actualización, manteniendo un acceso seguro y continuo. El token de acceso contiene declaraciones (claims) que definen las autorizaciones del usuario.

   2. AuthIDConnect también admite usuarios anónimos, una característica crucial para las empresas de terceros que integran los metadatos deportivos de Gameday en sus propias soluciones. En este modelo, cuando un usuario final anónimo está autorizado a utilizar el servicio de terceros, la solicitud de autenticación es enviada por el tercero a AuthIDConnect con un ID de sesión. A continuación, AuthIDConnect emite un token de acceso anónimo firmado que contiene el ID de sesión, el cual utiliza el usuario final para autenticar y autorizar su acceso a las APIs de Gameday y al servicio pub/sub de WebSocket.

   3. Nuestra solución WebSocket está diseñada para validar estos tokens de manera eficiente y rápida, garantizando una latencia mínima y una experiencia perfecta para todos los clientes conectados.

      
      

5. Menor complejidad de la infraestructura

   1. Al evitar una capa de protocolo adicional, eliminamos dependencias innecesarias y simplificamos la sobrecarga operativa. Nuestro servicio WebSocket se encuentra dentro de nuestra infraestructura de AWS existente, lo que reduce la necesidad de mantenimiento adicional y dependencias de terceros.

      
      

6. Cumplir con los pilares de un marco bien diseñado (Well-Architected Framework)

   1. Nuestra solución se alinea con los pilares clave del Well-Architected Framework de AWS:

      1. Excelencia operativa: Gestión y monitorización simplificadas con herramientas de observabilidad personalizadas.

      2. Seguridad: Autenticación y autorización detalladas para controlar el acceso y evitar la exposición no autorizada de datos.

      3. Fiabilidad: El escalado automático de AWS y las APIs de WebSocket gestionadas garantizan una alta disponibilidad y resiliencia.

      4. Eficiencia del rendimiento: La sobrecarga de procesamiento mínima y las estructuras de mensajes optimizadas mejoran la latencia y los tiempos de respuesta.

      5. Optimización de costes: La eliminación de dependencias de terceros reduce los costes de licencia y la sobrecarga de infraestructura.

      6. Sostenibilidad: La menor complejidad operativa y el uso eficiente de los recursos ayudan a mantener una arquitectura sostenible.

Una vista a 10.000 pies

A continuación se muestra una imagen de muy alto nivel de lo que creamos. Crucialmente, podemos gestionar a escala la solución de distribución de web sockets a través de múltiples zonas de disponibilidad y regiones, mientras que la autenticación y autorización se transmiten en el token de AuthIDConnect. Si queremos, podemos realizar el despliegue en un patrón de distribución