Sync Motion Logo
Serverschränke in einem Rechenzentrum

FORSCHUNG & EINBLICKE · BACHELORARBEIT

Über den ersten Einsatz hinaus denken

Entdecke, was möglich ist

Architektur, die mit den Standorten wächst

Ein einzelner Standort mit einem Broker ist schnell angebunden. Schwieriger wird es, wenn Sensoren an vielen Orten über unzuverlässige Netze an ein zentrales Backend liefern sollen. In Zusammenarbeit mit der FH JOANNEUM hat Thomas Jöbstl in seiner Bachelorarbeit untersucht, wie MQTT Broker Cluster dafür aufgebaut sein müssen, und drei Varianten einer hierarchischen Architektur gebaut und unter Last gemessen

Netzwerkkabel in den Ethernet Ports eines Routers

Eckdaten

Arbeit
BachelorarbeitFH JOANNEUM Graz2026
Autor
Thomas JöbstlWirtschaftsinformatik
Varianten
Lightweight GatewayRabbitMQ ClusterEMQX Cluster
Gemessen
DurchsatzLatenzRessourcenWAN AusfälleFehlertoleranz

Drei Fragen an eine verteilte Architektur

Wie müssen MQTT Broker Cluster strukturiert sein, damit verteilte Sensoren zuverlässig mit dem Backend kommunizieren? Worin unterscheiden sich zentrale, hierarchische und verteilte Topologien bei Skalierung, Fehlertoleranz und Latenz? Und welche Variante passt zu einem Unternehmen wie Sync Motion?

Die Antwort entstand nicht am Whiteboard. Alle drei Varianten wurden mit Mosquitto am Edge, Apache Kafka und ClickHouse im Kern aufgebaut und mit bis zu 10 000 Nachrichten pro Sekunde, gestörten Weitverkehrsnetzen und gezielten Ausfällen einzelner Komponenten getestet

Ergebnisse

Was die Messungen zeigen

  • Hierarchie bewährt sich

    Edge Broker puffern Nachrichten bei Netzausfall in allen drei Varianten, die zentrale Verteilschicht bleibt dabei einfacher zu betreiben als ein voll verteiltes System

  • Gleichauf bei moderater Last

    Bis 5 000 Nachrichten pro Sekunde verlieren alle Varianten rund ein Prozent, bis 2 000 liegt die Latenz überall bei 40 bis 70 ms im 95. Perzentil

  • Unterschiede unter Spitzenlast

    Bei 10 000 Nachrichten pro Sekunde verliert EMQX sieben Prozent, das Lightweight Gateway 13 Prozent und RabbitMQ 40 Prozent, dessen Latenz dann auf über elf Sekunden steigt

  • Resilienz im schlechten Netz

    Bei gestörtem WAN verliert RabbitMQ mit 5,7 Prozent am wenigsten, und nach einem Ausfall von 60 Sekunden liefert es den Puffer mit 0,7 Prozent Verlust am schnellsten nach

  • Ausfall eines Broker Knotens

    Beide Cluster Varianten übernehmen den Ausfall eines Knotens ohne Verlust, verwundbar bleiben einzelne Komponenten wie Load Balancer, die redundant betrieben werden müssen

  • Empfehlung für Sync Motion

    RabbitMQ als zentrale Schicht: bidirektionale Kommunikation, beste WAN Resilienz und eine offene Lizenz, mit Wachstum über mehrere unabhängige Cluster je Region

Was das für Projekte bedeutet

KERNAUSSAGE

Die Topologie entscheidet früher als die Technologie

  • Jeder Standort bekommt seinen Edge Broker

    Ein lokaler Broker hält die Anlage auch dann am Laufen, wenn die Verbindung zur Zentrale abreißt. Nachrichten werden gepuffert und nachgeliefert, statt verloren zu gehen

  • Skalierung ohne Umbau

    Neue Standorte kommen als weitere Edge Broker dazu, die Verteilschicht wächst über zusätzliche unabhängige Cluster je Region. Die Architektur bleibt dabei dieselbe

  • Messwerte statt Bauchgefühl

    Die Wahl der Broker Technologie beruht auf gemessenem Verhalten unter Last, bei Netzstörungen und bei Ausfällen. Die Zahlen fließen direkt in die Auslegung neuer Projekte ein

  • Offene Technologien, offene Zukunft

    Mosquitto, RabbitMQ, Kafka und ClickHouse sind unter offenen Lizenzen verfügbar. Kundinnen und Kunden binden sich an eine Architektur, nicht an einen Anbieter