Bei Spicy Mango sind wir kontinuierlich bestrebt, unsere Produkte zu verbessern, um den sich entwickelnden Anforderungen unserer Kunden gerecht zu werden. Unsere Sportdatenplattform, Gameday, zeichnete sich schon immer durch das Erfassen, Transformieren und Verteilen von Sportdaten an Unternehmen via REST-APIs und Webhooks aus. Da jedoch die Nachfrage nach Echtzeit-Sport-Updates für Direct-to-Consumer-Anwendungen (D2C) stieg, erkannten wir den Bedarf an einer skalierbaren Lösung mit geringer Latenz. Dies veranlasste uns, WebSocket-basierte Pub/Sub-Mechanismen zu untersuchen, um Live-Updates wie erzielte Tore oder Positionen von Rennwagen/Motorrädern effizient an Millionen verbundener Clients zu verteilen.

In diesem Artikel führen wir Sie durch:

• Evaluierung von Websocket-Technologien

• Die Arbeit, die wir für Onboarding und Erprobung geleistet haben

• Die Gründe für die Entscheidung, auf unsere eigene Websocket-Implementierung umzusteigen

• Die damit verbundenen Herausforderungen und die Vorteile, die sie gebracht hat

Der Bedarf an dedizierter WebSocket-basierter D2C-Funktionalität

Sportfans erwarten sofortige Updates. Latenz wird nicht mehr in Sekunden, sondern in Millisekunden gemessen. Unsere bestehenden Verteilungsmethoden – REST-APIs und Webhooks – eignen sich hervorragend für den strukturierten Datenaustausch, sind jedoch nicht für Echtzeit-Push-Updates im großen Maßstab ausgelegt. WebSockets hingegen bieten einen persistenten, bidirektionalen Kommunikationskanal und eignen sich daher ideal für die Bereitstellung von sofortigen Updates für Millionen von Clients weltweit.

Um diesen Übergang zu unterstützen, haben wir mehrere Ansätze evaluiert, darunter Standardprotokolle wie MQTT, bevor wir letztendlich unsere eigene WebSocket-basierte Pub/Sub-Lösung in Node.js entwickelten.

Erprobung von MQTT: Eine leistungsstarke, aber ungeeignete Lösung

MQTT ist ein bewährtes Publish-Subscribe-Protokoll, das in IoT-Anwendungen und Echtzeit-Messaging weit verbreitet ist. Auf dem Papier schien es ein starker Kandidat für unsere Anforderungen zu sein. Es unterstützt Umgebungen mit geringer Bandbreite, verfügt über integrierte Quality-of-Service-Stufen (QoS) und erleichtert ein effizientes Message Routing. Während unseres Tests stießen wir jedoch auf mehrere Herausforderungen, die den Einsatz für den D2C-Anwendungsfall von Gameday erschwerten.

1. Komplexe Konfiguration und Verwaltung im großen Maßstab

   1. Die Bereitstellung von MQTT in großem Maßstab erwies sich als mühsam. Die Verwaltung mehrerer Broker-Instanzen, die Gewährleistung hoher Verfügbarkeit und die dynamische Skalierung als Reaktion auf Datenverkehrsspitzen erforderten erheblichen operativen Aufwand. Unser DevOps-Team musste Zeit in die Feinabstimmung von Konfigurationen, das Cluster-Management und die Optimierung des Lastenausgleichs investieren, was zu unnötigem Mehraufwand führte.

   2. Wir haben auch verwaltete Drittanbieterlösungen – wie HiveMQ – untersucht, anstatt unsere eigenen Mosquitto-Instanzen zu verwalten. Die Kosten bei einer Skalierung machten dies jedoch schnell zu einer für unsere Anforderungen unrentablen Option.

      
      

2. Schwierige Überwachung und Berichterstattung

   1. Obwohl MQTT die Nachrichtenverfolgung und -protokollierung unterstützt, verlässt es sich bei der Überwachung stark auf die MQTT-Nachrichten selbst. MQTT-Broker nutzen häufig spezielle Topics, wie das Topic $SYS, um internen Status und Metriken zu veröffentlichen. Die Überwachung dieser Broker beinhaltet das Abonnieren dieser Topics, um Informationen über den Zustand und die Aktivität des Brokers zu sammeln. Dieser Ansatz bedeutet, dass Überwachungstools als MQTT-Clients fungieren müssen, die diese internen Topics abonnieren, um Metriken zu erfassen, was die Überwachungseinrichtung komplexer machen kann. Obwohl diese Methode innerhalb des MQTT-Ökosystems effektiv ist, lässt sie sich möglicherweise nicht nahtlos in externe Überwachungssysteme integrieren, die Metriken über Standardprotokolle wie HTTP erwarten. Dies machte Echtzeit-Berichte, Debugging und Analysen schwieriger als erwartet. Wir benötigten ein System, das eine tiefere Beobachtbarkeit der Verbindungsintegrität, der Zustellungsraten und der Latenzmetriken bot – Funktionen, die entweder komplex zu implementieren oder in MQTT nicht nativ verfügbar waren.

      
      

3. Mangel an flexibler Authentifizierung und Autorisierung

   1. Einer der kritischsten Nachteile war die Inflexibilität bei der Verwaltung von Authentifizierung und Autorisierung. MQTT-Broker bieten Authentifizierungsmechanismen, aber die Implementierung einer feingranularen Zugriffskontrolle für verschiedene Benutzerklassen – wie die Unterscheidung zwischen Premium- und Free-Tier-Abonnenten – erwies sich als komplex. Darüber hinaus fühlten wir uns mit unserer Abhängigkeit von Drittanbieter-Plugins innerhalb von Mosquitto unwohl, da dies eine externe Abhängigkeit einführte, über die wir nur begrenzte Kontrolle hatten. Des Weiteren stellten wir einen Leistungsabfall fest, da unsere komplexen Anforderungen an Authentifizierung und Autorisierung es erforderlich machten, diese Prozesse auf einen separaten, von Spicy Mango entwickelten und gewarteten Dienst auszulagern und per Proxy weiterzuleiten. Dies führte zu unnötiger Latenz und Komplexität und bestärkte uns in unserer Entscheidung, eine integriertere und effizientere Lösung anzustreben.

      
      

4. Nicht auf unseren Entwicklungs-Stack abgestimmt

   1. Obwohl MQTT robust ist, ist sein Ökosystem in erster Linie auf IoT- und Industrieanwendungen ausgerichtet, wobei Broker oft in Sprachen wie C (Mosquitto), Erlang (emqttd) oder Java (Moquette) geschrieben sind. Unser Engineering-Team arbeitet für die Backend-Entwicklung hauptsächlich mit Node.js, und die Wartung einer MQTT-Lösung hätte entweder die Einführung neuer Technologien in unseren Stack oder die Abhängigkeit von Brokern von Drittanbietern erfordert, was beides für die langfristige Wartbarkeit nicht ideal war.

      
      

5. Unnötiger Mehraufwand für unseren Anwendungsfall

   1. MQTT ist für eine breite Palette von Echtzeit-Messaging-Anwendungsfällen konzipiert, einschließlich solcher mit ressourcenbeschränkten Geräten und unzuverlässigen Netzwerken. Während es in diesen Szenarien hervorragend abschneidet, war unser Hauptziel die effiziente, skalierbare Echtzeitverteilung von Sport-Metadaten über stabile Internetverbindungen. Die zusätzlichen Funktionen von MQTT, wie das Behalten von Nachrichten und eine komplexe QoS-Verarbeitung, führten zu unnötigem Mehraufwand und Komplexität in unserer Infrastruktur, ohne einen proportionalen Nutzen zu bieten.

Entwicklung unserer eigenen WebSocket-basierten Pub/Sub-Lösung

Nach gründlicher Evaluierung von MQTT haben wir die strategische Entscheidung getroffen, unser eigenes WebSocket-basiertes Pub/Sub-System mit Node.js aufzubauen. Diese Entscheidung ermöglichte es uns, für unsere spezifischen Anforderungen zu optimieren und gleichzeitig unseren Technologie-Stack konsistent und wartbar zu halten. Hier ist der Grund, warum sich unsere Inhouse-Lösung als die richtige Wahl erwiesen hat:

1. Nahtlose Integration in die bestehende Architektur von Gameday

   1. Unsere Plattform läuft bereits auf Node.js, was es einfach machte, einen WebSocket-Dienst zu entwickeln, der sich nahtlos in unsere bestehenden Microservices integrieren lässt. Dies verkürzte die Einarbeitungszeit für unsere Entwickler und vereinfachte die laufende Wartung.

      
      

2. Leichtgewichtig und optimiert für Sport-Metadaten

   1. Durch die Kontrolle über die Implementierung konnten wir Nachrichtenstrukturen und Payload-Größen für Sportdaten optimieren. Im Gegensatz zu MQTT, das verschiedene QoS-Stufen unterstützt, die wir nicht benötigten, liefert unsere WebSocket-Lösung Updates mit minimalem Verarbeitungsaufwand.

      
      

3. Skalierbar und einfacher zu verwalten

   1. Mit unserer eigenen Lösung konnten wir AWS-Services wie Elastic Load Balancing und Auto-Scaling-Funktionen nutzen, um eine reibungslose Skalierung zu gewährleisten. Wir haben auf unsere Anforderungen zugeschnittene Überwachungstools entwickelt, die Echtzeit-Erkenntnisse über die Verbindungsstabilität, aktive Abonnenten und Nachrichtenzustellungszeiten liefern und sich zudem in unser Standard-Logging-Framework integrieren lassen.

      
      

4. Benutzerdefinierte Authentifizierung und Autorisierung

   1. Sicherheit war ein wichtiges Anliegen, und unsere maßgeschneiderte Lösung ermöglichte es uns, feingranulare Authentifizierungs- und Autorisierungskontrollen zu implementieren. Unser Authentifizierungs- und Autorisierungssystem basiert auf AuthIDConnect, einer von Spicy Mango entwickelten Lösung. AuthIDConnect unterstützt die Anmeldung registrierter Benutzer über Passwörter oder TOTP und stellt kurzlebige Access-Tokens sowie langlebige Refresh-Tokens (beides signierte JWTs) aus. Benutzer können ihre Access-Tokens mithilfe des Refresh-Tokens erneuern, wodurch ein sicherer und kontinuierlicher Zugriff gewährleistet bleibt. Das Access-Token enthält Claims, die die Berechtigungen des Benutzers definieren.

   2. AuthIDConnect unterstützt auch anonyme Benutzer, eine entscheidende Funktion für Drittunternehmen, die Gameday-Sport-Metadaten in ihre eigenen Lösungen integrieren. Wenn in diesem Modell ein anonymer Endbenutzer zur Nutzung des Drittanbieter-Dienstes autorisiert ist, wird die Authentifizierungsanfrage vom Drittanbieter mit einer Sitzungs-ID per Proxy an AuthIDConnect weitergeleitet. AuthIDConnect stellt dann ein signiertes anonymes Access-Token aus, das die Sitzungs-ID enthält und mit dem sich der Endbenutzer authentifiziert und seinen Zugriff auf die APIs und den WebSocket-Pub/Sub-Dienst von Gameday autorisiert.

   3. Unsere WebSocket-Lösung ist darauf ausgelegt, diese Token effizient und schnell zu validieren, um minimale Latenzen und ein nahtloses Erlebnis für alle verbundenen Clients zu gewährleisten.

      
      

5. Reduzierte Komplexität der Infrastruktur

   1. Durch den Verzicht auf eine zusätzliche Protokollschicht haben wir unnötige Abhängigkeiten beseitigt und den operativen Aufwand vereinfacht. Unser WebSocket-Dienst ist in unsere bestehende AWS-Infrastruktur integriert, was den Bedarf an zusätzlicher Wartung und Drittanbieter-Abhängigkeiten reduziert.

      
      

6. Erfüllung der Säulen eines Well-Architected Frameworks

   1. Unsere Lösung steht im Einklang mit den Kernsäulen des Well-Architected Frameworks von AWS:

      1. Operational Excellence: Vereinfachte Verwaltung und Überwachung mit maßgeschneiderten Observability-Tools.

      2. Sicherheit: Feingranulare Authentifizierung und Autorisierung zur Zugriffskontrolle und Verhinderung unbefugter Datenoffenlegung.

      3. Zuverlässigkeit: AWS Auto-Scaling und verwaltete WebSocket-APIs gewährleisten hohe Verfügbarkeit und Ausfallsicherheit.

      4. Leistungseffizienz: Minimaler Verarbeitungsaufwand und optimierte Nachrichtenstrukturen verbessern Latenz und Antwortzeiten.

      5. Kostenoptimierung: Der Verzicht auf Abhängigkeiten von Drittanbietern reduziert Lizenzkosten und Infrastruktur-Overhead.

      6. Nachhaltigkeit: Reduzierte operative Komplexität und effiziente Ressourcennutzung tragen zur Aufrechterhaltung einer nachhaltigen Architektur bei.

Eine Ansicht aus 10.000 Fuß Höhe

Unten sehen Sie ein (sehr) vereinfachtes Bild dessen, was wir geschaffen haben. Entscheidend ist, dass wir die WebSocket-Verteilungslösung über viele Availability Zones und Regionen hinweg verwalten und skalieren können, während die Authentifizierung und Autorisierung vollständig im AuthIDConnect-Token übertragen wird. Wenn wir möchten, können wir ein Fan-Out-Muster aus Origin- und Edge-Servern bereitstellen, um die Nachfrage in jeder Region zu bedienen – und das alles mit derselben WebSocket-Server-Implementierung.

Gewonnene Erkenntnisse und abschließende Gedanken

Unser Weg zu einer WebSocket-basierten D2C-Lösung hat uns wertvolle Lektionen gelehrt. MQTT ist ein leistungsstarkes und vielseitiges Protokoll, das sich gut für IoT und Machine-to-Machine-Kommunikation eignet. Für die spezifischen Anforderungen von Gameday – Skalierbarkeit, Messaging mit geringer Latenz, Integration in unseren Node.js-Stack und feingranulare Sicherheitskontrollen – war unsere maßgeschneiderte WebSocket-Lösung jedoch die beste Wahl.

Diese Erfahrung hat uns darin bestärkt, wie wichtig es ist, Technologien auszuwählen, die zu unserer Kernkompetenz und unseren operativen Zielen passen. Durch die Entwicklung einer eigenen Lösung verfügen wir nun über ein hochgradig optimiertes, skalierbares und sicheres System, das Echtzeit-Sport-Metadaten-Updates mit minimaler Latenz an Millionen von Benutzern liefert.

Da sich Gameday kontinuierlich weiterentwickelt, setzen wir uns weiterhin dafür ein, neue Wege zur Verbesserung unserer Plattform zu finden. Ob es um die weitere Optimierung unserer WebSocket-Infrastruktur, die Einbindung von Edge Computing oder die Nutzung neuer Cloud-Technologien geht, unser Ziel bleibt dasselbe: das bestmögliche Echtzeit-Sportdatenerlebnis zu bieten.