Die Zielstellung ist: Ein Tester oder eine Testerin soll eine Testausführung auf mehreren, parallelen Recheneinheiten auf Knopfdruck starten können. Wenn die Testausführung abgeschlossen ist, gibt es einen Bericht, der alle Testausführungen, -messungen und -ergebnisse so zusammenfasst, als wäre die Ausführung auf einem einzelnen Rechner erfolgt.
1. Verbindung vom Rechner in die Cloud über Internet
2. Aufbau von Instanzen
3. Upload von Dateien vom Rechner zu Instanzen (wie Modelle, Test-Skripte, etc.)
4. Start von Testausführung mit ausgewählten Testfällen je Instanz
5. Download von Dateien von Instanzen zum Rechner (wie Testberichte, etc.)
6. Abschalten von Instanzen
Die Nutzung mehrerer paralleler Recheneinheiten erfolgt durch Cloud-Computing und für uns mit einem Cloud-Nativen-Ansatz. Die Auswahl in unserer Fallstudie fiel auf den weltweit führenden Cloud-Anbieter Amazon Web Services (AWS), der Ende 2022 einen Marktanteil von 32 Prozent hatte (Quelle) und laut Recherche auch von vielen automotive OEMs genutzt wird.
Die gewählten Recheneinheiten für die Testausführung sind moderat und gut vergleichbar mit den in der Entwicklung üblichen CPUs und RAM. Aus Kostengründen wurde Linux als Betriebssystem gewählt. Die genutzten Tools werden in Amazon Machine Images (AMI) integriert.
Für den Upload und Download wurde entschieden einen einfachen Online-Cloud-Speicher (S3), einen Service von AWS, zu nutzen. Die Nutzung ermöglicht einen einfachen Zugriff zum Datenaustausch beim Up- und Download. Die Tools werden in Amazon Machine Images (AMIs) integriert.
Programme wie TPT und Matlab/Simulink benötigen ein Betriebssystem wie Windows oder Linux um lauffähig zu sein. Ein solches Betriebssystem wird von Cloud-Anbietern mit angeboten. Bei AWS heißt es Amazon Machine Image (AMI). Ein AMI ist wie ein Betriebssystem einer virtuellen Maschine; es ist vorkonfiguriert und weitere Installationen oder Anpassungen sind möglich.
AWS stellt einige Standard-AMIs bereit, die meist nur das Betriebssystem enthalten. Durch das Hinzufügen der gewünschten Software, Tools und Anwendungen können individuelle AMIs von diesen Standard-AMIs abgeleitet werden. Sobald ein AMI definiert ist, kann diese Konfiguration eins zu eins auf mehreren virtuellen Maschinen genutzt werden.
In unserem ersten Anwendungsfall haben wir uns für ein Linux Betriebssystem entschieden, da die von uns verwendeten Programme alle auch unter Linux ausführbar sind. Weil für die Nutzung von TPT und Matlab/Simulink Lizenzen benötigt werden, haben wir Lizenzserver außerhalb der Cloud gehostet. Die Lizenzserveradresse lässt sich direkt im AMI per Konfigurationsdatei angeben.
Das Kostenmodell basiert auf der Laufzeit der Instanz und es spielt dabei keine Rolle, ob die verfügbaren Ressourcen genutzt werden oder nicht. Für unseren ersten Fall mit vielen Instanzen ist es darum sinnvoll, nicht zu übertreiben.
Konkret fiel unsere Wahl auf EC2 Instanzen vom Typ T2.medium. Als Basis muss ein AMI definiert sein, damit die EC2-Instanz erstellt werden kann. Der Aufbau, das Abschalten und die Kommunikation mit den EC2 Instanzen erfolgt über SSM (AWS Systems Manager Session Manager): eine interaktive Shell und Command-Line-Interface zur EC2-Instanz-Verwaltung.
Bildunterschrift ergänzen
Um mit dem Testen starten zu können, braucht es noch Einstellungen, die eine sichere und reibungsfreie Kommunikation zwischen dem lokalen Rechner und der Cloud erlauben.
Die Kommunikation wird konfiguriert unter anderem durch Identity- and Accessmanagement (IAM), Virtual Private Clouds (VPCs) und Sicherheitsgruppen für eingehenden und ausgehenden Datenverkehr. Zum Schutz der Daten/IP und der Brieftasche werden mehrere Security-Mechanismen für die Kommunikation zwischen dem lokalen Rechner und der Cloud umgesetzt. Wichtig ist, diese Mechanismen zu verstehen und dann passend für den jeweiligen Anwendungsfall zu konfigurieren. Dabei sollten alle Elemente der Anwendung betrachtet werden.
In unserem Fall Nummer 1 gibt es mehrere Kommunikationsbeziehungen:
1. Anmeldung des lokalen Rechners in der Cloud = Initiale Anmeldung für weitere Kommunikation
2. Kommunikation vom Rechner zur Speicher-Einheit S3 für Up- und Download
3. Kommunikation vom Rechner zum SSM (z. B. Start von drei EC2-Instanzen)
4. Kommunikation vom Rechner zur EC2-Instanz (z. B. Tests starten)
5. Kommunikation von EC2-Instanz zur Speicher-Einheit S3 (Modell laden, Testberichte ablegen)
Wenn der Rechner erfolgreich mit den Cloud-Services kommuniziert, ist die IT-Konfiguration gelungen, und das eigentliche Testen kann starten.
Kommunikation zwischen Rechner und Cloud über SSM zu ECS zu TPT (über Commandline)
Die AWS-Default-Einstellungen sind aus Security-Sicht sehr restriktiv. Nahezu jeder Kommunikationsknotenpunkt muss in AWS konfiguriert werden.
1. Auf lokalem Rechner
2. Testausführung in der Cloud vom lokalen Rechner initiieren
3. Auf lokalem Rechner
Wir haben ein Automatisierungsskript erstellt, dass die folgenden Aufgaben übernehmen soll:
Der größte Aufwand lag bei den Security-Aktivitäten. Oft mussten wir erst einmal verstehen, welche Ports wir freischalten müssen, um eine Kommunikation zwischen zwei Entitäten zu ermöglichen.
Zum Beispiel für den Datei-Upload vom lokalen Rechner zu den Instanzen und für den Download der Reports aus der Instanz auf den Rechner.
An zahlreichen Stellen mussten auch die Kommunikationsbeziehungen zwischen den genutzten Elementen in AWS und dem Nutzer erlaubt werden. Als wir diese Wirkketten eingerichtet und verstanden haben, konnten wir ein Automatisierungsskript in Python umsetzen. Dank des sehr eingänglichen und umfangreichen boto3-Frameworks gelang das unglaublich schnell und reibungslos.
Allerdings können Skripte, die auf einem lokalen Rechner ausgeführt werden und den Prozess steuern, auch Risiken bergen:
Geht die Verbindung zwischen lokalem Rechner und Cloud verloren, laufen nicht benötigte Instanzen weiter und verursachen unnötige Kosten.
Auch ein Skript muss durch einen Nutzer gestartet werden. Das kann zu Zeitverzug führen, ist manchmal unkomfortabel und kann auch fehleranfällig sein.
Um solche Risiken lokaler Skripte zu minimieren, haben wir unseren ersten Anwendungsfall erweitert: Wir haben eine zusätzliche Instanz in der Cloud aufgebaut, die den Testausführungsprozess initiiert und überwacht. Das wird im zweiten Anwendungsfall beschrieben.