Close

Kosten bei Skalierung mit mehreren Instanzen

Einer der Hauptgründe für das Testen in der Cloud ist es, die Testdauer zu reduzieren, also die Zeit vom Teststart bis zum Erhalt der Testergebnisse. Technisch wird das ermöglicht, indem die Tests auf mehrere parallele Cloud instanzen aufgeteilt werden.

Der Vorteil dieses stark skalierbaren Ansatzes ist, dass – in gewissen Grenzen – die Gesamttestdauer annähernd linear reduziert werden kann, während die dafür notwendigen, zusätzlichen Instanzen nur geringe Mehrkosten verursachen.

Prinzip und Begriffe rund um die Skalierung
Zusatzkosten und Grenzen der Skalierung
Optimale Kosten-Nutzen-Betrachtung der Skalierung

Die Zukunft der ECU-Absicherung liegt nicht beim Entwicklungsfahrzeug oder HiL, sondern in der Cloud, wo Skalierbarkeit und Flexibilität neue Dimensionen des Testens ermöglichen.

Felix Wempe

Prinzip und Begriffe rund um die Skalierung

Die Skalierbarkeit beim Testen in der Cloud basiert im Kern auf der Möglichkeit, die Testausführungszeit aufzuteilen.

Technisch macht es keinen Unterschied, ob eine Instanz 100 Stunden Tests durchführt oder zwei Instanzen je 50 Stunden Tests ausführen. Die Gesamtlaufzeit der Tests ist identisch.

Die Gesamtdauer dagegen kann mit doppelter Anzahl an Instanzen halbiert werden, wenn jede Instanz die gleiche Ausführungszeit benötigt und alle Instanzen zur selben Zeit gestartet werden.

Aufteilung der Run Time von einer Instanz auf zwei Instanzen; Aufteilung bewirkt keine Änderung der Run-Time

Kosten für die Lebenszeit einer Instanz

Jede Instanz hat eine Lebenszeit (Life Time). Die Life Time startet mit dem Hochfahren einer Instanz und endet mit dem Herunterfahren der Instanz. Das Kerngeschäft von Cloud-Anbietern ist ein Mietmodel.

Die Kosten errechnen sich so:

Kosten einer Instanz = Laufzeit der Instanz in Minuten * Minutenpreis

Und das für jede Instanz. Es gibt noch weitere Business-Modelle von Cloudanbietern, wir beschränken uns bei der Kostenbetrachtung ausschließlich den üblichen On-Demand-Service; also der Möglichkeit jederzeit beliebig viele Instanzen zu starten, wie benötigt werden.

Phasen der Lebenszeit

Vor dem Testen muss das Betriebssystem hochgefahren werden, Tools müssen gestartet und gegebenenfalls Testrahmen aktualisiert werden. Prüfling und Testdaten werden außerdem in die Instanz kopiert. Das kann einen Augenblick dauern.

Als Run Time bezeichnen wir im Folgenden die Dauer für die Testausführung in einer Instanz. Diese hängt von mehreren Faktoren ab:

 

  • Umfang des Prüflings (z. B. Architektur/Design, Schnittstellen und Lines of Code)
  • Architektur/Design der Testfälle
  • Leistungsfähigkeit der Instanz (CPU, Speicher, Zugriffszeiten, etc.)
  • Leistungsfähigkeit der Testumgebung
  • und weitere

Nach dem Testlauf sollen die Testdaten aus der Instanz gesichert werden. Dafür müssen diese Daten vor dem Herunterfahren der Instanz, durch Verschieben/Kopieren in Bereiche außerhalb der Instanz verfügbar gemacht werden.

Auch wenn Start Up und Shut Down unproduktive Zeiten (im Folgenden auch als Overhead bezeichnet, kurz OH) sind, können sie nicht entfallen. Sie sind für den Gesamtprozess in der Cloud absolut notwendig. 

Durch eine geschickte Orchestrierung konnten für unsere beiden Anwendungsfälle die unproduktiven Zeiten in Summe auf etwa 5 bis 10 Minuten reduziert werden.

Zusatzkosten und Endlichkeit der Skalierung

In der Betrachtung der zusätzlichen Kosten gibt es zwei Seiten der Medaille:
Ein vermeintlicher Nachteil beim Skalieren

Obwohl die Aufteilung von Tests die Laufzeiten von Instanzen reduzieren, steigen in Summe die Gesamtkosten mit jeder weiteren Instanz gegenüber der Ausführung mit einer Instanz an.

Der Grund ist einfach: Jede zusätzliche Instanz verursacht Mehrkosten. Die Mehrkosten resultieren aus den notwendigen Overhead (Start Up und Shut Down Phasen) jeder weiteren Instanz (siehe Abbildung).

Das Positive des Skalierens

Die Dauer eines Testlaufs kann sehr stark reduziert werden.

Skalierung bei langen Testausführungszeiten lohnt sich fast immer.

Die Mehrkosten sind im Vorfeld gut berechenbar und das Beste: Die Mehrkosten durch Overhead haben nur einen geringen Kostenanstieg zur Folge.

Best-Case zur Aufteilung von Run-Times/Life Time für eine minimale Gesamtdauer

Schnellstmögliche Testergebnisse? Dafür muss die Aufteilung optimal sein. Die Gesamtdauer der Tests kann maximal auf die Dauer der längsten Instanz reduziert werden (siehe Abbildungen). Und im Idealfall erfolgt die Instanziierung so, dass die Life Time aller Instanzen gleich ist.

Ausführungsdauer bei nicht Äquidistanter Run-Time Aufteilung exemplarisch mit 2 Instanzen

Ausführungsdauer bei Äquidistanter Run-Time Aufteilung exemplarisch mit 2 Instanzen

Mit der Annahme, dass die unproduktiven Zeiten bei allen Instanzen nahezu gleich sind, sollte die Aufteilung von Tests auf Instanzen so gewählt werden: Die Run Time über alle Instanzen soll ebenfalls möglichst gleich sein für eine optimale Gesamtdauer.

Endlichkeit der Skalierung

Die Aufteilung und die damit einhergehende Reduzierung der Run Time kann beliebig oft erfolgen. Der Testlauf lässt sich theoretisch auf beliebig viele Instanzen aufteilen. 

Die Run Time pro Instanz reduziert sich gemäß der folgenden Formel:

Wichtige Randbedingungen dabei

  • Die Skalierung hat endliche Grenzen. Es kann maximal so viele Instanzen geben, wie es Testfälle gibt. Ein Testfall ist de facto atomar und ist somit nicht auf mehrere Instanzen weiter aufteilbar.
  • Eine unendliche Skalierung ist nicht sinnvoll; spätestens wenn die eigentliche Run Time einer Instanz in der Nähe des Overhead, also Start Up plus Shut Down, ist, steigen die Kosten weiter an, ohne dass es einen noch merkbaren Nutzen gibt, im Sinne einer kürzerer Dauer.

Rechenbeispiel

Angenommen der Overhead beträgt fünf Minuten und er ist bei einer und zwei Instanzen identisch.
Wichtig zu wissen ist!

Je höher die Ausführungsdauer von Tests auf einer Cloud-Instanz, desto eher lohnt sich eine Ausführung mit mehreren Cloud-Instanzen.

Ist die Run Time bereits zum Start gering (5 min-Fall), gibt es bei der Aufteilung auf zwei Instanzen einen Zeitgewinn von 25 Prozent. Die Kosten für den Betrieb sind allerdings 50 Prozent höher.
  • Das lohnt sich nicht.
Ist die Run Time allerdings sehr hoch (72h-Fall), ergibt sich bei der Aufteilung auf zwei Instanzen bereits einen Zeitgewinn von 49,94 Prozent. Die Kosten steigen um 0,12 Prozent.
  • Das lohnt sich auf jeden Fall.

Optimale Kosten-Nutzen-Berechnung der Skalierung

Neben Mehrkosten bringt die Skalierung auch den Vorteil schnellerer Testergebnisse. Und das hat ganzheitliche positive Effekte auf die gesamte Software-Entwicklung. Wie genau sich diese Effekte finanziell auswirken, ist nicht leicht zu sagen, auch weil die Berechnung der Total Cost je Produkt und Organisation generell sehr individuell ist.

These als Annährung

Eine Halbierung der Wartezeit bzw. Dauer bis zur Verfügbarkeit von Testergebnissen führt zu einem Effizienzgewinn von mindestens 10 Prozent der gesamten System- und Softwareentwicklungs-aufwände im Automobilbau.

Gründe

Wird ein Fehler schnell behoben, taucht dieser nicht in späteren Integrationsstufen auf (Rule-Of-Ten). Worst-Case Fehler wird in höheren Integrationen so eingeflochten, dass nur mit sehr hohem Aufwand in mehreren Bestandteilen behoben werden kann.

Sind Testergebnisse schnell verfügbar, kann bei einem auftretenden Fehler, der Entwickler diesen binnen kurzer Zeit fixen – ohne Neueinarbeitung und ohne Re-Fokussierung von bereits anderen gestarteten Arbeiten.

Fallbeispiel

Die aktuelle Ausführungszeit eines Testlaufs von 3 Tagen soll auf 1 Stunde reduziert werden.

Es ist klar, dass die Kosten steigen werden. Aber auf welchen Wert sollte nun optimiert werden? Dafür gibt es mindestens diese Optionen: Vorgabe der maximalen Ausführungszeit und Vorgabe der maximalen Kosten.

Spannend ist, dass beides direkt miteinander korreliert.

Um das ideale Kosten-Nutzen Optimum zu berechnen, braucht es:

  • Messungen der Start Up und Shut-Down Zeiten
  • mind. eine Messung der Run Time aller Tests mit einer Instanz.
  • Kostenmodelle der gewünschten Instanzen

Die Kalkulationstabelle gibt es hier zum Download.

Mit jeder zusätzlichen Instanz kann die Ausführungszeit pro Instanz verringert werden. 

In Orange dargestellt ist die zeitliche Ersparnis mit mehreren Instanzen gegenüber der Ausführung mit einer Instanz. Mit jeder Instanz steigen die Kosten (blau) an. Die rote Schraffierung zeigt den Bereich an, in dem der zusätzliche Zeitgewinn in % geringer ist als die zusätzliche Kosten in %.

Spätestens ab dem Erreichen der roten Fläche lohnt sich eine zusätzliche Instanz nicht mehr.

Ob diese Werte auch in der Praxis jeweils umsetzbar sind, kommt individuell auf die Entwicklung, die IT und die Tests im Unternehmen an.

Technische Grenzen der Skalierung

Atomizität von Testfällen

Die maximal mögliche Skalierung hängt von der Ausführungsdauer jedes einzelnen Testfalls ab. Je schneller ein Testfall auf einer Maschine ausgeführt werden kann, desto weniger muss diese Grenze beachtet werden.

Die Ausführungszeit eines typischen open-loop Unit-Test dauert mit TPT etwa 1ms.
Werden komplizierte, sehr rechenintensive Testfälle mit 3D-Umgebungssimulations-Modellen, wie z. B. TPT + CarMaker, ausgeführt, kann ein solcher Testfall auch 30min und länger dauern. Der Grund sind die Simulation von z. B. mehrfachen Spurwechsel auf der Autobahn, hohen Sampleraten (10ms) und eine lange Szenariodauer (15 min).

Leider sind letztere Art von Tests nicht ohne Aufwand weiter aufteilbar und können somit auch nicht auf mehrere Instanzen aufgeteilt werden. In dem Fall kann man:

  • die Grenzen akzeptieren
  • eine schnellere EC-2 Instanz nutzen, um die Ausführungszeit zu beschleunigen
  • Testdesign geschickt ändern, indem man Testaspekte eines Testfalls in mehrere Testfälle aufteilt, um die Laufzeit eines Testfalls zu verkürzen

Es gilt immer: eine Instanz kann nicht weniger als mindestens einen Testfall zur Ausführung übergeben bekommen.

Bestimmung der Timings für Startup & Shutdown und Ausführung

Diese Zeiten sind variabel. Messung von vorherigen Ausführungen sind Indikationen. Änderungen an SUT und Testdesign sind nur mit hohem Aufwand hinsichtlich der Auswirkung auf die Ausführungszeiten ermittelbar.

Eine erste Näherung: immer auf Basis des letzten Testlaufs Schätzungen vornehmen und für kritische Zeiten Puffer einplanen.

Achtung

Insbesondere die Zeiten für die Testausführungen können sich durch kleinere Änderungen am Code oder am Testdesign ändern. Leider kann man die exakten Timings erst bei der Ausführung messen.

Wichtig ist, die Timings zu beobachten und die Aufteilung von Tests bei erkannten Veränderungen so anzupassen, dass eine möglichst genaue Gleichverteilung vorliegt, sprich, dass alle Instanzen gleich lang laufen.

zurück zu den Kosten

weiter zu Betriebsstrategien

© 2023 Synopsys, Inc.       Alle Rechte vorbehalten