Green Software Patterns

Die Green Software Foundation hat begonnen, an Green Software Patterns zu arbeiten.

Da wir in hohem Maße mit den Zielen der Green Software Foundation übereinstimmen, möchten wir einige dieser Muster, angewendet im Kontext von DownToZero.Cloud, allen zur Kenntnis bringen.

• Green Software Patterns

Künstliche Intelligenz (KI)

https://patterns.greensoftware.foundation/catalog/ai/

Da wir keine KI-bezogenen Dienste anbieten, überspringen wir diesen Abschnitt des Katalogs.

Cloud

https://patterns.greensoftware.foundation/catalog/cloud/

Statische Daten cachen

Aus Sicht der Energieeffizienz ist es besser, den Netzwerkverkehr zu reduzieren, indem die Daten lokal über einen Cache gelesen werden, anstatt sie remote über das Netzwerk abzurufen.

Wir cachen bei vielen Instanzen während der Verarbeitung von Anfragen, z.B. cached unsere asynchrone Job-Laufzeit Docker-Images lokal, sodass bei jedem Aufruf kein kompletter Pull notwendig ist.

Wir verwenden auch so oft wie möglich Image-Hashes für Container-Images, um die Echtzeitbelastung beim Start neuer Container zu reduzieren.

Wähle die Region, die den Nutzern am nächsten ist

Aus Sicht der Energieeffizienz ist es besser, die Entfernung zu verkürzen, die ein Netzwerkpaket zurücklegen muss, damit weniger Energie für die Übertragung benötigt wird. Ebenso sind wir aus Sicht der verkörperten Kohlenstoffemissionen effizienter, wenn ein Netzwerkpaket weniger Rechenausrüstung durchläuft.

Da wir nicht multi-regional sind oder die regionale Infrastruktur nicht direkt offenlegen, kann dies von einem Nutzer nicht beeinflusst werden. Intern versuchen wir, die Regionalität so weit wie möglich zu optimieren, ohne Haltbarkeit und Verfügbarkeit zu beeinträchtigen.

Gespeicherte Daten komprimieren

Das Speichern zu vieler unkomprimierter Daten kann Bandbreite verschwenden und die Anforderungen an die Speicherkapazität erhöhen.

Wir verpflichten uns, nur komprimierte Daten zu speichern.

Sowohl das Objectstore als auch die Container Registry unterstützen Kompression auf Speicherebene. Dies ist in beiden Diensten integriert.
Der Observability-Dienst besitzt einen internen Tiering-Mechanismus, der Daten nach einer festgelegten Aufbewahrungszeit von einem heißen Speicher-Tier in ein kälteres, besser komprimiertes Format verschiebt.

Übertragene Daten komprimieren

Aus Sicht der Energieeffizienz ist es besser, die Größe der übertragenen Daten zu minimieren, damit weniger Energie benötigt wird, weil der Netzwerkverkehr reduziert ist.

Containerisiere deine Workloads

Container erlauben eine flexiblere Ressourcennutzung, da Workloads einfach zwischen Maschinen verschoben werden können. Container ermöglichen Bin-Packing und benötigen weniger Rechenressourcen als virtuelle Maschinen, was eine Reduzierung unnötiger Ressourcenzuweisungen und eine bessere Auslastung der Rechenressourcen bedeutet.

Wir unterstützen nur containerisierte Workloads. Die Möglichkeit, Workloads zwischen Standorten zu verschieben, ist Kernbestandteil von DTZ, um Workloads bedarfsgerecht in effizientere Ausführungsumgebungen zu verlagern.

Nicht genutzte Speicherressourcen löschen

Aus Sicht der verkörperten Kohlenstoffemissionen ist es besser, nicht genutzte Speicherressourcen zu löschen, damit wir effizient mit Hardware umgehen und die Speicherebene für die Aufgabe optimiert bleibt.

Unser Objectstore unterstützt Ablauffristen für Objekte, sodass jede Entität bereinigt werden kann, wenn sie nicht mehr verwendet wird. Unsere Container Registry führt ebenfalls konfigurierbare Bereinigungsjobs aus, um die Anzahl gespeicherter Objekte zu reduzieren.

Nur das Nötige verschlüsseln

Datenschutz durch Verschlüsselung ist ein wichtiger Aspekt unserer Sicherheitsmaßnahmen. Der Verschlüsselungsprozess kann jedoch auf mehreren Ebenen ressourcenintensiv sein. Erstens variiert der CPU-Bedarf zum Verschlüsseln je nach verwendetem Algorithmus, wobei komplexere Algorithmen mehr Rechenleistung benötigen. Zudem kann Verschlüsselung den Speicherbedarf erhöhen, da die Daten aufgebläht werden durch zusätzliche Metadaten und Padding, was besonders bei kleinen Dateien auffällt. Verschlüsselung ist außerdem eine wiederkehrende Tätigkeit, die bei jedem Abruf oder Update von Daten durchgeführt werden muss, was vor allem in hochfrequenten Systemen zu erhöhtem Energieverbrauch beitragen kann.

Andere CPU-Architekturen evaluieren

Anwendungen werden mit einer Software-Architektur gebaut, die dem Geschäftsbedarf am besten entspricht. Cloud-Anbieter erleichtern die Evaluierung anderer CPU-Typen, wie x86-64, die zusammen mit zahlreichen kosteneffizienten Alternativen mit gutem Leistungsverhältnis Watt berücksichtigt werden können.

Wir unterstützen derzeit nur eine CPU-Architektur, X86. Derzeit haben wir nicht die Ressourcen, um verschiedene Architekturen zu evaluieren.

Service Mesh nur bei Bedarf einsetzen

Ein Service Mesh setzt zusätzliche Container für die Kommunikation ein, typischerweise im Sidecar-Pattern, um mehr operationale Fähigkeiten bereitzustellen. Dies kann zu einer Erhöhung der CPU-Nutzung und des Netzwerkverkehrs führen, ermöglicht aber eine Entkopplung der Anwendung von diesen Fähigkeiten, welche so von der Anwendungsschicht in die Infrastrukturschicht ausgelagert werden.

Da unser Netzwerk nicht auf Kubernetes-Abstraktionen beruht, haben wir auch keinen Bedarf für ein Service Mesh.

TLS am Border Gateway terminieren

Transport Layer Security (TLS) sorgt dafür, dass alle Daten zwischen Webserver und Browser privat und verschlüsselt bleiben. Das Terminieren und Neuaufbauen von TLS-Verbindungen erhöht jedoch die CPU-Auslastung und kann in bestimmten Architekturen unnötig sein.

Zustandsfreie Architektur implementieren

Service-Zustand umfasst in-memory oder auf Festplatte gespeicherte Daten, die ein Service zum Funktionieren benötigt. Der Zustand umfasst Datenstrukturen und Member-Variablen, die der Service liest und schreibt. Je nach Architektur kann der Zustand auch Dateien oder andere auf der Festplatte gespeicherte Ressourcen einschließen.

Unsere existierenden Services, wie Container Services und Container Jobs, basieren auf zustandslosem Design und bieten diese Fähigkeiten auch unseren Nutzern.

Service Level Objectives auf Business-Bedürfnisse abstimmen

Wenn Serviceausfälle akzeptabel sind, ist es besser, nicht auf höchste Verfügbarkeit zu zielen, sondern die Lösung gemäß den realen Geschäftsanforderungen zu designen. Niedrigere Verfügbarkeitsgarantien können helfen, den Energieverbrauch durch geringeren Infrastrukturbedarf zu senken.

Unser SLO ist, den bestmöglichen Service zu bieten, ohne Effizienz und Nachhaltigkeit zu beeinträchtigen. Unsere Services basieren stark auf automatischem Skalieren, um stets das passende Service-Level bei minimalem Mehraufwand bereitzustellen.

Auslastungsanforderungen von virtuellen Maschinen (VMs) anpassen

Es ist besser, eine VM mit höherer Auslastung laufen zu lassen, als zwei bei geringer Auslastung, nicht nur in Bezug auf Energieproportionalität, sondern auch hinsichtlich verkörperter Kohlenstoffemissionen.

Bislang bieten wir keine VM-basierten Dienste an. Unsere gesamte Infrastruktur basiert auf Containern, um ein schlankeres Erlebnis zu ermöglichen.

Auslastungsanforderungen mit vorkonfigurierten Servern abstimmen

Es ist besser, eine VM mit höherer Auslastung laufen zu lassen, als zwei bei geringer Auslastung, nicht nur in Bezug auf Energieproportionalität, sondern auch hinsichtlich verkörperter Kohlenstoffemissionen.

Wir streben eine hohe Auslastung unserer Infrastruktur an, diese Komponenten sind jedoch nicht für Endnutzer sichtbar. Nutzer sehen nur Container als Abstraktion. Da wir Metriken zur Energieeffizienz bereitstellen, können diese je nach Auslastung der zugrundeliegenden Infrastruktur variieren.

Gesamtanzahl der bereitgestellten Umgebungen minimieren

In einer Anwendung kann es notwendig sein, mehrere Umgebungen im Workflow zu nutzen. Typischerweise wird eine Entwicklungsumgebung für regelmäßige Updates genutzt, während Staging- oder Testumgebungen sicherstellen, dass keine Probleme auftreten, bevor Code in die Produktionsumgebung gelangt, auf die Nutzer Zugriff haben.

Speicherplatznutzung optimieren

Es ist besser, die Speicherauslastung zu maximieren, damit die Speicherebene für die Aufgabe optimiert ist, nicht nur in Bezug auf Energieproportionalität, sondern auch hinsichtlich verkörperter Kohlenstoffemissionen.

Durchschnittliche CPU-Auslastung optimieren

CPU-Nutzung und Auslastung variieren im Tagesverlauf, manchmal stark je nach Anforderungen der Berechnung. Je größer die Abweichung zwischen durchschnittlicher und Spitzen-CPU-Auslastung ist, desto mehr Ressourcen müssen im Standby vorgehalten werden, um Verkehrsspitzen abzufangen.

Einfluss auf Kunden-Geräte und -Ausrüstung optimieren

Anwendungen laufen auf Kunden-Hardware oder werden darauf angezeigt. Die vom Kunden genutzte Hardware hat einen Kohlenstoff-Fußabdruck, der durch Produktion und den Stromverbrauch während des Betriebs entsteht. Die Optimierung von Softwaredesign und Architektur zur Verlängerung der Lebensdauer der Kundengeräte reduziert die Kohlenstoffintensität der Anwendung. Ideal ist es, wenn der Kunde die Hardware bis zum Ausfall oder bis zur Veralterung nutzen kann.

Spitzenlast bei CPU-Auslastung optimieren

CPU-Nutzung und Auslastung variieren im Tagesverlauf, manchmal stark je nach Anforderungen der Berechnung. Je größer die Abweichung zwischen durchschnittlicher und Spitzen-CPU-Auslastung ist, desto mehr Ressourcen müssen im Standby vorgehalten werden, um Verkehrsspitzen abzufangen.

Nicht dringliche Anfragen in die Warteschlange stellen

Alle Systeme haben Phasen mit hoher und niedriger Last. Aus Hardwareeffizienz-Sicht sind wir effizienter, wenn wir die Auswirkungen von Lastspitzen mit einer gleichmäßigen Auslastung der Komponenten minimieren. Aus Energieeffizienz-Sicht sind wir effizienter, wenn wir Leerlaufressourcen auf ein Minimum reduzieren.

Unser Service Container Jobs ist die Umsetzung dieses Ziels als Service innerhalb von DTZ.

Übertragene Daten reduzieren

Aus Sicht der Energieeffizienz ist es besser, die Größe der übertragenen Daten zu minimieren, damit weniger Energie benötigt wird, weil der Netzwerkverkehr reduziert ist.

Nicht genutzte Assets entfernen

Überwache und analysiere die Anwendung und die Cloud-Abrechnung, um nicht mehr genutzte oder reduzierte Ressourcen zu identifizieren.

Kubernetes-Anwendungen im Leerlauf skalieren

Um Kohlenstoffemissionen und Kosten zu reduzieren, können Dev & Test Kubernetes-Cluster Knoten (VMs) außerhalb der Bürozeiten (z.B. nachts & am Wochenende) ausschalten. => Die Optimierung erfolgt somit auf Clusterebene.

Wir bieten keine Kubernetes-basierten Dienste an.

Anwendungen im Leerlauf herunterfahren

Anwendungen verbrauchen CPU-Ressourcen, selbst wenn sie nicht aktiv genutzt werden, z.B. durch Hintergrund-Timer, Garbage Collection, Health Checks etc. Selbst wenn die Anwendung heruntergefahren ist, verbraucht die zugrundeliegende Hardware Leerlaufstrom. Dies gilt auch für Entwicklungs- und Testanwendungen oder Hardware außerhalb der Bürozeiten.

DownToZero bedeutet wie der Name sagt, dass Skalierung nach unten im Zentrum unseres Handelns steht. Daher streben wir an, dass alle Services Skalierungen nach unten ermöglichen.

Infrastruktur mit Benutzerlast skalieren

Der Ressourcenbedarf hängt von der Nutzerlast zu einem bestimmten Zeitpunkt ab. Dennoch laufen die meisten Anwendungen, ohne dies zu berücksichtigen. Das führt zu Unterauslastung und Ineffizienz.

Kubernetes-Workloads nach relevanten Nachfragemetriken skalieren

Standardmäßig skaliert Kubernetes Workloads basierend auf CPU- und RAM-Auslastung. Praktisch ist es jedoch schwierig, die Nachfragetreiber der Anwendung mit CPU- und RAM-Nutzung zu korrelieren.

Wir bieten keine Kubernetes-Dienste an.

Logische Komponenten unabhängig skalieren

Eine Microservice-Architektur kann den Bedarf an Rechenressourcen senken, da jede unabhängige Komponente entsprechend ihres eigenen Bedarfs skaliert werden kann.

Auf Sicherheitslücken scannen

Viele Angriffe auf Cloud-Infrastrukturen zielen darauf ab, bereitgestellte Ressourcen missbräuchlich zu nutzen, was zu unnötigen Nutzungsspitzen und Kosten führt.

Speicher-Aufbewahrungsrichtlinien setzen

Aus Sicht der verkörperten Kohlenstoffemissionen ist ein automatisierter Mechanismus zum Löschen ungenutzter Speicherressourcen besser, um effizient mit Hardware umzugehen und die Speicherebene für die Aufgabe zu optimieren.

Niedrig priorisierten Traffic begrenzen

Wenn Ressourcen bei hohem Verkehrsaufkommen oder hoher Kohlenstoffintensität knapp sind, erzeugt Ihr System mehr CO2-Emissionen. Mehr Ressourcen zur Unterstützung steigender Verkehrslasten verursachen mehr verkörperte Kohlenstoffemissionen und erhöhen den Stromverbrauch. Wenn bei hoher Kohlenstoffintensität weiterhin alle Anfragen bearbeitet werden, steigen die Gesamtemissionen Ihres Systems. Die Begrenzung von niedrig priorisiertem Traffic in diesen Situationen spart Ressourcen und Emissionen. Dies erfordert ein Verständnis Ihres Traffics, einschließlich der kritischen und tolerierbaren Anfragen hinsichtlich Wiederholungen und Fehlern.

Kubernetes-Cronjobs zeitlich verschieben

Die CO2-Emissionen eines Softwaresystems hängen vom Stromverbrauch der Software sowie von der Kohlenstoffintensität des eingespeisten Stroms ab. Deshalb kann es ineffizient sein, energieeffiziente Software auf einem hoch-kohlenstoffintensiven Stromnetz auszuführen.

Obwohl wir keine Kubernetes-Dienste anbieten, ermöglichen unsere Container Jobs ein flexibles Zeitplanmodell. Siehe unsere Dokumentation für mehr Informationen.

Asynchrone Netzwerkaufrufe statt synchroner verwenden

Bei Aufrufen über Prozessgrenzen hinweg zu Datenbanken, Dateisystemen oder REST-APIs kann die Verwendung synchroner Aufrufe dazu führen, dass der aufrufende Thread blockiert wird, was die CPU zusätzlich belastet.

Circuit Breaker Muster verwenden

Moderne Anwendungen kommunizieren regelmäßig mit anderen Anwendungen. Da diese eigene Deployment-Zyklen, Ausfälle und Verfügbarkeiten haben, kann die Netzwerkverbindung zu diesen Anwendungen instabil sein. Wenn die andere Anwendung nicht erreichbar ist, schlagen alle Netzwerkaufrufe fehl, und zukünftige Anfragen sind sinnlos.

Cloud-native Netzwerk-Sicherheitswerkzeuge und -Kontrollen verwenden

Netzwerk- und Webanwendungs-Firewalls schützen vor den häufigsten Angriffen und ermöglichen das Abwehren schädlicher Bots. Diese Tools helfen, unnötigen Datenverkehr zu reduzieren und die Belastung der Cloud-Infrastruktur zu minimieren, während gleichzeitig Bandbreite und Infrastrukturbedarf verringert werden.

DDoS-Schutz verwenden

Distributed Denial of Service (DDoS)-Angriffe erhöhen die Serverlast, so dass legitime Anfragen nicht mehr antworten können. Dies geschieht meist, um dem Dienst- oder Hardwareinhaber zu schaden. Aufgrund der Natur des Angriffs werden viele Umweltressourcen durch sinnlose Anfragen verbraucht.

Cloud-native Prozessor-VMs verwenden

Cloud-Virtualmaschinen basieren auf Hardwareprozessoren mit unterschiedlichen Fähigkeiten. Die Nutzung von VMs, die auf effiziente Prozessoren setzen, verbessert die Hardwareeffizienz und senkt Kohlenstoffemissionen.

Serverless-Cloud-Dienste verwenden

Serverlose Cloud-Dienste werden vom Cloud-Anbieter für die Anwendung verwaltet. Diese skalieren dynamisch mit der benötigten Arbeitslast zum Erfüllen der Service-Aufgabe und wenden Best Practices an, um den Ressourcenverbrauch minimal zu halten.

Alle Angebote von DownToZero sind serverlose Cloud-Dienste.

Web

https://patterns.greensoftware.foundation/catalog/web/

Da wir keine Web-bezogenen Dienste anbieten, überspringen wir diesen Abschnitt des Katalogs.