Die deutsche Automotive-Industrie durchläuft derzeit einen beschleunigten Digitalisierungsprozess. Ziel ist es nicht nur, eine nachhaltige Mobilität (E-Mobility, Hybridantrieb, autonomes Fahren) voranzutreiben, sondern sämtliche Produktionsprozesse nach dem Leitbild der Smart Factory neu zu denken und zu automatisieren.
Auch in diesem Erfahrungsbericht geht es um die Digitalisierung der Auto-Produktion – von der Bestellung der einzelnen Wagen über die Zusammenstellung der nötigen Bauteile und den Transport des Materials über das Werksgelände bis hin zur robotik-getriebenen Fertigung der Wagen und deren Auslieferung an den Kunden.
Ein wichtiger Baustein dafür ist die Cloud – bietet sie doch beste Bedingungen, zukunftssichere Lösungen zu realisieren, weil sie ein Maximum an Flexibilität, Skalierbarkeit und Kosteneffizienz ermöglicht.
PoCs sind ein etabliertes Mittel, Bestehendes zu hinterfragen und Verbesserungspotenziale freizulegen. Sie helfen, mögliche Lösungen schnell durchzutesten und anhand von Funktionalität und Mehrwert gezielt zu evaluieren.
Die Aufgabe unseres Teams in diesem Kontext war folgender PoC: die technisch-fachliche Prüfung, ob sich die Bestandsanwendungen für den Einsatz in der AWS-Cloud eignen sowie Konzeptionierung und Realisierung der nötigen Anpassungen – stets vor dem Hintergrund von Zukunftsfähigkeit, Skalierbarkeit und Kosteneffizienz.
So haben wir mit unserem PoC geprüft, ob die Bestandsapplikation, namentlich eine SAP-Anwendung auf Basis einer relationalen Datenbank, cloud-tauglich ist und ob/wo wir sie hinsichtlich Nutzung, Verwaltung und Suche weiter optimieren können. Um es vorwegzunehmen: Ja, die Bestandsanwendung ist cloud-kompatibel und ja, sie kann hinsichtlich Rechenleistung und Nutzerfreundlichkeit noch verbessert werden.
Beste Bedingungen für den PoC
Für uns als Tüftler und Macher war es eine große Freude, dass uns der Auftraggeber sämtliche Freiheiten gelassen hat. Die einzige Vorgabe war der Konzernstandard AWS, alle anderen Technologien durften wir frei wählen, durchtesten, vergleichen – um am Ende die tatsächlich beste Lösung in Bezug auf Performance und Wirtschaftlichkeit vorzulegen.
Bestandsanwendung und Ziele des PoCs
Die derzeitige Bestandsanwendung des Auftraggebers wird dafür genutzt, Materiallisten von Fahrzeugen zu importieren, die darin enthaltenen Posten entweder anhand vordefinierter Regeln oder auch manuell über eine Benutzeroberfläche anzupassen und diese dann freizugeben, um sie anschließend in eine andere Anwendung zu übertragen.
Unser PoC konzentrierte sich vor allem auf den Import der Materiallisten sowie die Definition und Ausführung sinnvoller Regeln. Ein Kernaspekt war dabei die Geschwindigkeit der Verarbeitung sowie die Darstellung der Materiallisten und der Regeln in der Benutzeroberfläche.
Im Wesentlichen haben wir dazu verschiedene Datenbankkonfigurationen und -technologien getestet und bewertet. Um die Ergebnisse des PoCs möglichst gut mit der Bestandsanwendung vergleichen zu können, wurden uns dafür Daten aus der Bestandsanwendung zur Verfügung gestellt: etwa 400.000 Datensätze und damit praktisch die reale Datenmenge, die in der Bestandsanwendung verarbeitet wird.
Neben der Performance der Datenbank haben wir in unserem PoC auch die Geschwindigkeit des Frontends auf den Prüfstand gestellt.
Ziel war also, herauszufinden, wie sich Verarbeitungs- und Antwortzeiten durch neue, cloud-kompatible Technologien verbessern lassen.
Herausforderungen
Da neben einer hohen Performance immer auch die Wirtschaftlichkeit einer Anwendung betrachtet werden muss, war es wichtig, dies als Faktor bei allen einzukalkulieren. Ich schreibe das deshalb so ausdrücklich, weil das gerade in einem Cloud-Umfeld schnell übersehen werden kann, weil man seine Ressourcen hier ja mit nur einem Klick vervielfachen kann, während es vom Entwickler zumeist einen höheren Aufwand erfordert, Performance-Engpässe z. B. bei der Architektur, bei der Datenbank-Design oder bei der Schnittstellen-Definition ausfindig zu machen und zu beheben.
Diese Überlegungen waren uns als erfahrene Softwareentwickler wichtig, bei den einzusetzenden Technologien mitzudenken. So lassen sich bspw. mit einer In-Memory-Datenbank sehr gute Ergebnisse bei Antwortzeiten erzielen. Jedoch sind die Kosten auch höher als bei einer klassischen Datenbank. Deshalb war es für uns entscheidend, nicht mit der vermeintlich schnellsten aber dafür auch teuren Datenbanktechnologie zu starten, sondern zunächst eine relationale Datenbank einzusetzen und so im Vergleich mit der Bestandsanwendung, ebenfalls eine relationale DB, zu sehen, ob wir auch damit von der Cloud profitieren können.
Ein weiterer Aspekt des PoCs war es, wie schon gesagt, die Benutzeroberfläche zumindest in Teilen zu überdenken und zu entscheiden, ob wir mit kleineren Änderungen eine bessere Benutzerführung erreichen können. Da dies parallel zur Backendentwicklung geschehen sollte, konnte die Schnittstelle zum Frontend nicht von Anfang an festgelegt werden und blieb im Laufe des PoCs flexibel anpassbar.
Der passende Technologie-Mix
Neben den genannten Herausforderungen mussten die gewählten Technologien natürlich auch den gegebenen Rahmenbedingungen genügen. Diese waren wie folgt definiert:
- nach Möglichkeit serverless und als FaaS
- hohe Skalierbarkeit, ggf. automatische Skalierung
- hohe Performance
- geringe Antwortzeiten
- wirtschaftliches Kostenmodell
Gleichwohl es im PoC darum ging, verschiedene Technologien zu testen und diese im Kontext der gegebenen fachlichen Anforderungen objektiv zu bewerten, mussten bestimmte Teile der Architektur schon früh definiert werden, um überhaupt parallel arbeiten zu können und die Abstimmungsaufwände gering zu halten.
Folgende Technologien wurden zunächst als Basis gewählt:
- AWS Lambda als event-getriebene, serverlose Cloud-Plattform
- AWS Aurora als relationaler Datenbankdienst
- NodeJS als plattformübergreifende Laufzeitumgebung
- TypeScript als Programmiersprache, die perfekt mit NodeJS kooperiert
- Sequelize als ORM im NodeJS-Umfeld
- AppSync als GraphQL-API, um die verschiedenen Lambda-Funktionen in einer Schnittstelle zu vereinen
- Serverless als Hilfe für das einfache Deployment von Lambda-Funktionen und Cloud-Formation-Templates
Testen ohne Vorurteile
Nachdem die Architektur aufgebaut und die Anwendung auf Korrektheit bzgl. der fachlichen Anforderungen geprüft war, starteten wir den PoC. Dabei ging es vor allem darum, Antwort- und Ausführungszeiten zu messen und zu prüfen, an welcher Stelle es zu Engpässen kommt.
Wie erwartet haben wir die Datenbank als wichtigste Komponente für Performance-Verbesserungen ausgemacht. Um eine Paginierung im Frontend zu ermöglichen – bei so großen Datenmengen einfach unverzichtbar – ist es notwendig, neben den angefragten Daten auch die Anzahl der Datensätze für die gemachte Anfrage seitens der Datenbank berechnen zu lassen. Nur so ist es möglich, dem Endnutzer anzuzeigen, auf welcher Seite er sich befindet und wie viele Inhalte es noch mit dem angegeben Filter gibt. Doch genau diese Berechnung kann zu höheren Antwortzeiten führen, wenn der Filter nur wenig einschränkt ist und somit die Berechnung über eine größere Datenmenge stattfindet. Deshalb waren die ersten Ergebnisse ernüchternd.
Doch bevor wir wg. sowas die gewählte Technologie in Frage stellen, sollten wir uns immer zunächst fragen, ob wir die Technologie überhaupt korrekt eingesetzt haben. Bei einer Datenbank fällt der erste Blick dabei immer auf die Indizes. Dort sind die meisten Performance-Verbesserungen zu erreichen.
Nachdem wir die Indizes überprüft hatten und feststellen mussten, dass an dieser Stelle nicht mehr viel Performance rauszuholen war, widmeten wir uns der SQL-Query, die in diesem Fall vom ORM erstellt wurde. Dabei konnten wir sehen, dass die Abfrage für die Anzahl der vorhandenen Daten im gegebenen Filter nicht auf PostgreSQL optimiert war. Dank der Cloud konnten wir dies dann sehr schnell durch den Umzug der Aurora-Engine von PostgreSQL auf MySQL ändern. Allein durch diesen Wechsel der Engine haben wir die Antwortzeit von 11 Sekunden auf einige hundert Millisekunden drastisch gesenkt.
Da wir schon festgestellt hatten, dass die Berechnung der Anzahl der Datensätze einen relativ hohen Aufwand seitens der Datenbank erfordert, versuchten wir im nächsten Schritt, diesen Nachteil zu mildern, indem wir die Abfrage der Daten von der Abfrage der Datenmenge entkoppelten und diese in der Schnittstelle als zwei separate Abfragen bereitstellten. Somit war es möglich, im Frontend beide Abfragen parallel abzufragen, so dass die Antwortzeiten sich nicht mehr aufsummierten.
Nachdem wir die Performance-Engpässe ausgemacht, behoben und so gute Antwortzeiten erreicht hatten, ging es nun an das eigentliche Testen, um zu zeigen, welche Vor- und Nachteile der Einsatz anderer Technologien sowie das Skalieren der Ressourcen bringen. Dazu wurde zunächst die vorhandene Aurora-Datenbank in ihrer Serverless-Version einer EC2-Version gegenübergestellt und skaliert. Beide Versionen verhielten sich sehr ähnlich und brachten keine Nennenswerte Performance-Steigerung. Auch das Hochskalieren der Datenbank zeitigte keine nennenswerten sprich messbaren Verbesserungen. Somit konnten wir festhalten, dass für den PoC bereits eine gering skalierte (2-8 CUs) Aurora-Datenbank ausreichend war.
Im nächsten Schritt haben wir geprüft, ob es Vorteile bringen kann, eine dokument-basierte Datenbank einzusetzen. Auch hier war es dank der Cloud-Infrastruktur einfach möglich, dies zu testen. Dafür haben wir zwei DynamoDB-Tabellen aufgesetzt und zunächst den Import der Daten gestartet. Dabei war es nötig, relativ hohe Werte für die Schreibzugriffe (1000 Write-CUs) zu genehmigen, um den Import der etwa 400.000 Datensätze weiterhin so schnell wie möglich abzuarbeiten. Dies führte jedoch zu erhöhten Kosten, die durch die nur unwesentlich verbesserten Abfragezeiten nicht ausgeglichen werden konnten.
Der Test einer In-Memory-Datenbank war am Ende nicht mehr notwendig, da wir bereits mit den klassischen Datenbanklösungen ausreichend gute Antwort- und Ausführungszeiten erreicht hatten.
Fazit
Der PoC zur Datenbank-Performance hat uns gezeigt, dass wir trotz der Vielzahl an Möglichkeiten für einfache Skalierbarkeit und der großen Auswahl an Technologien in der Cloud immer zunächst prüfen sollten, ob wir die Möglichkeiten der bestehenden Lösung bereits ausgeschöpft haben – bevor wir zu anderen u. U. teureren Maßnahmen greifen.
Und er hat auch gezeigt, dass Legacy-Software durchaus gute Voraussetzungen für die Cloud mitbringt. Wer sie vorurteilsfrei und objektiv durchtestet, wird nicht selten erleben, dass das Bestehende gut funktioniert und sich statt für eine komplett neue Lösung für eine Optimierung der alten entscheiden.
