Echtzeitinformationen für Millionen von Bahnpassagieren Freie Fahrt für die DB Reisendeninformation mit Kafka Streams

Von Axel Löhn und Uwe Eisele *

Anbieter zum Thema

Täglich reisen rund 13,4 Millionen Fahrgäste mit der Deutschen Bahn. Praktisch jeder dieser Fahrgäste verlässt sich dabei auf die Reisendeninformation. Ist diese nicht zuverlässig oder konsistent über die verschiedenen Informationskanäle, kann das bei den Reisenden zu großen Ärgernissen führen. Beispiele dafür sind fehlerhafte Verspätungsprognosen oder nicht vorhandene Informationen zu Zugausfällen.

Die Deutsche Bahn hat sich zum Ziel gesetzt, ihre Kunden passgenau zu informieren, denn eine konsistente und verlässliche Information in Echtzeit ist zentraler Bestandteil des digitalen Reiserlebnisses.
Die Deutsche Bahn hat sich zum Ziel gesetzt, ihre Kunden passgenau zu informieren, denn eine konsistente und verlässliche Information in Echtzeit ist zentraler Bestandteil des digitalen Reiserlebnisses.
(Bild: Deutsche Bahn AG)

Eine konsistente und verlässliche Information in Echtzeit ist zentraler Bestandteil des digitalen Reiserlebnisses. Die Deutsche Bahn hat sich zum Ziel gesetzt, ihre Kunden passgenau zu informieren. Deshalb muss die Qualität der Reisendeninformation gesteigert werden. Im ersten Schritt ging es darum, die Reisendeninformation bei Abweichungen, konkret beim kurzfristigen Gleiswechsel und veränderter Wagenreihung, zu verbessern. Das mittelfristige Ziel bestand aus der Entwicklung eines neuen Systems, dass den Kunden jederzeit konsistente Reiseinformationen in Echtzeit zur Verfügung stellt. Diese Informationen werden den Kunden z. B. über den DB Navigator oder am Gleisanzeiger am Bahnhof angezeigt.

Das neue System, die RI-Plattform, liefert als „Single Point of Truth“ alle relevanten Informationen für die Kunden der Deutschen Bahn. Die RI-Plattform soll künftig deutschlandweit alle Reisendeninformationskanäle konsistent mit Echtzeitinformationen des öffentlichen Personenverkehrs versorgen.

Entwicklung auf der Basis von Event-Streaming

Zu Beginn des Projekts stand das Team vor der Anforderung, sehr große Datenmengen in Echtzeit zu verarbeiten, die sich aus dem täglichen Betrieb von 800.000 Fahrten in Deutschland ergeben. Bei den Daten handelt es sich u. a. um Fahrplan- und Sensordaten aus unterschiedlichen Datenquellen des DB Konzerns. Allein die Ist-Meldungen der Züge ergeben jeden Tag mehr als 1.6 Millionen Nachrichten. Dabei ist jede einzelne Nachricht kundenrelevant und muss garantiert verarbeitet werden.

Agil nach Scrum wurden während des Projektverlaufs mehrere Lösungen evaluiert, um sich der fachlichen und technischen Machbarkeit dieser Aufgabe in kleinen Schritten zu nähern. Dabei gab es zu Projektbeginn wenige Vorgaben. Die Anwendung sollte in der DB Cloud entwickelt und betrieben werden. Um die technische und organisatorische Komplexität zu reduzieren, wurde für die Implementierung der Funktionalität der Ansatz einer Microservice-Architektur gewählt. Streaming war ein weiterer Designansatz, da die Kernfunktionalität der RI-Plattform in der kontinuierlichen Verarbeitung von Echtzeitereignissen liegt.

Als Streamingtechnologie wurde anfänglich eine Kombination aus Apache Kafka und Apache Storm eingesetzt. Die Integration der unterschiedlichen Datenquellen erfolgte mit Apache Kafka während für die Verarbeitung der Nachrichten Apache Storm genutzt wurde. Allerdings zeigte sich relativ schnell, dass der Betrieb des Storm-Cluster sowie das Deployment der Storm-Anwendungen für das Projekt zu aufwendig war.

Evaluation von Kafka Streams

Als Alternative wurde deshalb die Verwendung von Kafka Streams evaluiert. Kafka Streams vereinfachte deutlich den Betrieb und den Entwicklungszyklus. Als leichtgewichtige Java-Bibliothek ermöglicht es Kafka Streams, alle Komponenten der Anwendung auf die gleiche Art und Weise zu betreiben. Mit Kafka Streams kann die Fachlichkeit effizient mittels einer intuitiven DSL für die Stream-Verarbeitung abgebildet werden.

Die Fachlichkeit der RI-Plattform bedingt, dass die Verarbeitung von Nachrichten in den meisten Fällen nur zustandsbehaftet möglich ist. Beispielsweise können in bestimmten Anwendungsfällen Entscheidungen nur getroffen werden, wenn die vollständige Historie einer Fahrt bekannt ist. Dieser für die Verarbeitung relevante Zustand wurde anfänglich in einer externen Datenbank verwaltet. Hierbei besteht eine Eins-zu-Eins-Beziehung: Eine Datenbank gehört immer genau zu einer Kafka-Streams-Anwendung, die darin ein auf ihre Verarbeitung optimal zugeschnittenes Modell pflegt. Nachteil an dieser Lösung ist jedoch, dass die Datenbank schnell zu einem Bottleneck werden kann.

Kafka Streams ermöglicht es mit dem Konzept der „Local State Stores“ eine zustandsbehaftete Verarbeitung vollständig, ohne den Einsatz einer externen Datenbank, durchzuführen. Ein „Local State Store“ wird durch eine leichtgewichtige Key/Value-Datenbank abgebildet, die innerhalb der Anwendung selbst läuft und aus Gründen der Ausfallsicherheit in einem Kafka-Topic persistiert wird. Mit diesem Ansatz konnte beispielsweise die Performance des Services zur Versorgung der Gleisansagen signifikant verbessert werden. Die Verarbeitung des täglichen Fahrplanimports reduzierte sich dabei um den Faktor 10 und benötigt aktuell nur noch zwei Minuten. Dieses Beispiel zeigt, dass Kafka Streams in Verbindung mit „Local State Stores“ ein vielversprechender Ansatz ist, der in Zukunft auf weitere Microservices angewendet werden soll.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Big Data, Analytics & AI

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Apache Kafka ist zentraler Bestandteil der neuen Architektur.
Apache Kafka ist zentraler Bestandteil der neuen Architektur.
(Bild: Deutsche Bahn AG)

Hilfreich für die Optimierung des Betriebs von Apache Kafka war die Einführung der Confluent-Platform und der damit einhergehende Enterprise-Support von Confluent. In enger Zusammenarbeit mit Confluent und deren Partner Novatec wurden die Anforderungen im Rahmen eines Health-Check-Engagements diskutiert und darauf basierend eine Konfiguration mit dem Schwerpunkt auf „Durabililty“ und „Hochverfügbarkeit“ ermittelt. Diese Konfiguration ermöglicht bis heute auf allen Projektumgebungen einen stabilen und zuverlässigen Betrieb.

Der Entwicklungs- und Betriebsansatz der RI-Plattform

Das Projektteam der RI-Plattform besteht aus rund 100 Mitarbeitern, die in elf Scrum-Teams organisiert sind. Nach dem Ansatz „You build it, you run it“ entwickelt und betreibt das Projektteam die Anwendung nach dem DevOps-Modell selbst.

Die Teams haben während der Projektlaufzeit rund 100 Microservices programmiert, die die Confluent-Platform als Streaming-Plattform nutzen, um Ereignisse untereinander auszutauschen. Dabei werden durch die Microservices täglich in der RI-Plattform rund 180 Millionen Events generiert und verarbeitet.

Zur fortlaufenden Qualitätssicherung der Microservices setzt das Testteam der RI-Plattform ein eigenes automatisiertes Framework mit etwa drei Millionen Testfällen ein. Das Framework und die Anzahl der Testfälle werden stetig erweitert. Nahezu jeden Tag liefern die Teams in Zusammenarbeit mit dem Testteam vier bis acht Änderungen in die Produktion.

Im Projekt werden nur Open-Source-Produkte verwendet. Die zentralen Technologien für die RI-Plattform sind Apache Kafka, Apache Cassandra und Rancher/Kubernetes und für die Anbindung externer Schnittstellenpartner RabbitMQ. Die Komponenten der Anwendung sind in der DB Cloud hochverfügbar über drei Rechenzentren verteilt.

Beschleunigtes Deployment und Bereitstellung neuer Funktionen

Eine Kernanforderung an die RI-Plattform war unter anderem eine kurze „Time to Market“ für neue Features. Mit der Confluent-Platform lassen sich neue Funktionen und sogar Schnittstellen im laufenden Betrieb unterbrechungsfrei bereitstellen. Je nach Business Case werden dafür die notwendigen Nachrichten in Kafka mit der entsprechenden Aufbewahrungsdauer bereitgestellt. In der RI-Plattform beträgt diese maximal vier Tage. Ein neuer Service kann somit direkt operativ eingesetzt werden, da er sofort auf die persistenten Daten in Kafka zugreifen und neue Informationen direkt verarbeiten kann. Damit erfüllt die RI-Plattform nicht nur ihre Mission, eine einzige, branchenübergreifende, aktuelle und konsistente Informationsquelle bereitzustellen, sondern etabliert sich als schnelle „Enablerin“ neuer Features für die Reisendeninformation.

99,9 % Verfügbarkeit und ein Blick in die Zukunft

Die RI-Plattform ist seit August 2018 im produktiven Einsatz und versorgt in einer Pilotphase ca. 80 Bahnhöfe in drei Regionen (Sachsen, Regensburg und Göttingen) in Deutschland mit Daten. Diese Echtzeitinformationen werden visuell und akustisch kunden- und marktgerecht durch das neue System IRIS+ von DB Station&Service aufbereitet und ausgeben, um den Reisenden noch verständlicher den Weg zu bereiten. Dazu werden an den Anzeigern u. a. neue Informationen wie ein detaillierter Wagenstand angezeigt.

Die Pilotphase wurde Anfang September 2019 erfolgreich abgeschlossen und der deutschlandweite Rollout gestartet. Die Einführung von IRIS+ mit Echtzeitinformationen aus der RI-Plattform erfolgt sukzessive, d. h. jeder Bahnhof wird einzeln auf die neuen IT-Systeme umgestellt. Teilweise werden auch neue Zuganzeiger an den Bahnsteigen mit deutlich verbesserter Auflösung installiert.

Die Einführungsphase des neuen Systems verlief insgesamt reibungslos und seit eineinhalb Jahren arbeitet die RI-Plattform sehr stabil und hat eine Verfügbarkeit der Reisendeninformation von mehr als 99,9 % ermöglicht. Apache Kafka und die Confluent-Platform sind hierbei ebenfalls absolut zuverlässig im Einsatz. Erfahrungsgemäß ist bei einem Vorhaben dieser Größenordnung ein solches Niveau an Robustheit und Zuverlässigkeit nicht einfach von Beginn an zu erreichen. Um diese beiden Eigenschaften noch weiter zu steigern, steht ein hoher Grad an Automatisierung und selbstheilenden Fähigkeiten der Anwendung stets im Fokus.

Weitere Funktionalitäten geplant

Darüber hinaus wird die RI-Plattform fortlaufend fachlich und technisch schrittweise um neue Funktionalitäten ergänzt. Aus den existierenden Daten soll immer mehr Nutzen für die Kunden generiert werden. Gegenwärtig verarbeitet das System die Daten des Regional- und Fernverkehrs in Deutschland. Im Verlauf des Rollouts versorgen wir zukünftig weitere Mobilitätsanbieter mit Echtzeitinformation durch die RI-Plattform. In der Endausbaustufe bedeutet dieses für die RI-Plattform eine Erhöhung der zu verarbeitenden Fahrten um den Faktor 20.

Auch die Verwendung der Confluent-Cloud und damit die Nutzung von „Kafka as a Service“ ist bei der RI-Plattform ein Thema zur technischen Optimierung der Infrastruktur. Ein „Proof of Concept“ für den Einsatz der Confluent-Cloud ist in Planung.

Insgesamt betrachtet war die Entwicklung des neuen Systems unter anderem durch den Einsatz der unterschiedlichen Technologien und Arbeitsweisen ein sehr komplexes Vorhaben.

Das Ergebnis der geleistesten Arbeit ist dabei für alle Projektmitarbeiter an den bereits umgestellten Bahnhöfen (z. B. in Leipzig) sichtbar. Für die Reisenden wird die RI-Plattform das tägliche Reiseerlebnis in Deutschland verbessern, da die Konsistenz der Information mit fortschreitendem Rollout an den Bahnhöfen immer weiter zunimmt.

* Axel Löhn ist Senior Projektleiter für individuelle Softwarelösungen im Bereich Reisendeninformation bei der Deutschen Bahn. Uwe Eisele ist seit 2011 bei der Novatec Consulting GmbH als Software-Entwickler und Berater mit den Schwerpunkten Event Streaming und Event-getriebene Architekturen sowie Integration tätig.

(ID:46574411)