Mit Spot Instances sparen Sie bis zu 90 % der Compute-Kosten. Wir zeigen, was Spot Instances sind, warum Sie sie einsetzen sollten und wann sich das lohnt.
Obwohl sie die Compute-Kosten um 20 bis 80 % senken und nebenbei für widerstandsfähigere Anwendungen sorgen können, werden Spot Instances (oder Spot VMs in Google Cloud) längst nicht so häufig genutzt, wie sie es verdient hätten.
Die Gründe reichen von der schwer vorhersehbaren Verfügbarkeit über die Sorge vor Unterbrechungen einzelner workloads bis hin zur Komplexität bei Einrichtung und Verwaltung. Der häufigste Grund, warum viele auf Spot Instances verzichten, ist jedoch schlicht fehlende Vertrautheit mit dem Thema.
Wer diese vermeintlichen Hürden zu nehmen weiß, kann bislang ungenutzte Einsparpotenziale bei der Rechenleistung heben.
In dieser zweiteiligen Serie erfahren Sie alles, was Sie wissen müssen, um das volle Potenzial von Spot Instances auszuschöpfen.
In Teil eins klären wir, was Spot Instances sind, warum Sie sie nutzen sollten und wann ihr Einsatz sinnvoll ist. In Teil zwei zeigen wir, wie Sie die Auslastung von Spot Instances mit Auto Scaling Groups optimieren und mit Spot Scaling Ihre Einsparungen maximieren.
Was sind Spot Instances?
Spot Instances sind ein bisschen wie günstige Last-Minute-Flüge, die durch kurzfristige Stornierungen oder unverkaufte Plätze frei werden. Fluggesellschaften senken die Preise oft deutlich, um diese leeren Sitze noch vor dem Abflug zu füllen.
Bei Compute-Instanzen funktioniert es ähnlich: Cloud-Anbieter geben ungenutzte On-Demand-Rechenressourcen mit Rabatten von bis zu 90 % gegenüber regulären On-Demand-Instanzen ab, um ihre überschüssigen Kapazitäten zu verwerten.
Sie legen einfach einen Bid-Preis für die Spot Instance fest – den Höchstbetrag, den Sie pro Stunde zu zahlen bereit sind – und solange der Spot-Preis (der aktuelle Preis am Spotmarkt) unter Ihrem Bid-Preis liegt, läuft die Instanz.
Allerdings kann der Cloud-Anbieter Spot Instances mit nur zwei Minuten Vorlauf zurückfordern, wenn die Nachfrage nach regulär bepreisten On-Demand-Instanzen steigt – was Ihre Anwendung unterbrechen kann.
Spot Instances und Flugtickets haben eines gemeinsam: Beide bieten die Chance, etwas (Rechenleistung im einen, einen Flug im anderen Fall) zum reduzierten Preis zu bekommen. Beides ist aber mit Unsicherheit und einem gewissen Risiko verbunden – Spot Instances können zurückgefordert werden, sobald der Marktpreis Ihren Bid übersteigt, und Last-Minute-Tickets sind weg, sobald jemand anderes sie schneller bucht.
Unterbrechungen treten am häufigsten in zwei Situationen auf:
- Wenn die Nachfrage nach On-Demand- oder Reserved Instances stark steigt
- Wenn Spot-Preise über den Bid steigen (heute weniger wahrscheinlich)
Warum Sie Spot Instances einsetzen sollten (Tipp: Es geht nicht nur um Kosten)
Die möglichen EC2-Einsparungen (bis zu 80 %!) werden gerne als Hauptvorteil von Spot Instances ins Feld geführt – sie sind aber bei Weitem nicht der einzige.
Spot Instances machen Anwendungen nicht von sich aus widerstandsfähiger – sie setzen aber häufig voraus, dass Anwendungen bereits ein gewisses Maß an Resilienz mitbringen, um die möglichen Unterbrechungen sinnvoll abzufedern.
Da Anwendungen auf Spot Instances idealerweise so gebaut sein sollten, dass sie Unterbrechungen souverän verkraften, sollten Sie sie ohnehin schon mit Checkpoints, Auto-Save-Mechanismen oder einer Verteilung der workloads auf mehrere Instanzen entworfen haben.
So profitiert Ihre Infrastruktur dreifach:
- Sie verkraftet Schwankungen besser,
- Sie hält die Performance auch zu Spitzenzeiten aufrecht und
- Sie minimiert Risiken durch potenzielle Unterbrechungen oder Ausfälle.
Bei Lastspitzen lassen sich Spot Instances einbinden, um die zusätzliche Nachfrage abzufangen – so bleibt Ihr System auch bei schwankendem Traffic oder workload performant.
Mit günstigeren Instanzen können Sie zudem mehr Ressourcen in Redundanz und Failover-Mechanismen stecken und workloads auf mehr Instanzen verteilen.
Fällt eine Instanz aus, übernehmen die anderen die Verarbeitung – der Einfluss eines einzelnen Ausfalls bleibt minimal. So wechseln Ihre workloads nahtlos auf eine andere Instanz, ohne dass die Kosten merklich steigen.
EC2 Instance Pools verstehen
Um AWS Spot Instances optimal zu nutzen, sollten Sie das Konzept der EC2 Instance Pools verstehen. Ein EC2 Instance Pool bezeichnet die Gesamtkapazität eines Instanztyps (z. B. m5.xlarge) in einer bestimmten Region.
Gibt es ungenutzte Kapazität in einem Instance Pool, spricht man von einem Spot Capacity Pool.
Jede Instanzfamilie, jede Instanzgröße, jede Availability Zone und jede Region hat ihre eigenen EC2 Instance Pools – und damit auch eigene Spot Capacity Pools.
Setzen Sie deshalb nicht alles auf eine Karte. Je mehr Pools Sie anzapfen, desto breiter wird Ihre Auswahl an möglichen Instanzen – und desto geringer das Risiko, dass für Ihre Anwendung gerade keine Spot Instances verfügbar sind.
Wann Sie Spot Instances einsetzen sollten
Generell eignen sich Spot Instances am besten für workloads, die:
- flexibel sind,
- keine festen zeitlichen Anforderungen haben,
- verteilbar sind bzw. in parallel laufende Aufgaben aufgeteilt werden können und
- Unterbrechungen tolerieren.
Auf konkrete Anwendungsfälle gehen wir gleich ein. Drei Fragen helfen Ihnen aber schon vorab einzuschätzen, ob Ihre workloads für Spot Instances geeignet sind:
- Sind meine workloads fehlertolerant?
Da Spot Instances unterbrochen werden können, müssen workloads so entworfen sein, dass Unterbrechungen weder kritische Fehler noch Datenverlust nach sich ziehen. Fehlertolerante workloads laufen weiter oder erholen sich schnell, wenn Instanzen unterbrochen oder beendet werden. 2. Lässt sich der workload in < 2 Minuten stoppen? workloads müssen sich innerhalb kurzer Zeit anhalten lassen, um Datenverlust oder Störungen zu vermeiden. Wenn sich Ihr workload in unter zwei Minuten stoppen lässt, können Sie auf Unterbrechungen von Spot Instances deutlich besser reagieren. Aus diesem Grund sind zustandslose (stateless) Anwendungen besonders gut geeignet – sie speichern keine Sitzungsdaten und können nahtlos zwischen Instanzen migrieren, ohne dass Funktionalität oder Daten verloren gehen. 3. Bin ich flexibel bei Instanztypen und Availability Zones? Wenn Sie Ihre workloads über mehrere Instanzen und Availability Zones verteilen, sinkt die Anfälligkeit für Unterbrechungen, weil Sie das Risiko streuen. Denken Sie daran: Kapazität ist eine Eigenschaft des jeweiligen Spot Instance Pools. Jeder Instanztyp in jeder Availability Zone bildet einen eigenen Pool. Wenn Sie mehrere Pools nutzen, ist das Risiko, dass alle gleichzeitig keine Kapazität haben, deutlich geringer als bei nur einem Pool. Eine Verteilung über mehrere Availability Zones reduziert die Abhängigkeit von einem einzelnen Pool und sichert die Verfügbarkeit, selbst wenn eine Zone an Kapazitätsgrenzen oder Preisspitzen stößt.
Konkret sollten Sie Spot Instances in den folgenden Situationen in Betracht ziehen.
Test-Umgebungen und CI/CD
Test- und Dev-Umgebungen sowie CI/CD-Aufgaben benötigen in der Regel keine durchgehende Verfügbarkeit, da sie nur zeitweise für bestimmte Features oder zum Testen von Änderungen genutzt werden. Außerdem lassen sich Entwicklungs- und Testaufgaben ohne kritischen Datenverlust neu starten oder pausieren und fortsetzen (sofern entsprechend geplant) – sie sind also robust gegenüber Unterbrechungen.
Diese workloads sind oft flexibel bei den Ressourcenanforderungen und passen sich problemlos an unterschiedliche Instanztypen oder Availability Zones an, ohne dass die laufende Arbeit darunter leidet.
Batch-Verarbeitung
Batch-Processing- und ETL-Jobs sind oft nicht zeitkritisch – diese Flexibilität macht Spot Instances zur idealen Wahl.
Solche Aufgaben lassen sich außerdem in kleinere, unabhängige Einheiten zerlegen, die auf mehrere Instanzen verteilt werden können – fällt eine Instanz aus, hat das kaum Auswirkungen.
Eine Unterbrechung einer einzelnen Instanz verzögert so nicht die gesamte Verarbeitung, weil die Arbeit auf andere verfügbare Instanzen verteilt werden kann. Sind keine Instanzen verfügbar, lassen sich Jobs so strukturieren, dass sie Zwischenstände speichern und nach einer Unterbrechung am letzten Checkpoint fortsetzen.
High-Performance Computing (HPC) und Big-Data-Verarbeitung
Beim High-Performance Computing geht es um die Verarbeitung und Analyse riesiger Datenmengen. Spot Instances passen hier perfekt, weil sich solche Aufgaben auf viele Instanzen verteilen und einfach hoch- und herunterskalieren lassen.
In der Regel sind diese Aufgaben kostenintensiv, da die Verarbeitung großer Datenmengen erhebliche Compute-Ressourcen erfordert. Mit Spot Instances liegen die Kosten pro Instanz jedoch deutlich niedriger – bei tausenden Instanzen summiert sich das schnell zu erheblichen Einsparungen.
Webserver
Webserver sind hervorragende Kandidaten für Spot Instances, weil sie meist stateless sind. Sie speichern in der Regel keine Daten lokal und sind nicht auf Informationen aus früheren Sitzungen angewiesen – eine Unterbrechung hat daher kaum Auswirkungen.
Bei Webservern wird in vielen Fällen jede Anfrage unabhängig verarbeitet, ohne auf gespeicherte Sitzungsinformationen zurückzugreifen.
Containerisierte workloads / Kubernetes
Containerisierte Anwendungen sind häufig stateless ausgelegt – und damit gute Kandidaten für Spot Instances.
Da Container in der Regel keine sitzungsspezifischen Daten speichern, können neue Container hochgefahren oder beendet werden, ohne das Gesamtsystem zu beeinträchtigen.
Weil Container Anwendungen außerdem in kleinere, unabhängige Einheiten aufteilen, lassen sich containerisierte workloads leicht an verschiedene Instanztypen oder Availability Zones anpassen. Diese Flexibilität passt perfekt zur variablen Natur von Spot Instances.
Damit haben wir alles abgedeckt, was Sie über Spot Instances wissen müssen – vom Konzept über den effektiven Einsatz bis zu den Use Cases, in denen Sie deren Vorteile am besten ausschöpfen.
In Teil zwei der Serie behandeln wir Auto Scaling Groups (ASGs), mit denen Sie Spot-Unterbrechungen abfangen und die Auslastung optimieren, sowie Spot Scaling, das die Konfiguration und Verwaltung von ASGs vereinfacht – damit Sie sowohl Spot-Einsparungen als auch Anwendungsverfügbarkeit maximieren.