Application Performance Monitoring (APM) von Microservices und FaaS in OpenShift

Autonome Fahrfunktionen werden immer komplexer und auch die Zahl der Servicefunktionen im Fahrzeug wächst. Da ist es gerade in der Entwicklung wichtig, diese Herausforderungen zu meistern. Für diesen Fall bieten sich sogenannte Microservices an, die eine massive Parallelisierung von Diensten erlauben. Doch warum macht der Einsatz von Microservices hier Sinn und wie kann man da den Überblick behalten?

Autonome Fahrfunktionen

Da autonome Fahrfunktionen und alles was dazu gehört, sehr komplex sind, braucht es von Beginn an eine Architektur, die diesen Herausforderungen gewachsen ist. Microservices modularisieren Software und liefern damit genau das, was benötigt wird, um Software erweiterbar und wartbar zu gestalten. Die einzelnen, unabhängig voneinander entwickelten und deployten Microservices lassen sich einfacher tauschen, updaten oder erweitern. All das sind Dinge, die eine Skalierbarkeit schaffen, die bei großen Projekten, wie im Bereich autonomem Fahren, wichtig sind.

Ähnlich wie ein Microservice, kann an dieser Stelle auch ein Function as a Service (FaaS) eingesetzt werden. Dieser hat den Vorteil, dass er nicht wie der Microservice durchgehend läuft, sondern nur gestartet wird, wenn die Funktion aufgerufen wird. Bezahlt wird dann auch nur die tatsächliche Rechenzeit, die von der Funktion in Anspruch genommen wird.

Setzt man diese Microservices oder FaaS nun in einzelne Container (z.B. OpenShift), kann jeder dieser Services in einer anderen Programmiersprache auf einer anderen Plattform implementiert sein und trotzdem über eine REST Schnittstelle mit den anderen kommunizieren. Ebenso kann jeder Service einzeln skaliert werden.

Microservices Aufbau v2 eigene Darstellung
Abbildung 1: Microservices Aufbau v2 eigene Darstellung

Warum sollte man Microservices überwachen?

Aus demselben Grund wieso man Systeme im generellen überwacht – weil alle Systeme Fehler aufweisen können. Ein System ist nicht immer „Up“ oder „Down“, es kann auch in einem herabgesetzten Zustand sein, was beispielsweise Performance Einbußen mit sich bringt. Ein Monitoring zeigt solche Zustände auf und kann dadurch eventuell auch einen Ausfall verhindern.

Dienstleistungen, die intern oder für externe Kunden erbracht werden, werden oft im Rahmen eines Service Level Agreement (SLA) festgehalten. Ohne Monitoring ist es unmöglich zu wissen, ob das SLA eingehalten oder verletzt wird.

Überwachungssysteme produzieren zudem im Laufe der Zeit wertvolle Daten, die zur Verbesserung der Leistung genutzt werden können. Fehler- und Leistungsdaten können analysiert werden, um nach Mustern bei Systemausfällen oder Performance Einbrüchen zu suchen, die mit Ereignissen korreliert werden können.

Monitoring ist für die Aufrechterhaltung belastbarer und verfügbarer Systeme unerlässlich. Gerade in der Entwicklung autonomer Fahrfunktionen wird mit großen Datenmengen in sehr komplexen Algorithmen gearbeitet. Da ist es wichtig, dass das System zuverlässig und performant läuft.

Monitoring von Microservices in OpenShift

Monitoring ist ein Prozess der Berichterstattung, Sammlung und Speicherung von Daten. Es gibt einige gängige Kennzahlen im Monitoring für Microservices in Openshift, die man aufzeichnen kann. Dazu gehören:

  • Anwendungskennzahlen
    Zeichnet Kennzahlen auf, die innerhalb der Anwendung messbar sind. Das könnte beispielsweise Nutzer Registrierungen sein oder wie viele Fahrzeug Simulationen an einem Tag gemacht werden, um ein Beispiel aus den autonomen Fahrfunktionen aufzuzeigen.
  • Plattformkennzahlen
    Hier werden Kennzahlen der Infrastruktur gemessen, wie zum Beispiel die Ausführungszeit bestimmter Funktionen oder die Auslastung einer GPU für die Fahrzeug Simulation. Das sind auch Kennzahlen, bei denen Performance Probleme sichtbar gemacht werden können.
  • System Events
    Hier geht es grundlegend um betriebliche Änderungen oder Code-Bereitstellungen. Diese führen häufig auch zu Systemfehlern oder Ausfällen. Solche Änderungen können dann mit dem Systemverhalten korreliert werden, um zu sehen, ob es da Zusammenhänge gibt.

Doch wie sieht so eine Monitoring Lösung nun konkret aus. Im Folgenden wird exemplarisch die Monitoring Lösung Dynatrace aufgezeigt:

Microservice Dynatrace Monitoring eigene Darstellung
Abbildung 2: Microservice Dynatrace Monitoring eigene Darstellung

Der Dynatrace OneAgent Operator wird als Container auf der OpenShift Node ausgeführt. Dieser OneAgent „setzt“ sich in alle anderen Container und überwacht diese anschließend. Damit kann sehr schnell eine komplette OpenShift Node und die darin liegenden Microservices, überwacht werden.

Fazit

Der Einsatz von Microservices bringt enorme Vorteile, bei der Umsetzung großer Softwareprojekte, wie die Entwicklung autonomer Fahrfunktionen. Doch um ein solch großes Projekt dauerhaft stabil und performant zu betreiben, ist es wichtig, dass diese Services und Funktionen durch den Einsatz einer Monitoring Lösung wie z.B. Dynatrace überwacht werden. Danach kann das System möglichst performant betrieben und deutlich einfacher skaliert werden.

 

Mehr über Connected Car Services erfahren

 


Hier geht es zu Teil 1 und 2 der Blogserie:

Teil 1: Mit der Cloud vielfältige Fahrszenarien lernen – Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt

Teil 2: Codequalität für autonome Fahralgorithmen gewährleisten


Weitere Artikel zu diesem Thema:

DevOps, Microservices & Big Data: Drei Top IT-Themen, die Automobilhersteller künftig beschäftigen werden

Skalierbare Microservices mit Docker und HAProxy

Wussten Sie schon, was Microservices sind?


Quellen:

https://www.all-electronics.de/evolutionaere-fahrzeug-architektur-devops/

https://thenewstack.io/the-hows-whys-and-whats-of-monitoring-microservices/

Dynatrace Logo:

https://dt-cdn.net/wp-content/uploads/2016/12/dynatrace_logo.png

OpenShift Logo:

https://upload.wikimedia.org/wikipedia/commons/thumb/3/3a/OpenShift-LogoType.svg/1200px-OpenShift-LogoType.svg.png

Codequalität für autonome Fahralgorithmen gewährleisten

Die Entwicklung autonomer Fahrzeuge ist ein Wettrennen, daher müssen schnellstmöglich stabile Algorithmen für das autonome Fahren entwickelt werden. Dafür müssen Bug Fixes und neue Features so schnell wie möglich implementiert werden, aber ohne die Qualität aus den Augen zu verlieren. Wie kann das gerade in solch großen und komplexen Projekten gewährleistet werden? Die Antwort findet sich in einer skalierbaren „Continuous Integration“ und Continuous Delivery“ Pipeline. Hier erfahren Sie wie der Aufbau einer skalierfähigen Continuous Integration und Continuous Delivery Pipeline in OpenShift funktionieren kann.

Continuous Integration und Delivery – was ist das?

Continuous Integration oder kurz CI sorgt dafür, dass neu entwickelter Code zusammengeführt, getestet und dann in die Gesamtcodebasis eingefügt wird. CI soll die Zusammenarbeit der Entwickler vereinfachen und dabei helfen Fehler frühzeitig zu erkennen.

continous integration

Abbildung 1: So funktioniert Continuous Integration [1]

Mehrere Entwickler arbeiten an neuen Features oder Bug Fixes. Sobald einer von ihnen sein Arbeitspaket fertiggestellt hat, wird der Code committet und genau hier setzt CI dann ein. Sobald der Code gepusht wird, überprüft CI ob der neue Code sich nahtlos in die schon vorhandene Codebasis einfügen lässt. Anschließend startet ein automatischer Build, der dann aufzeigt ob der Code fehlerfrei gebaut werden kann oder ob es fehlschlägt. Schlägt der Build fehl, muss der Entwickler den Bug finden und beheben und den Prozess erneut starten. War der Build fehlerfrei, wird getestet und das entsprechende Ergebnis reportet.

Continuous Delivery oder kurz CD sorgt dafür, dass eine aktuelle Version der Software verfügbar gemacht wird. CD erweitert das CI Vorgehen um den Punkt „Release“ (Continuous Integration + Release = Continuous Delivery). Dabei wird die neue Codebasis auf eine Produktivumgebung implementiert, sodass die neuen Features dort getestet werden können.

Umsetzung mit OpenShift

CI/CD ist einer der beliebtesten Anwendungsfälle für die OpenShift Container Plattform. OpenShift stellt Container für den Bau von Continuous Delivery-Pipelines zur Verfügung. Dies ermöglicht es unter anderem Jenkins, viele Aufträge parallel auszuführen und beseitigt die Wartezeit für die Ausführung von Builds in großen Projekten. OpenShift bietet eine End-to-End-Lösung für den Aufbau kompletter Bereitstellungspipelines und ermöglicht die notwendige Automatisierung, die für die Verwaltung von Code- und Konfigurationsänderungen über die Pipeline erforderlich ist.

Dieses Beispiel zeigt eine CI/CD-Infrastruktur auf OpenShift:

Beispielhafter Aufbau einer CI oder CD-Infrastruktur auf OpenShift

Abbildung 2: Beispielhafter Aufbau einer CI/CD-Infrastruktur auf OpenShift (eigene Darstellung)

Einsatz in der Fahralgorithmen Entwicklung

Wenn ein neues Feature für den Algorithmus entwickelt wird, beispielsweise eine Erkennung von Ampeln, dann wird dieses Feature in einzelne Module aufgeteilt. Dies wird gemacht, da ein solches Feature meist zu groß ist, um es mit nur einem Team zu entwickeln oder es zu zeitintensiv ist, um es in einem Sprint fertigzustellen. Jedes dieser Module wird daher getrennt (pro Team/Sprint) entwickelt und jedes durchläuft einen CI Prozess. Dadurch durchläuft jede Teilentwicklung Unit- und Integrationstests, wodurch die Codequalität jedes Moduls und dadurch auch jedes Features steigt.

CI oder CD Prozess anhand der Entwicklung eines neuen Fahralgorithmen Features

Abbildung 3: CI/CD Prozess anhand der Entwicklung eines neuen Fahralgorithmen Features (eigene Darstellung)

Ein CD erfolgt meist zu einem Sprint Ende oder pro Feature. Zum Sprint Ende werden dann mehrere neu entwickelte Features auf die E2E Umgebung und schlussendlich auf PROD deployed (siehe Abbildung 4). Bei der zweiten Herangehensweise wird ein Feature, sobald es fertig ist, deployed (siehe Abbildung 3).

Continous Delivery bei der Entwicklung autonomer Fahrfunktionen
Abbildung 4: Continous Delivery bei der Entwicklung autonomer Fahrfunktionen (eigene Darstellung)

Fazit: Was bringen CI und CD, auch im Umfeld autonomes Fahren?

Die Umsetzung einer CI und CD bringt einige Vorteile mit sich:

  • Da neue Features und Bug Fixes schneller auf der E2E beziehungsweise auf Produktivumgebung sind, kann früher mit Testfahrzeugen unter realen Bedingungen getestet und das Feedback der Kunden eingeholt werden.
  • Die gesamte Entwicklungs- und Testzeit neuer Features ist schneller, was eine übergreifend schnellere Entwicklung des Fahralgorithmus bedeutet. Das wiederrum kann einen Wettbewerbsvorteil in der Automobilbranche bringen.
  • Bugs werden früher erkannt und können besser identifiziert werden, da man nach jedem Commit weiß ob der Build geklappt hat oder nicht.
  • Daraus folgt eine übergreifend höhere Code- und Softwarequalität, was gerade für autonome Fahrfunktionen besonders wichtig ist.

Hier geht es zu Teil 1 und 3 der Blogserie:

Teil 1: Mit der Cloud vielfältige Fahrszenarien lernen – Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt

Teil 3: Application Performance Monitoring (APM) von Microservices und FaaS in OpenShift


Quellen:

[1] https://cloud.google.com/solutions/continuous-integration/images/hero-banner.png

https://blog.openshift.com/cicd-with-openshift/

Git Logo: https://git-scm.com/images/logos/2color-lightbg@2x.png

Jenkins Logo: https://miro.medium.com/max/2100/1*LOFbTP2SxXcFpM_qTsUSuw.png

SonarQube Logo: https://www.sonarqube.org/images/logos/sonarqube-dark.png

OpenShift Logo: https://upload.wikimedia.org/wikipedia/commons/thumb/3/3a/OpenShift-LogoType.svg/1200px-OpenShift-LogoType.svg.png

Mit der Cloud vielfältige Fahrszenarien lernen – Wie die Cloud bei großen Datenmengen in der Testausführung von autonomen Fahrzeugen unterstützt

Jeder spricht darüber und alle großen Automobilhersteller entwickeln es – das autonome Fahrzeug. Doch wie „lernt“ ein Fahrzeug, selbständig zu fahren und mit der Flut an Datenmengen (Szenarien, Sensoren etc.) umzugehen? Wir zeigen Ihnen, warum die Cloud einen großen Teil dazu beiträgt und wie der Nutzen der skalierbaren Cloud für die Verarbeitung großer Datenmengen durch Function as a Service (FaaS) entsteht.

Vorsicht Fahranfänger – Wie Fahrzeuge mit riesigen Datenmengen umgehen lernen?

Genauso wie wir Menschen das Fahren lernen – mit Übung. Je mehr Kilometer wir fahren, desto sicherer werden wir im Straßenverkehr. „Learning by doing“ ist hier das Stichwort. Fahrzeuge tun das mit Hilfe von Sensoren, Rechenkapazität und dem Einsatz künstlicher Intelligenz (KI). Die Sensoren überwachen pausenlos umliegenden Gebäude, Fußgängerwege, Verkehrsteilnehmer und andere Personen. Die Rechner verarbeiten diese gewaltige Datenflut mit Hilfe von Algorithmen. Diese interpretieren dann die Daten und schaffen so ein Bild der Umgebung des Fahrzeugs und reagieren darauf.

Sensoren autonomes Fahren

 

 

 

 

 

 

 

 

 

 

( zu sehen 09:36 How a driverless car sees the road Quelle: YouTube)

Sensoren und KI autonomes Fahren

 

 

 

 

 

 

 

 

 

 

(09:44 How a driverless car sees the road Quelle: YouTube)

Über das maschinelle Lernen tasten sich die Systeme immer mehr an komplizierte Situationen im Straßenverkehr heran. Die Königsdisziplin ist der Arc de Triomphe in Paris – eine Herausforderung für den normalen Autofahrer und eine enorme Herausforderung für ein autonomes Fahrzeug – auch im Hinblick der in dieser Situation zu meisternden Datenmengen.

KI Algorithmen werden mit Hilfe großer Datenmengen trainiert, damit sie Verkehrssituationen richtig interpretieren, vor allem aber korrekt darauf reagieren können. Dafür werden viele Millionen gefahrene Testkilometer benötigt. Aber vor der Quantität steht die Qualität, denn bei perfekten Bedingungen kann jeder fahren. Ein leistungsstarker Algorithmus muss mit Extremsituationen umgehen können, weshalb er gerade diese lernen muss. Doch wie bringt man ein Fahrzeug kontrolliert in teilweise gefährliche Extremsituationen?

Simulieren statt Probieren

Die enorme Anzahl an zu fahrenden Testkilometern und das Testen gefährlicher Extremsituationen, kann während der Entwicklung eines Algorithmus nicht geliefert werden. Denn nach jeder Änderung an diesen Algorithmen müssten diese Testkilometererneut gefahren werden. Um dieses Problem zu lösen, wird ein Großteil der Testkilometer virtuell per Simulation zurückgelegt. BMW spricht davon, dass „rund 95% der Testkilometer per Simulation absolviert werden“, so Martin Peller [1], Leiter der Fahrsimulation bei BMW. Diese Simulationen können nun entweder in der Cloud oder OnPremise betrieben werden.

Hoch performante Cloud-Anwendungen als Basis

Die Cloud bietet eine Vielzahl von Vorteilen gegenüber einer On-Premise (Vor Ort) Lösung:

  • Kein eigenes Rechenzentrum und somit auch einen geringeren Personalaufwand
  • Der Cloud Anbieter liefert meist Support und Wartung Rund um die Uhr
  • Die Rechenleistung ist flexibel skalierbar und lässt sich somit perfekt an den Bedarf anpassen
  • Die räumliche Unabhängigkeit bietet einen Zugriff von jedem beliebigen Ort aus
  • Cloud Anbieter gewährleisten dank Sicherheitskopien und Co eine hohe Datensicherung
  • Keine Investitionskosten für Server-Hardware, was den Einstieg kostengünstiger macht

All diese Punkte sprechen für eine Cloud-Lösung und zeigen auf, warum Cloud-Computing-Anbieter wie AWS (Amazon Web Services) und Microsoft Azure so eine Marktrelevanz haben. Auch wir bei doubleSlash beschäftigen uns mit den Big Playern des Cloud Computing und entwickeln hoch performante Cloud Anwendungen. Speziell eben auch im Bereich der Testfahrten-Simulation für autonome Fahrzeuge. Solch performante Lösungen nennt man „Function as a Service“ oder kurz FaaS.

Fazit: Function as a Service als wichtiger Bestandteil bei der Entwicklung autonomer Fahrzeuge

Anwendungen wie die Simulation von Testfahrten oder der Sprachassistent Alexa sind Beispiele für eine Function as a Service (FaaS) Lösung. Dabei werden dem Anwender einzelne Funktionen zur Verfügung gestellt, die angesprochen werden können und innerhalb kürzester Zeit Ergebnisse liefern. Bei Alexa wäre das beispielsweise eine Anfrage, wie das Wetter morgen wird.

Daher findet der FaaS Ansatz häufig dann seinen Einsatz, wenn Performanz und Skalierbarkeit Kernanforderungen an die Lösung sind. Zudem wird nur die tatsächliche Rechenzeit, die zur Ausführung der Funktionen benötigt wird, in Rechnung gestellt.

FaaS-Lösungen und damit leistungsfähige Cloud Infrastrukturen wie Azure und AWS sind also ein wichtiger Bestandteil der Entwicklung autonomer Fahrzeuge.


Hier geht es zu Teil 2 und 3 der Blogserie:

Teil 2: Codequalität für autonome Fahralgorithmen gewährleisten

Teil 3: Application Performance Monitoring (APM) von Microservices und FaaS in OpenShift


Weitere Artikel rundum das autonome Fahren:

https://blog.doubleslash.de/autonomes-fahren-im-praxistest-zf-teststrecke-im-selbstversuch/

https://blog.doubleslash.de/vision-zero-durch-autonomes-fahren/

https://blog.doubleslash.de/von-driver-only-bis-roboter-taxi-die-herausforderungen-beim-automatisierten-fahren/


Quellen:

https://www.bmw.com/de/innovation/die-entwicklung-selbstfahrender-autos.html

https://www.automotiveit.eu/virtuelle-kilometerfresser/entwicklung/id-0064486

https://www.it-management.today/on-premise-vs-cloud-software-vor-und-nachteile/