Freie Fahrt für die Reisendeninformation mit Kafka Streams

DB Reisendeninformation

Fachliche Weiterentwicklung
der zentralen RI-Komponenten
Maßgeschneiderte
Lösungen
Betrieb einer deutschland-
weiten Datendrehscheibe
Beratung & Koordination
Kunden- und Mitarbeiterkanäle Karten-Services Daten-Services Analytic Services

6.200.000
Kunden
› 5.000
Züge
12.200
Anzeigen
› 9.500.000
Anfragen DB Navigator
800.000
Reisen
› 6.000
Bahnhöfe
>30.000
Involvierte Mitarbeiter (aus zehn
Geschäftsfeldern)
Zahlen pro Tag

Informationskanäle
• Bahn.de
• DB Navigator
• DB Bahnhof Live
• ….
• Abfahrtstafel
• Gleisanzeiger
• Störungskarten
• Karten Services
• ….
• RIS Fahrzeug
• WIFI@DB
• ….
• Betrieb Live
• RIS Infoplattform
• RIS Communicator
• …

RI-Plattform

Verbesserungen der Reisendeninformation
über drei Zeithorizonte
II. 1.2 Verbesserung der Reisendeninformation:
„Rechtzeitig und korrekt informiert, jederzeit und
überall“
Kurzfristige Verbesserungen
der Reisendeninformation
Umfassende Beseitigung der
größten Kundenärgernisse inA 2016
Informationsplattform
Reisendeninformation
Konsistente, umfassende,
modulare, diskriminierungsfreie
Informationsplattform bis Ende
B 2018
Wettbewerbsdifferenzierende
Funktionen für Transporteure
"State-of-the-art" Reisenden-
information und innovative
Reisendenbegleitung bis Ende
C 2020

Vorher
Seit 08/2018
RI-Plattform
Data RI-Plattform
(Single Point of Truth)
Data

Start
in Q2/2018 in Plauen, Vogtland
Pilotphase
Pilotphase über ein ein Jahr für ca. 80 Bahnhöfe mit
ca. 350 Anzeigern in den Regionen Sachsen,
Regensburg und Göttingen.
GO LIVE

Methoden &
Technologien

Methoden
• Agile Entwicklung nach Scrum
• Von Nexus zu eigenem, optimiertem Framework
• Betrieb nach DevOps („You build it, you run it“)
• Wöchentlicher Wissenstransfer und regelmäßige
Bootcamps
• Patenkonzept für Technologien
• Synchronisation von Technik und Versionen

Technologien
Cloudcomputing
wirtschaftliches Entwickeln und schnelles
Skalieren bei Lastspitzen
Microservices
Reduktion technischer und organisatorischer
Komplexität
Verwaltung und Orchestrierung mit Kubernetes.
Streaming (Event-driven)
Kontinuierliche Verarbeitung und Lieferung von
Datenströmen in Echtzeit

Technologien

>110 Personen mit
13 Scrum Teams 24/7
Betriebsteam
(DevOps)
Mehrmals tägliche unterbrechungsfreie
Änderungen in Produktion
Eigenes Testteam mit selbst entwickeltem
Testframework
(Simulation Bahnbetrieb mit ~ 3 MioTestfällen)
Livedatenverarbeitung
über alle Stages

Die Plattform erzeugt und
verarbeitet >60 Mio Nachrichten
pro Tag
Produktionsumgebung besteht aus
>100 virtuellen Servern in der AWS
Cloud
Die Anwendung ist
verteilt über 3 AZ
Die Teams entwickeln und testen
ca. 80 Microservices
Es finden täglich Dauerlasttests statt

Kafka als Fundament

Streaming Plattform
Data Hub „RI-Plattform“
(Single Point of Truth)
Prognose
Apache Kafka
Kundenfahrpla
n
OracleDB
Betriebsfahrpla
n
Wagenreihung
Bahnhofswisse
n
Dispositionen
Zug-Positionen
OracleAQFTPTCP
Socket
RabbitMQ
IK
Abfahrtstafel
MatcherFahrtbuilder
KonsolidierungAnalyse
IK
Gleisansagen
IK Prognose
IK VDV

Verarbeitung von Daten des
gesamten öffentlichen
Personenverkehr in Deutschland in
Echtzeit
Flexibles hinzufügen neuer Features
durch Entwicklung neuer Microservices
Effiziente und zuverlässige Verarbeitung
durch Aufbau individueller Views
Integration unterschiedlichster
Systeme (Echtzeit und periodische
Lieferung)
Aufbewahrung von Daten über die
Dauer einer Zugfahrt (4 Tage)
Jedes einzelne Event ist kunden-
wirksam und muss daher garantiert
ausgeliefert werden
Für was nutzen wir
Kafka?

Wie hilft uns Kafka?
Zuverlässige, zeitlich unbegrenzte
permanente Speicherung von Daten
ohne Beeinträchtigung der Zugriffszeit
Beliebiger Einstieg im Datenstrom, sowie
erneutes Lesen von Daten (kurze Anlaufzeit
von neuen Features und nach Fehler)
Unterstütz Pub/Sub und Competing
Consumer Pattern auf demselben Topic
(ohne Auswirkung auf Datenmenge)
Sowohl Anwendungen als auch die
Broker können flexibel skaliert werden
(über die Anzahl der Partitionen)
Reihenfolge wird pro Partition garantiert
Integration von Systemen unabhängig vom
Workload, da Kafka als Puffer agiert

Kafka Streams in der
Reisendeninformation

Innerhalb der Plattform setzen wir mittlerweile
vollständig auf Kafka Streams (1.1.1-cp1)
Die Anbindung von Quellen und Abnehmern erfolgt
über die Kafka Consumer bzw. Producer API
(Kafka Connect wird bei uns aktuell nicht verwendet)
Streaming
Technologies

Kafka Streams zur Verarbeitung von
Datenströmen
Kafka
Streams
https://docs.confluent.io/current/streams/introduction.html
Kafka Streams benötigt kein separates
Cluster
Einfacher Betrieb und gute Skalierbarkeit

Kafka Streams zur Verarbeitung von
Datenströmen
Kafka
Streams
Robust und zuverlässig
Kafka Integration für Apache Storm problematisch
• Letztes Release der Storm Kafka-Client Library vom Mai 2018
• Starte Abhängigkeit der Storm Version zur Kafka Version
• Storm Kafka Library hat fetch.min.bytes=0 gesetzt, wodurch
Broker sehr stark belastet wurden
Kafka Streams zu Kafka Broker vor- und
rückwärts-kompatibel (dadurch unabhängig
voneinander aktualisierbar
Sehr gute Betriebs und Entwickler
Dokumentation
Kafka Streams ist Teil des Kafka Ökosystems
(dadurch erprobt, kompatibel und immer aktuell)
https://www.confluent.io/blog/upgrading-apache-kafka-clients-just-got-
Einfache DSL für Entwicklung

Kafka Streams als verteilte Datenbank
Stateful Verarbeitung mit Kafka Streams State
Stores
Stateful Verarbeitung mit globaler
Datenbank (Cassandra, PostgreSQL,
Hazelcast)
Kafka
Streams App
Kafka
Streams App
https://docs.confluent.io/current/streams/architecture.html
 Für Verarbeitung erforderliche Daten liegen lokal vor
 Keine zusätzlichen Abhängigkeiten und niedrige Latenz
 Programmiermodell verhindert Race Conditions und
Inkonsistenzen (Verarbeitung in einem Thread!)
 Zustand in eigenem Topic gesichert, wodurch nach Ausfall
einer Instanz eine andere übernehmen kann
 Datenbank kann zu Bottleneck werden
 Zusätzliche Netzwerkkommunikation
 Das sicherstellen der erforderlichen Konsistenz
und die Vermeidung von Race Conditions ist ein
Herausforderung

Kafka Streams als verteilte Datenbank
Kafka
Streams
State Stores
Massive Verbesserung der Performance:
Dauer der Verarbeitung des Fahrplanimports von 20 auf 2 Minuten reduziert
Zughalt
Haltphase
Abo
Gleisansagen
Bahnhof

Problemstellungen
Rebalancing führt zu „Stop-the-World“-Effekt
Wenn ein Prozess eine Gruppe verlässt oder dieser beitritt, unterbrechen alle Mitglieder der Gruppe die
Verarbeitung und stimmen sich ab, um die Zuweisungen zu den Kafka Partitionen neu zu verteilen.
Die Auswirkungen auf folgende Use Cases sollte reduziert werden:
• Kubernetes Prozess stirbt
• Rolling bounce
• Scale up/down
An einer Lösung wird gearbeitet (Under Discussion):
https://cwiki.apache.org/confluence/display/KAFKA/Incremental+Cooperative+Rebalancing:+Support+and+Policies
KIP-429: Incremental Rebalance Protocol (https://cwiki.apache.org/confluence/display/KAFKA/KIP-
429:+Kafka+Consumer+Incremental+Rebalance+Protocol)
KIP-441: Smooth Scaling Out (https://cwiki.apache.org/confluence/display/KAFKA/KIP-
441:+Smooth+Scaling+Out+for+Kafka+Streams)
 Unsere Anforderung: Die Verarbeitung wird nur für betroffene Partitionen unterbrochen.
 Ein vorübergehendes Ungleichgewicht hat weniger Auswirkungen als viele Umverteilungen

• Upgrade auf Kafka Streams 2.2.0-cp2 (Confluent
5.2.1)
• Erarbeitung von Best Practices für State Store
Konfiguration, Upgrade, … (e.g. zur Reduzierung
der Dauer von Rebalances)
• Evaluierung von KSQL
Nächste Schritte

Deployment & Betrieb
von Apache Kafka

• Aktuell Einsatz von Confluent Plattform 4.1.1
• Betrieb in AWS Cloud auf EC2 Instanzen
• Zum Einsatz kommt Kafka, Zookeeper und
Schema Registry
• Die optimale Konfiguration wurde mit AWS und
Confluent ermittelt
• 4 Cluster mit Live-Daten (von Dev bis Prod) +
weitere Cluster für Test und Entwicklung
Apache Kafka

Deployment (Stretch Cluster)
r4.2xlarge
• 8 vCPUs
• 61GB Memory
• Up to 10Gbit Network
• 1TB EBS/gp2 (3000
IOPS)
r4.large
• 2 vCPUs / 15,25 GB
m4.large
• 2 vCPUs / 8 GB

0
20
40
60
80
22.04
(Mo)
23.04
(Di)
24.04
(Mi)
25.04
(Do)
26.04
(Fr)
27.04
(Sa)
28.04
(So)
29.04
(Mo)
30.04
(Di)
01.05
(Mi)
02.05
(Do)
03.05
(Fr)
04.05
(Sa)
05.05
(So)
Anzahl Nachrichten (in Millionen)
Eingang (Avg: 3,22) Ausgang (Avg: 8,83) Intern (Avg: 54,25)
Aktuelle Auslastung der Broker
Topics
215
Partitionen
2387
Replicas pro
Broker
1194 / 2000
Log Size
1,8 TB
Datenvolumen pro Tag
125 GB
CPU Usage (%)
14 Avg / 60 Max
Replicas
7157
Network Tx (MBs)
2,4 Avg / 39 Max
Network Rx (MBs)
1,3 Avg / 34 Max
Records / sec (in Tausend)
1.2 Avg / 27 Max

Persistenz – Don‘t fear the filesystem
https://docs.confluent.io/current/kafka/deployment.html#jvm
 Kafka verwendet Mapped Byte Buffer für den Zugriff auf
die Log Segmente
 Schreiben:
 Records werden aus Sicht von Java direkt in die Seg-
mente geschrieben  OS entscheidet wann tat-
sächlich geschrieben wird
 Ein Record wird unabhängig davon, ob dieser tatsächlich
geschrieben wurde, als committed
 Lesen:
 Direkt aus dem Arbeitsspeicher
 Zero-Copy: Records müssen nicht in Heap kopiert
werden um diese zu versenden
 Log Struktur erlaubt sequenzielles lesen und schreiben
der Segmente
 Neustart von Kafka sehr schnell, da die Daten bereits im
Page Cache liegen
Größe des Arbeitsspeicher sollte so gewählt sein, dass im Normalbetrieb nicht auf die Disk
zugegriffen werden muss.
JVM Heap (GB)
1,6 Avg / 3,5 Max

Durchsatz-Test
2 Topics mit 12 Partitionen und Replikation 3
for i in 1 2 3 4 5 6 7 8 9 10 11 12; do docker run -d --name kafka-producer-benchmark-$i --net host confluentinc/cp-
kafka:5.2.0 kafka-producer-perf-test --topic sherlock-benchmark-producer --num-records 100000 --record-size 2048 --
throughput -1 --producer-props bootstrap.servers=smoky03-kafka01:9092 batch.size=1
max.in.flight.requests.per.connection=1 acks=-1; done
24 Instanzen:  1287.100677 batches/sec (2.51 MB/sec) pro Instanz
39,2k batches/sec
 Aktuell werden bei Fahrplanimport ca 8,8k batches/sec erreicht

Skalierung
Hinzufügen von neuen Brokern
BessererInstanz-Typ
Größere/zusätzlicheVolumes r5.4xlarge
• 2TB EBS

Garantien, Availability und Durability
 At Least Once Delivery
 Einhaltung der Reihenfolge pro Partition
Die Garantien müssen auch noch eingehalten werden wenn:

L
F
F
 Replikation Factor 3
ISR
 min.insync.replicas = 2
Partition:
Client:
 acks = all (Producer / Streams)
 replication.factor = 3 (Streams)
Broker:
 unclean.leader.election = false

Broker:
 Rackawareness:
brocker.rack = (1a|1b|1c)

Producer:
 max.in.flight.requests.per.connection = 1
L
F
Client
1
2
3
 retries = Integer.MAX_VALUE (default ab 2.1.0)NOT_ENOUGH_REPLICAS
1
1
2 3 1

Monitoring und Alarmierung

Herausforderungen
Dauerhafte „under replicated partitions“
Konfiguration zusammen mit AWS und Confluent optimiert.
Problem nicht mehr aufgetreten

Herausforderungen
Produktiver Betrieb eines Kafka Clusters in der Cloud,
mit welchem 13 Teams arbeiten
Monitoring, Alarmierung und Troubleshooting
Verhalten des Cluster im Fehlerfall
Überwachung und Planung des Wachstums
Team Support

• Upgrade auf Confluent 5.2.1 (Client und Broker)
• Evaluierung R5 Instanz-Typ und Einsatz von 5
Zookeeper
• Anbindung ÖV (+ ~750.000 Sollfahrten pro Tag)
• Evaluierung Kafka Operator und Kubernetes für
Orchestrierung der Middleware
• Evaluierung von Kafka Security
• Verwaltung von Topics über Kubernetes Controller
Nächste Schritte

Fragen?

Freie Fahrt für die Reisendeninformation mit Kafka Streams

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Freie Fahrt für die Reisendeninformation mit Kafka Streams

Ähnlich wie Freie Fahrt für die Reisendeninformation mit Kafka Streams (20)

Mehr von confluent

Mehr von confluent (20)

Freie Fahrt für die Reisendeninformation mit Kafka Streams