Green Cloud: Ideen für eine nachhaltigere Architektur

Die ökologische Nachhaltigkeit eines Systems ist aktuell häufig noch kein Thema. Nachhaltigkeit bedeutet für mich in diesem Kontext die Reduktion der verursachten Emissionen durch gesenkten Ressourcenverbrauch – egal ob die Emissionen beim Cloudprovider im Rechenzentrum oder beim Datentransport zum User entstehen. Je früher diese Anforderung mitgedacht wird, desto einfacher kann sie schon in die Architektur einfließen.

Im Folgenden möchte ich Ideen für nachhaltige Architekturentscheidungen beschreiben und dabei auch einen Blick auf andere, nicht-funktionale Anforderungen werfen. Häufig können wir durch eine kostengünstigere oder performantere Lösung auch den Stromverbrauch unseres Systems senken. Der Fokus soll hierbei auf der Public Cloud liegen. Falls ihr ein bereits bestehendes System optimieren wollt, ist es sinnvoll, zunächst den aktuellen Verbrauch zu analysieren.

Wahl der Cloud-Region

Die erste Entscheidung vor dem Deployment einer Ressource in die Cloud ist der Standort. Heutzutage bieten alle Cloud-Anbieter ihre Services weltweit in unterschiedlichen Regions und (Availability) Zones an. Relevante Faktoren für die Wahl eines Standorts sind die Kosten und Ausfallsicherheit. Auch die Entfernung und damit die Latenz zu den Usern spielt eine Rolle.

Möchte man ein möglichst emissionsarmes Deployment der Anwendung, ist der wichtigste Faktor der Strommix vor Ort. Je nach Land und Region unterscheidet sich der Anteil erneuerbarer Energien im Strom stark. Google bietet mit dem Region Picker ein Tool an, um die Faktoren Preis, Latenz und Strommix zu gewichten und den optimalen Standort zu ermitteln. Bei den anderen Anbietern können wir mithilfe externer Services herausfinden, in welchen Regionen der Anteil erneuerbarer Energien hoch ist.

Der Strommix sollte aber nicht das einzige Argument für eine Region sein. Jedes Datenpaket gelangt über eine Vielzahl von Systemen von unserem Server zum User und zurück. Je weiter die Strecke, desto mehr Zeit wird benötigt. Aber auch der Stromverbrauch steigt durch die Länge der Strecke an. Wenn unsere Anwendung außerhalb des eigenen Systems Datenverkehr verursacht, ist uns auch dieser Stromverbrauch zuzuschreiben. Hier gilt es also, zwischen dem besseren Strommix einer Region und der Entfernung zu unseren Usern abzuwägen.

Managed Services

Bei den grundlegenden Compute- und Storage-Services haben wir aber häufig die Wahl zwischen mehreren Alternativen. Eine davon sind Managed Services: Wir können Code ohne Server und Container mit Google Cloud Functions ausführen und Datenbanken ohne Updates und Migrationen mit AWS DynamoDB betreiben.

Leider geben Anbieter kaum Informationen über Architektur und Auslastung der Managed Services heraus. Wir können uns an dieser Stelle nur darauf verlassen, dass die Serverless-Angebote auf höchste Auslastung optimiert werden. Dadurch sparen sich AWS, Azure und Co. Stromkosten und steigern ihre Marge. Wir können uns von einer höheren Auslastung weniger betriebene Hardware und damit einen geringeren Stromverbrauch erhoffen.

Generell muss der Service aber immer zuerst zum zu lösenden Problem passen. Wenn eine Funktion beispielsweise 24/7 benötigt wird, explodieren die Kosten von FaaS-Angeboten, wie AWS Lambda im Vergleich zu einer eigenen Serverinstanz schnell. Mit „As-a-Service“-Angeboten können wir aber die Verantwortung für die Auslastung unseres Systems an die Cloudprovider abgeben.

Leerlauf reduzieren

Wir alle kennen Test- und Entwicklungssysteme, die 24/7 betrieben werden – auch wenn niemand mit ihnen arbeitet. Ressourcen, die nicht benötigt werden, sollten alleine schon aus Kostengründen heruntergefahren werden. Dies reduziert auch den Stromverbrauch und damit die ausgestoßenen Emissionen. Dadurch können wir einen großen Einfluss nehmen, da viele Server im Leerlauf auf Arbeit warten.

Verarbeitet unser System nicht zeitkritische Workloads, können wir hier ebenfalls ansetzen. Ein typisches Beispiel sind Batchjobs, die in der Nacht aufwendige Berechnungslogiken durchführen. Wir können diese Workloads zeitlich verlagern und so Kosten sparen, da die Cloudprovider ihre Server günstiger anbieten, wenn die Auslastung gering ist. Ein Beispiel sind die EC2-Spot-Instanzen von AWS. Gleichzeitig erhöhen wir auch die Chancen für einen emissionsärmeren Strommix, wenn wir unsere Arbeit abseits von Industrie und Haushalten ausführen. Um den Strombedarf von Lastspitzen zu decken, muss häufig Strom aus nicht erneuerbaren Quellen hinzugenommen werden. Die Chance dafür können wir mit diesem Vorgehen verringern.

Mit Services wie der Electricity Map können wir noch dynamischer auf den aktuellen Strommix einer Region reagieren. Damit lassen sich Ort und Zeit für eine möglichst ressourcensparende Ausführung von Workloads ermitteln, die nicht zeitkritisch sind. Diese Lösung ist erstmal sehr komplex in der Umsetzung – erlaubt es dann aber, auf aktuelle Bedingungen zu reagieren und den nachhaltigsten Strommix zu nutzen.

Auch die asynchrone Verarbeitung mithilfe einer Queue ist eine Möglichkeit, den eigenen Stromverbrauch zu optimieren. Anstatt bei hoher Last zusätzliche Instanzen hochzufahren, kann eine Queue die Anfragen abpuffern. Dadurch umgehen wir eine Überprovisionierung, um unerwartete Lastspitzen auf dem Server verarbeiten zu können.

Komponenten skalieren

Individuelle Skalierung kann aber auch einen Schritt früher anfangen. Wieso sollten wir das gesamte System dauerhaft laufen lassen, wenn eigentlich nur ein kleiner Teil ständig genutzt wird?

Google empfiehlt, Microservices zu implementieren, falls Teile des Systems unterschiedlich stark genutzt werden. Beispielsweise wird ein login-service nur initial gebraucht, um eine Session zu starten. Im Anschluss benötigen die User den search-service aber häufig, um Produkte zu finden und den basket-service, um diese in den Einkaufswagen zu legen. Aber egal ob Microservices, Monolith oder etwas dazwischen – wir müssen die Nutzungsprofile unserer Systemkomponenten kennen. Nur dann können wir die beste Kombination von “as a service”-Angeboten und dedizierten Servern wählen, um das Problem zu lösen.

Spezialisierte Services helfen uns aber nicht nur dabei, die Performance zu verbessern, indem einzelne Komponenten schneller und stärker skaliert werden können. Auch für den Stromverbrauch hat dieser Ansatz Vorteile: Wir können Instanzen der Services – und damit auch den Stromverbrauch – herunterfahren. Die Kosten reduzieren wir damit gleich mit.

Fazit

Wir können bereits beim Entwurf einer Architektur darauf achten, ein nachhaltigeres Fundament aufzustellen. Dabei muss es nicht unbedingt auf ein „entweder – oder“ hinauslaufen. Häufig gewinnen wir im Falle einer nachhaltigen Entscheidung auch auf der Kosten- und Performance-Ebene.

Aktuell gibt es noch große Unterschiede beim Strommix in unterschiedlichen Regionen. Über „As-a-Service“-Angebote kann die Verantwortung für eine optimale Auslastung der Ressourcen an die Provider abgegeben werden. Wenn Optimierungen wie diese zu den anderen Anforderungen an ein System passen, lassen sich Emissionseinsparungen auf einfache Weise umsetzen.

Nicht jedes Projekt wird von Anfang an möglichst sparsam entworfen. Aber auch im Nachhinein lassen sich Optimierungen umsetzen. Die Grundlage hierfür ist ein gutes Monitoring der Kosten und der Performance eines Systems. Dadurch bekommen wir Hinweise für weiteres Optimierungspotential. Diese Potentiale betrachten wir im nächsten Teil der „Green Cloud“-Serie, wenn wir uns die Skalierung des Systems genauer anschauen.