Zur Identifikation und Optimierung der Betriebskosten beim Testen mit parallelen Instanzen in der Cloud hilft im ersten Schritt zu verstehen, welche Stellschrauben es gibt.
Overheadzeiten spielen im Cloud Testing eine wichtige Rolle. Sie sollten so kurz wie möglich sein, um Geld sparen können. Vermieden werden sollten daher alle unnnötigen, redundanten Arbeiten und Berechnungen, sowie Kommunikationsengstellen.
Beispiele dafür:
Testrahmen werden für alle Instanzen benötigt. Deshalb ist es sinnvoll, die Erstellung in eine Instanz auszulagern und den Testrahmen in andere Instanzen zu kopieren, die erst starten, wenn der Testrahmen erstellt ist.
Größere Daten können in einen Cloud-Speicher kopiert werden, um lange Kommunikationswege zwischen Rechner und Instanz zu vermeiden.
PRO TIPP Architekturbilder (Komponentendiagramm, Ablaufdiagramm) liefern stets einen guten Überblick. Es sollte genau dargestellt sein, was genau passiert und dann eine Zeitmessung für die einzelnen Prozessschritte geschehen. |
Wie auch bei phyischen Rechnern könnte man schnell nach dem Motto “Haben ist besser als Brauchen” mehr Speicher, Rechenpower und mehr von allem in die Cloud-Rechner-Konfiguration nehmen. Beim Testing in der Cloud kann das die Kosten aber sehr schnell und vor allem unnötig in die Höhe treiben, denn nicht immer gilt: mehr Power = schnellere Performance.
Entscheidend ist am Ende nicht, schnellstmöglich zu rechnen, sondern schnellstmöglich Ergebnisse zu haben. Und dafür gibt es die Parallelisierung.
Das bedeutet, wenn zwei weniger performante Instanzen genauso schnell wie eine performante Instanz die Ergebnisse liefern und der Betrieb insgesamt günstiger ist, dann ist die günstigere Variante empfehlenswert.
PRO TIPP Experimentiere mit den verfügbaren Instanz-Typen und bestimme so die notwendigen Ressourcen für Testläufe. Mit den dabei erhobenen Daten lässt sich das Optimum aus Performance und Kosten einfach berechnen.
|
|
PRO TIPP Keine weitere Beschleunigung durch zusätzliche Instanzen, wenn eine dieser Grenzen erreicht sind:
|
Hier ist der Ansatzpunkt, eine gute Testplanung und -organisation zu haben.
Denn durch eine gute Vorausplanung lassen sich Instanzen optimal nutzen und unnötige Kosten vermeiden.
Folgendes Szenario liegt vor: Es gab eine Änderung an einer Unit. Diese soll mittels Unittest überprüft werden. Danach schließt sich prozessual ein Integrationstest an. Diesen könnte man doch gleich, um Zeit zu sparen, parallel zum Unittest laufen lassen oder? Doch das birgt ein Kostenrisiko.
Warum? Wenn der Unittest fehlschlägt, wird der Integrationstest obsolet. Man hätte Kosten produziert, für unbrauchbare Ergebnisse.
Es gibt jedoch die Möglichkeit, die Instanz für den Unittest direkt weiterzuverwenden und dadurch den Overhead, also unproduktive Zeiten einer Instanz, einzusparen: Vor Ende des Testlaufs werden geschickt die notwendigen Daten (Software, Testdaten, etc.) in die Instanz geladen und die Ausführung des Integrationstests wird angestoßen. Parallel dazu werden die Ergebnisse des Unittests heruntergeladen.
Natürlich ist hier die Frage: Wenn ich schon die Ergebnisse herunterlade, woher weiß ich, ob der Testlauf erfolgreich war? Die Lösung ist ein permanentes Überwachen der laufenden Instanz, denn die meisten Ergebnisse sind bereits vor Ende des Test bekannt. Das Risiko ist dann gering, dass ein Integrationstest schon startet und der vorherige Unittest aber fehlschlug.
Im Endeffekt ist das Mehrkostenrisiko damit nahe 0.
Das bedeutet: Genau prüfen und überlegen, wann die Testergebnisse wirklich benötigt werden.
Warum viele Instanzen nutzen, um Testergebnisse innerhalb einer Stunde zu erhalten, wenn diese zu dem Zeitpunkt gar nicht benötigt werden. Zum Beispiel: Teststart am Freitagabend – um 18 Uhr – und Ergebnisse werden erst im Laufe des Montags benötigt.
In CI-Umgebungen lassen sich Testläufe automatisiert organisieren. Mit der richtigen Strategie, Planung und ein wenig Geduld können Kosten massiv gesenkt werden, wie bei der Nutzung von Dauermieten.
Bei vielen Cloud-Anbietern kann man neben On-Demand auch dauerhaft Rechen-Ressourcen mieten. Es gibt mehrere Zahlungsmodelle abhängig von der gewünschten zeitlichen Bindung.
Hybride Modell sind dabei auch möglich: zum Beispiel indem die Grundlast durch Dauermieten abgedeckt wird und On-Demand durch zusätzliche Instanzen nach Bedarf. Die Kostenersparnis ist gegenüber der Spot-Instanzen natürlich deutlich geringer, aber dafür ist das Setup weniger aufwändig.
Was sind Spot-Instanzen?
AWS bietet mit Spot-Instanzen eine Lösung für ungenutzte Rechenkapazitäten, denn selten ist ein Rechenzentrum komplett ausgelastet. Spot-Instanzen werden mit einem Rabatt von 80 Prozent oder mehr angeboten. Allerdings besteht das Risiko, dass diese Instanzen zugunsten zahlender Kunden abgebrochen werden. Je nach EC-2-Typ liegt die Wahrscheinlichkeit dafür bei 20 Prozent.
Wie beeinflusst die Verwendung von Spot-Instanzen die Gesamtkosten?
Für eine bessere Einschätzung vergleichen wir die Kosten von Spot mit On-Demand-Instanzen mit den folgenden Annahmen:
Ein Abschaltrisiko von circa 20 Prozent erhöht die Anzahl notwendiger Instanzen für einen Testlauf.
80 Prozent Rabatt auf Spot-Instanzen gegenüber vergleichbarer On-Demand Instanzen.
Die Gesamtkosten für die Nutzung von Spot-Instanzen GK_Spot können über die folgende Formel berechnet werden:
Sind Instanzen von einer automatischen Abschaltung betroffen, dann hast du keine Test-Ergebnisse und du musst diese Instanzen neu starten.
Bei einem Abschaltrisiko von Risk_Shutdown > 0% hast du beim Testen mit Spotinstanzen daher immer einen Mehrbedarf an Instanzen (MBI) im Vergleich zum Testen mit On-Demand Instanzen.
Dieser Mehrbedarf an Instanzen (MBI) beschreibt das Verhältnis von Anzahl Spot-Instanzen zu Anzahl On-Demand-Instanzen für einen vollständigen Testlauf und kann mit der folgenden Formel hinreichend genau angenähert werden:
Da die Anzahl n (notwendigen Wiederholungen von ausgefallen Spot-Instanzen) abhängig von der Anzahl Instanzen und dem Abschaltrisiko ist, nähern wir uns dem MBI mit einem mathematischen Trick an. Wir rechnen mit unendlich vielen Wiederholungen. So können wir den theoretisch maximalen MBI ermitteln.
Die Anzahl der notwendigen Instanzen für einen Testlauf werden steigen. Die Kosten für eine Spot-Instanz sind allerdings geringer als für eine On-Demand-Instanz.
Die prozentuale Einsparung ist:
Mit einem Rabatt von angenommenen 80% ist die prozentuale Kosteneinsparung 20%. Oder anders gesagt: Für den Betrieb einer Spot-Instanz zahlt man nur ein Fünftel der Kosten des Betriebs einer On-Demand-Instanz.
GK_Spot = 20% * 125 % * GK_On-Demand = 25% * GK_On-Demand.
In unserer Beispielrechnung hast du nur 1/4 der Kosten.
Oder anders gesagt: du sparst 75% der Kosten. Spot-Instanzen lohnen sich!
Die Kostenersparnis beim Testen mit Spot-Instanzen bedeutet allerdings auch, dass die Dauer eines Testlaufs durch Abbrüche und Neustarts erhöht wird.
Wie viel länger hängt hauptsächlich von der Start-Anzahl an Instanzen ab. Das lässt sich wieder mithilfe von Prozentrechnung und exponentiellem Wachstum berechnen.
Zur vereinfachten Kalkulation haben wir einen Spot-Instanzen-Rechner erstellt.
Bitte beachten, dass die Verwendung von Spot-Instanzen spezifische Risiken und Vorteile mit sich bringt. Es ist wichtig, die individuellen Anforderungen und Ressourcen der Anwendung vor der Strategieumsetzung zu berücksichtigen.
Dauer und Iterationen
Die Dauer der Nutzung von Spot-Instanzen hängt von der Anzahl der Startinstanzen ab. Durch wiederholtes Neustarten können zusätzliche Iterationen entstehen. Der genaue Zeitpunkt der Instanzabschaltungen ist ungewiss, das gleich zu Beginn oder erst am Ende passieren. Ein kontinuierliches Monitoring und automatisiertes Neustarten ist in diesem Fall sehr sinnvoll.
Kombination von Spot und On-Demand
Das Modell kann sich kostentechnisch rechnen, auch wenn die exakte Dauer ungewiss ist. Wenn man die Testergebnisse nicht sofort braucht, ist eine empfehlenswerte Strategie die Kombination von Spot- und On-Demand-Instanzen.
Dafür muss bekannt sein, wann valide Ergebnisse vorliegen sollen, zum Beispiel Montag 8:00 Uhr. Mit diesem Zeitpunkt kann rückwärtsgerechnet werden, wann mehrere parallele On-Demand-Instanzen gestartet werden müssen, um alle Testergebnisse zu erhalten. Die Zeit von Teststart bis zu diesem letztmöglichen Zeitpunkt kann für die Ausführung mit Spot-Instanzen genutzt werden. Instanzen, die im Spot-Modus bereits gelaufen sind, müssen sie nicht mit On-Demand-Instanzen rechnen. Das Setup für Planung und Überwachung ist ein wenig aufwändiger, allerdings haben sie in diesem hybriden Modell die notwendige Sicherheit und das Kostenoptimum für ihre Testausführung.
Hinweise zur Nutzung von Spot-Instanzen
Zahlungsmodelle können sich ändern
Es ist ratsam, Änderungen in den Zahlungsbedingungen zu verfolgen.
Abschaltungsraten können variieren
Die Rate der Instanzabschaltungen kann je nach Land und Zeit variieren.
Optimierung der Instanzdauer
Die Wahrscheinlichkeit des Abschaltens steigt mit der Dauer der Instanz. Eine Anpassung des Kosten-Nutzen-Optimums ist ratsam.
Automatisierung erfordert Expertise
Die Implementierung einer Automatisierung erfordert fundierte Kenntnisse, um teure Fehler zu vermeiden.
Es kann vorkommen, dass Testläufe Fehlkonfigurationen enthalten, deshalb: Instanzen überwachen.
Dauert etwas ungewöhnlich lange, sollte die Ausführung manuell oder im CI-Anwendungsfall automatisiert abgebrochen werden. Dann heißt es, die Ergebnisse sichern, die Instanzen runterfahren und das Betriebs- und Serviceteam informieren, z. B. über eine atomisierte Abbruch-Mail.
Überwache die Testausführung von Anfang an und prüfe nach jedem Testfall das Ergebnis. Schlagen viele Tests fehl, dann sollte die Ausführung abgebrochen werden. Die Ergebnisse sollten gesichert und alle Instanzen heruntergefahren werden.
PRO TIPP Einen sinnvollen Schwellwert einführen, ab dem Testläufe abgebrochen werden sollen. Schlagen sehr viele Tests fehl, stimmt in den meisten Fällen etwas nicht mit der Testausführung oder es liegt ein Major-Bug im Code vor. Für die Analyse braucht es meistens nicht alle Tests. |
Neue Teststrategien oder angepasste Methoden haben das Potenzial, Kosten und Dauer der Testausführung zu reduzieren.
Modell oder Code testen?
Es soll ein Simulink-Modell getestet werden? Erst im MiL und dann im SiL. Das klingt auf den ersten Blick nach einer guten Idee. Aber warum soll einmal das Modell und danach der generierte Code getestet werden?
Unsere Empfehlung: auf den MiL-Durchlauf verzichten und nur den Code testen.
Dabei spart man die Ausführung des Modells und die Kosten für Lizenzen und hat dennoch aussagekräftige Ergebnisse.
Maßgeschneiderte Teststrategien: Kostenlose Beratung für Ihr Produkt
Die einzige, optimale Teststrategie gibt es so nicht. Zu stark ist sie an das Produkt, die Anforderungen und die Ziele gekoppelt.
Gern helfen wir im individualen, kostenfreien Strategie-Gespräch eine passende Strategie zu entwickeln.