Optimierung von eventgesteuerten Workloads mit Containern und AWS Serverless

„Bundesweit unterwegs – vor Ort zu Hause“. Das ist das Motto der DB Regio Bus, der Bussparte der DB Regio AG. Die DB Regio Bus hat ihren Schwerpunkt im öffentlichen Personennahverkehr im ländlichen Raum. Sie ist mit über 40 Gesellschaften und Beteiligungen vor Ort dafür verantwortlich, den Busverkehr in weiten Teilen Deutschlands in Bewegung zu halten.

Die Herausforderung

Als Geschäftsbereich des Deutsche Bahn Konzerns (DB) unterliegt die DB Regio Bus den Compliance-Richtlinien der Muttergesellschaft. Die Complianceanforderungen geben klare Leitlinien für die Verwaltung der IT-Infrastruktur und Daten vor. Einen vollständigen und aktuellen Überblick über die IT-Infrastruktur eines Unternehmens zu haben ist vor allem dann wichtig, wenn es sich um ein Unternehmen mit unterschiedlichen komplexen Geschäftsbereichen handelt. Eine Hauptkomponente der Compliance-Richtlinien ist die Erstellung eines Infrastrukturverzeichnisses (Asset-Register), in welchem deutlich wird, welche Ressourcen die DB Regio Bus in der AWS Cloud verwaltet.

Da die DB Regio Bus ITK ein eigenes Asset-Register (Quellsystem) pflegt ergibt sich die Notwendigkeit, dieses Register in das zentrale Register der Deutsche Bahn (Zielsystem) zu synchronisieren.

Die Umsetzung dieser Anforderung erfordert die Entwicklung eines neuen Prozesses und einer neuen Anwendung.

Folgende Herausforderungen ergeben sich für die Umsetzung:

• Trennung von Staging- und Produktivbetrieb
• Anforderung: Implementierung eines Batchworkloads als Fully Managed Service, um minimale Belastung von Betriebsteams zu gewährleisten (automatisierte und tagesaktuelle Ausführung des Workloads)
• Sicherstellen, dass sich die Anwendung automatisiert weiterentwickeln lässt (ohne viel Aufwand durch Entwickler)
• Kontinuierliche Weiterentwicklung und Bereitstellung der Anwendung mittels CI/CD
• Keine dauerhafte Laufzeit (nach Bedarf einsetzbar). Die Laufzeit besteht nur, so lange eine Aufgabe zu erledigen ist

Die Lösung

Aufteilung in Test und Produktivbetrieb:

Um die gleichzeitige Weiterentwicklung der Anwendung und gleichzeitig einen stabilen Produktivbetrieb der Anwendung zu gewährleisten, wurde die Anwendung in zwei identische, jedoch voneinander getrennte Umgebungen aufgeteilt. Während auf der Produktivumgebung die stabile Version der Anwendung betrieben wird, kann in der Testumgebung weiter an der Optimierung der Anwendung gearbeitet werden.

Automatisierung von Docker Images Builds zu ECR

Die implementierte CI/CD-Pipeline auf Basis von AWS CodePipeline, CodeCommit, CodeBuild und CodeDeploy ermöglicht vollautomatische Deployments in beide Umgebungen. Ebenfalls automatisiert sind Unit- sowie Integrationstest des Anwendungsartefakts innerhalb der CI/CD Pipeline. Nach erfolgreichen Tests wird automatisiert ein Dockerimage erstellt und in AWS ECR abgelegt.

Automatische Updates des ECS Services

Sobald ein neues Image erstellt wurde, wird diese neue Version vollautomatisch mit Hilfe von CodeDeploy auf AWS Elastic Container Service (AWS ECS) ausgerollt. AWS ECS sorgt nun dafür, dass beim nächsten Trigger (s.u) automatisch die neuste Version der Anwendung genutzt wird.

Move zu Cloudwatch getriggertem Batch Workload

Der Workload lässt sich als sog. Batchworkload umsetzen: Aus der Quelldatenbank werden Daten ausgelesen, innerhalb der Anwendung entsprechend den Anforderungen konvertiert und ins Zielsystem transferiert. Nachdem alle Datensätze bearbeitet und transferiert wurden gibt es keinen Grund, die Anwendung weiterhin „laufen zu lassen“.

Aus diesem Grund wurde AWS ECS ausgewählt, da sich der Service bestens für Batchworkloads eignet. Basierend auf einem AWS CloudWatch Eventtrigger wird die Anwendung jeden Tag zu einer zuvor definierten Zeit gestartet. Nachdem alle Datensätze prozessiert wurden, wird die Anwendung automatisch gestoppt und erst durch den nächsten Trigger erneut gestartet.

Dies reduziert die Kosten der implementierten Lösung im Vergleicht zu einer Architektur basierend auf AWS EC2 um das ca. 10-fache.