Telemetriedaten in Echtzeit erfassen mit NATS auf Scaleway

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Stellen wir uns folgendes Szenario vor: Ein Automobilhersteller möchte seine neue Fahrzeugflotte mit IoT-Sensoren ausstatten, die Position (GPS), Geschwindigkeit, Ladezustand und Drehmoment der Fahrzeuge in Echtzeit ermitteln.

Ziel ist eine cloud-native Anwendung, die die von den Sensoren erfassten Telemetriedaten in einem zentralen Datenspeicher zusammenführt, um den Fahrzeugzustand in Echtzeit visualisieren und analysieren zu können.

In diesem technischen Beitrag gehen wir den gesamten Entwurfsprozess durch – von der Bestimmung der nötigen Cloud-Ressourcen bis zur Architekturskizze – und adressieren dabei zentrale Herausforderungen verteilter Anwendungen wie Skalierbarkeit und Zuverlässigkeit.

Einige Rahmenbedingungen

Damit es spannender wird, definieren wir einige Rahmenbedingungen, die das System berücksichtigen muss:

• Die Sensoren sind eingebettete IoT-Geräte mit sehr begrenzten CPU- und Speicherressourcen.

• Die auf den Sensoren installierte Software startet automatisch beim Anlassen des Fahrzeugs und läuft, bis das Fahrzeug abgeschaltet wird.

• Jeder Sensor arbeitet unabhängig von den anderen, das heißt, die Abtastrate (also wie oft pro Sekunde ein Signal erzeugt wird) kann sich zwischen den Sensoren deutlich unterscheiden.

• Die Kommunikation vom Fahrzeug in die Cloud muss sicher und ausfallsicher sein.

• Das Protokoll zum Senden der Daten in die Cloud muss leichtgewichtig, zuverlässig und schnell sein.

• Dienste für Datenspeicherung und Visualisierung müssen vom selben europäischen Cloud-Anbieter stammen.

• Das System muss skalierbar sein, da potenziell Daten von Tausenden Fahrzeugen gleichzeitig erfasst werden.

• Die Lösung soll so wenige Cloud-Ressourcen wie möglich nutzen, um Cloud-Fußabdruck und Kosten zu minimieren.

Die Wahl der Technologien

Scaleway: mehr als nur ein EU-Anbieter für souveräne Cloud

Scaleway ist ein französischer Cloud-Anbieter, der häufig als einer der wichtigen Akteure im europäischen Markt für souveräne Cloud genannt wird. Globale Bedeutung und Marktanteil sind noch begrenzt, dürften aber künftig wachsen, da Datensouveränität für europäische Unternehmen zunehmend zur Notwendigkeit wird.

Gelobt für seine Preisgestaltung, seine Web-Konsole und seine ökologische Nachhaltigkeit, ist Scaleway eine gute Wahl für Workloads in der Cloud. Und auch wenn es nicht dieselbe Bandbreite an Diensten bietet wie die Big 3, hält es einige überraschende Schätze bereit. Eine Technologie sticht dabei besonders hervor.

Diese Technologie ist NATS (Neural Autonomic Transport System), ein cloud-natives Open-Source-Messaging-System, das auf Performance, Sicherheit und einfache Nutzung ausgelegt ist und seit 2018 als Incubating-Projekt Teil der CNCF-Landschaft ist.

Warum NATS gut passt

NATS setzt das Publish-Subscribe-Muster um: Publisher senden Nachrichten über Kommunikationskanäle, sogenannte Subjects (oder Topics), die Subscriber abonnieren können. Ein NATS-Server vermittelt die Kommunikation, indem er Nachrichten von Publishern entgegennimmt und an die passenden Subscriber ausliefert. Im Kern stellt er damit eine Datenebene für die Kommunikation zwischen Microservices in einer cloud-nativen Umgebung bereit.

Wirklich interessant ist jedoch die Breite seiner Funktionen. Hier können Sie nachlesen, wie NATS im Vergleich zu anderen verbreiteten Messaging-Technologien abschneidet: Gegenüber Kafka ist NATS deutlich schlanker, mit minimalem Infrastruktur- und Konfigurationsaufwand, und sein cloud-natives Design verschafft ihm einen Vorteil gegenüber MQTT, wo Skalierbarkeit und hoher Durchsatz gefragt sind.

Im nächsten Abschnitt betrachten wir, welche zentrale Rolle die folgenden NATS-Funktionen in der Architektur dieser Anwendung spielen:

• Wildcards

• Queue Groups

• JetStream

• Key/Value Store

Scaleway stellt gemanagte NATS-Accounts (also Server) direkt bereit. Aufwendige Installationen und Konfigurationen entfallen – Dienst bereitstellen und loslegen!

Welche weiteren Ressourcen brauchen wir?

Als Nächstes benötigen wir eine Compute-Plattform für die Subscriber-Workloads. Cloud-native Anwendungen drehen sich typischerweise darum, Container zu bauen und auf Kubernetes zu betreiben. Scaleway bietet gemanagte Kubernetes-Cluster unter dem Namen Kubernetes Kapsule. Beim Anlegen eines Kapsule-Clusters wählen Sie den Node-Typ für Ihren Node Pool und aktivieren bei Bedarf Funktionen wie Autoscaling, Autohealing und Node Isolation.

Für die Datenbank stehen bei Scaleway mehrere Optionen zur Verfügung. Interessant ist Serverless SQL Database, ein vollständig serverloser Datenbankdienst für PostgreSQL, der Speicher- und Rechenressourcen automatisch an Ihre Workloads anpasst.

Verglichen mit klassischeren Optionen wie Scaleways Managed Database for PostgreSQL and MySQL, die unabhängig von der Nutzung einen festen Betrag berechnet, zahlen Sie bei Serverless SQL nur für die tatsächliche Nutzung. Wenn Sie weniger als zwei Stunden am Tag aktiv Daten abfragen oder schreiben, sparen Sie gegenüber der gemanagten Lösung über 80 %!

Selbstverständlich brauchen wir auch einen Dienst zur Datenvisualisierung. Eine der führenden Lösungen ist Grafana, das PostgreSQL nativ unterstützt. Wir können einen Grafana-Container im selben Kubernetes-Cluster wie die NATS-Subscriber betreiben und uns so zusätzliche Infrastruktur sparen.

Schließlich wollen wir die Zugangsdaten für Datenbank und NATS-Server sicher ablegen. Dafür bietet Scaleway den Secret Manager, einen gemanagten, sicheren Speicherdienst für sensible Daten wie Passwörter und API-Schlüssel.

Zusammenfassung der benötigten Technologien

Clientseite

• Eigenes C-Programm, lokal per Skript ausgeführt (dies ist der verwendete offizielle NATS-C-Client)

Serverseite

• Scaleway NATS-Account

• Scaleway Kubernetes Kapsule

Datenspeicherung und Visualisierung

• Scaleway Serverless SQL Database

• Grafana-Pod im Kubernetes Kapsule

Verwaltung der Zugangsdaten

• Scaleway Secret Manager

All diese Ressourcen werden über Terraform angelegt, aktualisiert und am Ende wieder entfernt.

Die Architektur entwerfen

Da sich die Architektur um NATS dreht, besteht die erste Entwurfsfrage darin, wie Publisher und Subscriber verbunden werden. Ziel ist es, dass Subscriber große Nachrichtenmengen effizient verarbeiten – zumal ihre Skalierung in der Cloud die Kosten schnell in die Höhe treiben kann.

Ansatz 1: statische Zuordnung + Fahrzeug-Discovery-Dienst

Der naheliegendste Ansatz besteht darin, jedes Fahrzeug einem bestimmten Subscriber zuzuweisen, sodass jeder Subscriber die auf den Subjects des Fahrzeugs veröffentlichten Daten eigenständig aggregieren kann.

Dieses Design erfordert einen Fahrzeug-Discovery-Dienst, der nachhält, welche Fahrzeuge aktiv sind, und sie entsprechend zuweist. Diese Komponente wäre jedoch ein Single Point of Failure und würde schnell zum Flaschenhals.

Ansatz 2: keine Zuordnung + Datenaggregationsdienst

Eine besser skalierbare Alternative besteht darin, ganz auf statische Zuordnungen zu verzichten. In NATS können Subscriber über Wildcards mehrere Subjects gleichzeitig abonnieren. Durch das Abonnement von vehicle.*.* erhalten sie sämtliche Nachrichten aller Fahrzeuge und Sensoren – ganz ohne manuelle Koordination!

Nun müssen wir dafür sorgen, dass jeder Subscriber eine eigene Teilmenge der eingehenden Nachrichten verarbeitet, damit dieselbe Nachricht nicht mehrfach bearbeitet wird. Hier kommen Queue Groups ins Spiel: Innerhalb derselben Queue Group wird jede Nachricht nur an einen zufällig ausgewählten Subscriber zugestellt. Das sorgt automatisch für Lastverteilung, Fehlertoleranz und Skalierbarkeit.

NATS lässt sich mit JetStream erweitern, das Persistenz ergänzt, sodass Nachrichten gespeichert und später erneut abgespielt werden können. Die Funktion Key/Value Store von JetStream stellt Buckets (also assoziative Arrays) bereit, in denen Clients Daten als Schlüssel-Wert-Paare ablegen können – ähnlich wie in echten Key-Value-Datenbanken wie Redis.

Subscriber können den Key/Value Store nutzen, um die Payload der empfangenen Nachrichten zu speichern (etwa vehicle.4613.speed=95). Von dort liest ein Datenaggregationsdienst periodisch die jeweils aktuellsten Sensorwerte und schreibt für jedes Fahrzeug einen mit Zeitstempel versehenen Datensatz in die PostgreSQL-Datenbank.

Und schließlich: Daten in Grafana visualisieren

Sobald der Aggregator Datensätze in die PostgreSQL-Datenbank schreibt, können wir die Zeitreihendaten über Grafana abrufen und visualisieren, indem wir den Grafana-Service-Endpunkt im Browser aufrufen.

Das folgende Beispiel zeigt ein Grafana-Dashboard mit der Geschwindigkeit eines Fahrzeugs über ein Intervall von zehn Minuten. Die Daten stammen von einem lokal ausgeführten Publisher, der den Geschwindigkeitssensor simuliert. Die Werte waren zwar zufällig erzeugt, durchliefen aber dennoch die komplette Verarbeitung des Systems und zeigen dessen Fähigkeit zur nahezu echtzeitfähigen Datenerfassung.

Wie sieht das Architekturdiagramm aus?

Das folgende Diagramm veranschaulicht die vollständige Architektur des Systems:

Quellcode und mögliche Verbesserungen

Den vollständigen Quellcode des Projekts finden Sie in diesem Repository, wo Sie im README auch tiefer in einige technische Details einsteigen können. Das Repository ist schreibgeschützt, Sie können es jedoch forken und als Ausgangspunkt für Ihre eigene Lösung nutzen.

In diesem Proof of Concept liest der Aggregator jeweils zum Beginn einer neuen Minute aus dem Bucket des Key/Value Store. Für ein reales Szenario wäre diese Frequenz vermutlich zu niedrig, da ein Fahrzeug seinen Zustand sehr schnell ändern kann – etwa beim Beschleunigen.

Sie können das Intervall verkürzen, doch unterhalb einer bestimmten Schwelle würde die aktuelle Implementierung scheitern, weil der Aggregator einen neuen Lese-Schreib-Zyklus beginnen würde, bevor der vorherige abgeschlossen ist. Eine mögliche Verbesserung wäre Multithreading in der Kernlogik des Aggregators, sodass mehrere Zyklen nebenläufig und unabhängig voneinander laufen.

Das ist natürlich nur eine von vielen möglichen Optimierungen. Sie könnten etwa Monitoring ergänzen, die Ausfallsicherheit verbessern, indem Sie Ausfallzeiten im Aggregator-Dienst abfangen, oder horizontales Autoscaling für Subscriber anhand der Zahl eingehender Nachrichten aktivieren.

Zusammenfassung

In diesem Proof of Concept sind wir von einer komplexen Aufgabenstellung ausgegangen und haben von Grund auf eine cloud-native Lösung gebaut – mit innovativen Scaleway-Diensten wie NATS. Wir haben zwei Architekturansätze betrachtet und die Vorteile herausgearbeitet, auf eine direkte Bindung zwischen Publishern und Subscribern zu verzichten. Außerdem haben wir zentrale NATS-Funktionen genauer angesehen, die diese Technologie für den Anwendungsfall besonders geeignet machen.

Ich hoffe sehr, das inspiriert Sie dazu, selbst mit Scaleway und NATS zu experimentieren. Es gibt unendlich viel zu entdecken – und Sie können Scaleway sogar noch besser machen, indem Sie sich der Open-Source-Community anschließen!