Green Cloud: Nachhaltig skalieren

Wenn Softwareprojekte in die Cloud gebracht werden, versprechen wir uns davon hohe Verfügbarkeit, planbare Kosten und eine immer dem Bedarf entsprechende Skalierung. Aufgrund der grenzenlosen Angebote ist es aber auch leicht, die Komponenten eines Systems zu überprovisionieren und damit mehr Ressourcen zu verbrauchen, als notwendig wären.

Nachdem ich im letzten Blogpost Ideen für eine ressourcensparende Cloud-Architektur besprochen habe, soll es dieses Mal darum gehen, wie wir die Emissionen unserer Anwendung mithilfe einer optimierten Skalierung reduzieren können. Skalierung bezieht sich hierbei auf die Bereitstellung von (Hardware-)Ressourcen und die Entscheidung, wie viele Server mit welcher Hardware-Ausstattung benötigt werden. Wie beim letzten Post liegt der Fokus ebenfalls auf der Public Cloud.

Kapazitäten reduzieren

Die Last, die ein System verarbeiten können muss, ist häufig zeitlich sehr unterschiedlich verteilt. Selbstverständlich muss ein Onlineshop 24/7 verfügbar sein, damit Kunden jederzeit einkaufen können. Wenn meine Kundschaft aber nicht weltweit verteilt ist, wird die Last auf das System in der Nacht stark sinken. Auch AWS empfiehlt, kritisch zu hinterfragen, welche Systeme herunterskaliert werden können.

Ähnliches gilt auch für die Softwareentwicklung selbst: Üblicherweise arbeiten die Teams tagsüber in einem relativ festen Zeitraum. Spätestens nachts benötigt niemand mehr den Test-Server oder die Build-Pipeline. Ein netter Nebeneffekt davon: Wenn mein Server nicht mehr läuft, kostet er auch nichts. Hier gewinnen wir also auch auf der Kostenebene, während wir einen großen Einfluss auf unseren Stromverbrauch nehmen.

Skalierung der Datenspeicher

Rechtliche Bestimmungen spielen je nach Branche eine große Rolle bei der Frage, welche Daten ein Unternehmen für welche Zeiträume speichern muss. Häufig ist die einfache Antwort dabei: „Cloudspeicher ist so günstig, lasst uns einfach alles für immer speichern“. Wenn wir aber sehr viele Daten speichern und diese nur selten aufräumen, summieren sich die Kosten schnell.

Über die Kosten lässt sich gut für eine stromsparende Reduktion der genutzten Speichersysteme argumentieren. Denn auch wenn wir keine Größe für den Cloudspeicher angeben, skalieren wir diesen indirekt durch unsere tatsächliche Nutzung. Durch regelmäßiges Löschen unserer Daten sorgen wir dafür, dass die Cloudanbieter weniger Speichermedien vorhalten müssen und reduzieren ihren Strombedarf. Es ist also aus verschiedener Sicht sehr sinnvoll, die gespeicherten Daten regelmäßig zu überprüfen und nicht mehr verwendete Daten zu löschen.

Automatisiertes Löschen der gespeicherten Daten kann dabei helfen, den Arbeitsaufwand zu reduzieren. Ein Weg sind hier Retention Policies, mit denen wir festlegen können, ab wann unsere Daten vom System entfernt werden sollen. Falls die Daten nicht gelöscht werden können, aber die Zugriffe ab einem bestimmten Zeitpunkt absehbar abnehmen, erlauben Lifecycle Policies das automatische Verschieben der Daten in andere Speichersysteme. Magnetspeicher sind dann eine gute Lösung, da sie energiesparender sind. Für Einträge in einer Datenbank lassen sich sogenannte „Time to Live“-Werte konfigurieren. Ist die Lebensdauer der Datensätze überschritten, räumt die Datenbank automatisch auf.

Hardware skalieren

Manche Anforderungen verlangen nach einem dedizierten Server. Weil die Auswahl der Cloud-Provider heutzutage sehr groß ist, ist es leicht, die stärkste Hardware zu provisionieren und mögliche Skalierungsprobleme frühzeitig mit Geld lösen zu wollen. „Sicher ist sicher“ gewinnt gegenüber der sparsamen Variante bei der Wahl der Hardware.

Mithilfe von detailliertem Monitoring eines Systems kann ich nicht nur Probleme und Fehler frühzeitig erkennen. Es lässt sich auch genauer beurteilen, wie hoch die Auslastung meiner Hardware ist. Das ermöglicht es, erst bei dauerhaftem Bedarf vertikal auf eine bessere Hardware zu skalieren.

Außerdem ist es ratsam, regelmäßig nach neuen Servermodellen Ausschau zu halten. Diese sind häufig nicht nur günstiger, sondern auch performanter. Zusätzlich haben beispielsweise die Graviton-Instanzen von AWS einen deutlich niedrigeren Energieverbrauch bei gleicher Leistung. Ein Wechsel des Instanztyps spart letztlich nicht nur Geld, sondern auch Strom.

Dynamische Skalierung

Die horizontale Skalierung auf mehrere Server ist die zweite Möglichkeit, auf dynamischen Workload zu reagieren. Wenn sich die Last auf ein System zeitlich sehr unterschiedlich verteilt, ist es besser, in die Breite zu skalieren. Statt den dauerhaft höheren Energieverbrauch der besseren Hardware auf sich zu nehmen, lassen sich kurzfristige Lastspitzen auch über eine dynamische Skalierung auf mehreren Instanzen abfangen.

Generell ist es empfehlenswert, möglichst kleine Skalierungsschritte zu konfigurieren. Damit beugen wir einer Überprovisionierung vor. Auch hier gilt: Zunächst sollte das System beobachtet und dann bedarfsabhängig optimiert werden, anstatt Probleme mit besserer Hardware zu erschlagen. Ein weiterer Vorteil von diesem Vorgehen: Selbst bei stark überprovisionierter Hardware besteht das Risiko, dass die Last alle Erwartungen übersteigt und das System überfordert ist. Wenn ein System dynamisch reagieren kann, lassen sich auch unerwartete Zugriffszahlen besser verarbeiten.

Die Skalierungsregeln sollten über die Utilization implementiert werden, um so eine optimale Auslastung der Systeme umzusetzen. Erst wenn eine Ressource eine gewisse Auslastung erreicht hat, stoßen wir die Skalierung an. Im selben Moment muss auch daran gedacht werden, die Ressourcen wieder herunter zu skalieren, wenn sie nicht mehr benötigt werden.

Spezialfall „Function as a Service“

„Function as a Service“-Angebote (FaaS) wie Azure Functions erlauben es, Code ohne Infrastruktur-Overhead in der Cloud auszuführen. Die Anbieter sorgen dafür, dass genügend Ressourcen zur Verfügung stehen, um Anfragen verarbeiten zu können. Interessant wird es, wenn eine Funktion nicht benötigt wird. Weil nach Laufzeit bezahlt wird, gibt es einen Scale-to-Zero und wir bezahlen nichts mehr.

Leider geben die Cloud-Provider kaum Informationen über die genaue Architektur und Auslastung ihrer FaaS-Angebote heraus. Eine gewisse Grundkapazität muss jedoch immer vorgehalten werden, auch wenn unsere eigene Funktion aktuell nicht genutzt wird. Da diese Serverkapazität den Usern aber nicht abgerechnet wird, ist davon auszugehen, dass die Anbieter die Auslastung so weit wie möglich optimieren. Für uns bieten FaaS-Angebote damit eine gute Möglichkeit, die Skalierung unseres Systems vollständig abzugeben.

Fazit

Generell gilt: Solange die aktuelle Last problemlos verarbeitet werden kann, können wir die kleinste Hardware-Konfiguration eines Systems laufen lassen. Für die unerwarteten Momente bietet sich eine dynamische Skalierung an. Grundvoraussetzung ist aber ein gutes Monitoring und detaillierte Kenntnis des Systems. Nur auf diese Weise können wir die Skalierung korrekt konfigurieren.

Häufig gewinnen wir mit der dynamischen Skalierung nicht nur beim Stromverbrauch. Auch die Kosten unseres Systems lassen sich auf diese Weise reduzieren. Es mag häufig nach der leichteren Lösung aussehen, statische Ressourcen zu nutzen. Aber langfristig rechnet sich ein dynamisch skalierendes System nicht nur finanziell, sondern auch bei den verursachten Emissionen unseres Systems.