Green Software Patterns

The Green Software Foundation begann mit der Arbeit an Green Software Patterns.

Da wir in hohem Maße mit den Zielen der Green Software Foundation übereinstimmen, wollten wir einige dieser Muster im Kontext von DownToZero.Cloud zur Aufmerksamkeit aller bringen.

• Green Software Patterns

Artificial Intelligence (AI)

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

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

Cloud

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

Cache static data

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

Wir verwenden Caches in vielen Fällen bei der Verarbeitung von Anfragen, z. B. cached unsere asynchrone Job-Laufzeit Docker-Images lokal, sodass wir bei jeder Invocation keinen vollständigen Pull benötigen.

Wir verwenden außerdem, soweit möglich, Image-Hashes für Container-Images, um die Echtzeitbelastung beim Starten neuer Container zu reduzieren.

Choose the region that is closest to users

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 erforderlich ist. Ebenso gilt aus Sicht des verkörperten CO2: Wenn ein Netzwerkpaket durch weniger Rechenequipment läuft, sind wir effizienter hinsichtlich der Hardware.

Da wir nicht multi-regional sind oder das regionale Layout unserer Infrastruktur nicht direkt für den Nutzer offenlegen, kann dies nicht vom Nutzer beeinflusst werden. Intern versuchen wir, so weit wie möglich regional zu optimieren, ohne Langlebigkeit und Verfügbarkeit zu opfern.

Compress stored data

Das Speichern zu vieler unkomprimierter Daten kann zu Bandbreitenverschwendung führen und den Speicherbedarf erhöhen.

Wir sind verpflichtet, Daten nur komprimiert zu speichern.

Sowohl Objectstore als auch das Container-Registry unterstützen Kompression auf Speicherebene. Dies ist in beide Dienste integriert. Der Observability-Dienst verfügt über einen internen tiering-Mechanismus, der Daten nach einer festen Aufbewahrungsfrist von einer Hot-Storage-Ebene in ein kälteres, besser komprimiertes Format verschiebt.

Compress transmitted data

Aus Sicht der Energieeffizienz ist es besser, die Übertragungsgröße der Daten zu minimieren, damit weniger Energie benötigt wird, da der Netzwerkverkehr reduziert wird.

Containerize your workloads

Container erlauben eine flexiblere Nutzung von Ressourcen, da Workloads einfach zwischen Maschinen verschoben werden können. Container ermöglichen Bin-Packing und benötigen weniger Rechenressourcen als virtuelle Maschinen, was eine Reduktion unnötiger Ressourcenallokation und eine Erhöhung der Auslastung der Rechenressourcen bedeutet.

Wir unterstützen ausschließlich containerisierte Workloads. Die Fähigkeit, Workloads zwischen Standorten zu verschieben, ist zentral für DTZ, um das Verschieben von Workloads in effizientere Ausführungsumgebungen auf Abruf zu ermöglichen.

Delete unused storage resources

Aus Sicht des verkörperten CO2 ist es besser, ungenutzte Speicherressourcen zu löschen, damit wir effizient mit Hardware umgehen und die Speicherschicht für die Aufgabe optimiert ist.

Unser Object-Store unterstützt Ablauffristen für Objekte, sodass jede Entität aufgeräumt werden kann, wenn sie nicht mehr verwendet wird. Unser Container-Registry führt ebenfalls konfigurierbare Aufräumjobs aus, um die Menge gespeicherter Objekte zu reduzieren.

Encrypt what is necessary

Datenschutz durch Verschlüsselung ist ein entscheidender Bestandteil unserer Sicherheitsmaßnahmen. Der Verschlüsselungsprozess kann jedoch auf mehreren Ebenen ressourcenintensiv sein. Erstens variiert die für die Verschlüsselung benötigte CPU-Menge je nach gewähltem Algorithmus, und komplexere Algorithmen erfordern tendenziell mehr Rechenleistung. Darüber hinaus kann Verschlüsselung den Speicherbedarf erhöhen, da sie die Größe der gespeicherten Daten aufbläht, weil sie typischerweise zusätzliche Metadaten und Padding enthält, was besonders bei kleineren Dateien auffällt. Ferner ist Verschlüsselung eine sich wiederholende Aufgabe, die jedes Mal ausgeführt werden muss, wenn Daten abgerufen oder aktualisiert werden. Diese Wiederholung kann insbesondere in Systemen mit hohem Durchsatz zu einem erhöhten Energieverbrauch beitragen.

Evaluate other CPU architectures

Anwendungen werden mit einer Softwarearchitektur gebaut, die am besten zu den geschäftlichen Anforderungen passt, denen sie dienen. Cloud-Anbieter machen es einfach, andere CPU-Typen zu evaluieren, wie z. B. x86-64, die zusammen mit vielen kosteneffektiven Alternativen in die Bewertung mit einbezogen werden können, die ein gutes Performance-pro-Watt-Verhältnis bieten.

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

Use a service mesh only if needed

Ein Service-Mesh setzt zusätzliche Container für die Kommunikation ein, typischerweise in einem Sidecar-Muster, um mehr operationelle Fähigkeiten bereitzustellen. Dies kann zu einer Erhöhung der CPU-Auslastung und des Netzwerkverkehrs führen, erlaubt jedoch auch, die Anwendung von diesen Fähigkeiten zu entkoppeln und sie aus der Anwendungsschicht in die Infrastruktur zu verlagern.

Da unser Netzwerk nicht auf Kubernetes-Abstraktionen beruht, besteht für uns ebenfalls kein Bedarf an einem Service-Mesh.

Terminate TLS at border gateway

Transport Layer Security (TLS) stellt sicher, dass alle zwischen Webserver und Webbrowsern ausgetauschten Daten privat und verschlüsselt bleiben. Das Beenden und Wiederherstellen von TLS erhöht jedoch die CPU-Auslastung und kann in bestimmten Architekturen unnötig sein.

Implement stateless design

Service-State bezieht sich auf die im Speicher oder auf der Festplatte gespeicherten Daten, die ein Dienst zum Funktionieren benötigt. State umfasst die Datenstrukturen und Member-Variablen, die der Dienst liest und schreibt. Je nach Architektur des Dienstes kann der State auch Dateien oder andere auf der Festplatte gespeicherte Ressourcen enthalten.

Unsere bestehenden Dienste, wie Container Services und Container Jobs, basieren auf einem zustandslosen Design und bringen diese Fähigkeiten auch für unsere Nutzer mit.

Match your service level objectives to business needs

Wenn Dienst-Ausfallzeiten akzeptabel sind, ist es besser, nicht auf höchste Verfügbarkeit zu zielen, sondern die Lösung nach den tatsächlichen geschäftlichen Anforderungen zu gestalten. Niedrigere Verfügbarkeitsgarantien können helfen, den Energieverbrauch durch die Nutzung weniger Infrastrukturkomponenten zu reduzieren.

Unser SLO ist es, den bestmöglichen Service bereitzustellen, ohne dabei Effizienz und Nachhaltigkeit zu kompromittieren. Daher verlassen sich unsere Dienste stark auf automatische Skalierung, um jederzeit ein angemessenes Service-Level mit minimalem Overhead zu bieten.

Match utilization requirements of virtual machines (VMs)

Es ist besser, eine VM mit höherer Auslastung laufen zu haben, als zwei mit geringer Auslastung, nicht nur in Bezug auf Energieproportionalität, sondern auch hinsichtlich des verkörperten CO2.

Bisher bieten wir keine VM-basierten Dienste an. Alle unsere Infrastrukturangebote basieren auf Containern, um ein schlankeres Erlebnis zu ermöglichen.

Match utilization requirements with pre-configured servers

Es ist besser, eine VM mit höherer Auslastung laufen zu haben, als zwei mit geringer Auslastung, nicht nur in Bezug auf Energieproportionalität, sondern auch hinsichtlich des verkörperten CO2.

Wir streben eine hohe Auslastung unserer Infrastruktur an, diese Komponenten werden jedoch nicht dem Endnutzer offenbart. Der Nutzer sieht nur Container als Abstraktion. Da wir Metriken zur Energieeffizienz bereitstellen, können diese je nach Auslastung der darunterliegenden Infrastruktur variieren.

Minimize the total number of deployed environments

In einer Anwendung kann es notwendig sein, mehrere Umgebungen im Anwendungsworkflow zu nutzen. Typischerweise wird eine Entwicklungsumgebung für regelmäßige Updates verwendet, während Staging- oder Testumgebungen dazu dienen, sicherzustellen, dass vor dem Erreichen einer Produktionsumgebung keine Probleme auftreten, auf die Benutzer Zugriff haben könnten.

Optimise storage utilisation

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

Optimize average CPU utilization

CPU-Auslastung und -Nutzung schwanken im Tagesverlauf, manchmal stark abhängig von den verschiedenen Rechenanforderungen. Je größer die Varianz zwischen Durchschnitts- und Spitzen-CPU-Auslastung ist, desto mehr Ressourcen müssen im Standby vorgehalten werden, um diese Verkehrsspitzen abzufangen.

Optimize impact on customer devices and equipment

Anwendungen laufen auf der Hardware des Kunden oder werden darauf angezeigt. Die vom Kunden verwendete Hardware hat einen durch Produktion und den laufenden Stromverbrauch verkörperten CO2-Fußabdruck. Die Optimierung von Softwaredesign und -architektur zur Verlängerung der Lebensdauer der Kundenhardware reduziert die Kohlenstoffintensität der Anwendung. Idealerweise kann der Kunde die Hardware bis zum Ausfall oder bis zur Veralterung weiterverwenden.

Optimize peak CPU utilization

CPU-Auslastung und -Nutzung schwanken im Tagesverlauf, manchmal stark abhängig von den verschiedenen Rechenanforderungen. Je größer die Varianz zwischen Durchschnitts- und Spitzen-CPU-Auslastung ist, desto mehr Ressourcen müssen im Standby vorgehalten werden, um diese Verkehrsspitzen abzufangen.

Queue non-urgent processing requests

Alle Systeme haben Phasen mit Spitzen- und niedriger Auslastung. Aus Hardware-Effizienzsicht sind wir effizienter, wenn wir die Auswirkungen von Anfrage-Spitzen minimieren und eine gleichmäßigere Auslastung der Komponenten ermöglichen. Aus Energieeffizienzsicht sind wir energieeffizienter, wenn wir sicherstellen, dass Leerlaufressourcen minimiert werden.

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

Reduce transmitted data

Aus Sicht der Energieeffizienz ist es besser, die Übertragungsgröße der Daten zu minimieren, damit weniger Energie benötigt wird, da der Netzwerkverkehr reduziert wird.

Remove unused assets

Überwachen und analysieren Sie die Anwendung und die Cloud-Kosten, um Ressourcen zu identifizieren, die nicht mehr verwendet werden oder reduziert werden können.

Scale down kubernetes applications when not in use

Um CO2-Emissionen und Kosten zu reduzieren, können Dev&Test-Kubernetes-Cluster außerhalb der Bürozeiten (z. B. nachts & an Wochenenden) Knoten (VMs) abschalten. => Dadurch wird die Optimierung auf Clusterebene umgesetzt.

Wir bieten keine Kubernetes-basierten Dienste an.

Scale down applications when not in use

Anwendungen verbrauchen CPU, auch wenn sie nicht aktiv genutzt werden. Beispielsweise Hintergrund-Timer, Garbage Collection, Health Checks etc. Selbst wenn die Anwendung heruntergefahren ist, verbraucht die darunterliegende Hardware Leerlaufleistung. Dies kann auch bei Entwicklungs- und Testanwendungen oder Hardware außerhalb der Bürozeiten passieren.

DownToZero — wie der Name sagt — steht das Runterskalieren im Kern unserer Aktivitäten. Daher streben wir an, dass alle Dienste Skalierungen nach unten ermöglichen.

Scale infrastructure with user load

Der Bedarf an Ressourcen hängt von der Nutzerlast zu einem gegebenen Zeitpunkt ab. Viele Anwendungen berücksichtigen dies jedoch nicht. In der Folge werden Ressourcen unterausgelastet und ineffizient genutzt.

Scale Kubernetes workloads based on relevant demand metrics

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

Wir bieten keine Kubernetes-Dienste an.

Scale logical components independently

Eine Microservice-Architektur kann die Menge der benötigten Rechenressourcen reduzieren, da sie es ermöglicht, jede unabhängige Komponente entsprechend ihrer eigenen Nachfrage zu skalieren.

Scan for vulnerabilities

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

Set storage retention policies

Aus Sicht des verkörperten CO2 ist es besser, einen automatisierten Mechanismus zum Löschen ungenutzter Speicherressourcen zu haben, damit wir effizient mit Hardware umgehen und die Speicherschicht für die Aufgabe optimiert ist.

Shed lower priority traffic

Wenn Ressourcen während stark frequentierter Ereignisse oder bei hoher Kohlenstoffintensität knapp sind, werden durch Ihr System mehr CO2-Emissionen erzeugt. Das Hinzufügen weiterer Ressourcen, um erhöhte Verkehrsanforderungen zu unterstützen, bringt mehr verkörpertes CO2 und mehr Strombedarf mit sich. Wenn während hoher Kohlenstoffintensität weiterhin alle Anfragen bearbeitet werden, erhöhen sich die Gesamtemissionen Ihres Systems. Das Abschneiden von niedrig priorisiertem Traffic in diesen Szenarien spart Ressourcen und CO2-Emissionen. Dieser Ansatz erfordert ein Verständnis Ihres Traffics, einschließlich welcher Aufrufe kritisch sind und welche besser Wiederholungsversuche und Fehler tolerieren können.

Time-shift Kubernetes cron jobs

Die CO2-Emissionen eines Softwaresystems hängen vom von dieser Software verbrauchten Strom ab, aber auch von der Kohlenstoffintensität des Stromnetzes, in dem sie betrieben wird. Aus diesem Grund kann das Ausführen energieeffizienter Software in einem kohlenstoffintensiven Stromnetz ineffektiv sein, um die globalen CO2-Emissionen zu reduzieren.

Obwohl wir keine Kubernetes-Dienste anbieten, bieten unsere Container Jobs die Möglichkeit eines flexiblen Zeitplanmodells. Siehe unsere Docs für mehr Informationen.

Use Asynchronous network calls instead of synchronous

Beim Aufrufen von Prozessen außerhalb des eigenen Prozesses — z. B. Datenbanken, Dateisysteme oder REST-APIs — kann das Verlassen auf synchrone Aufrufe dazu führen, dass der aufrufende Thread blockiert wird und die CPU zusätzlich belastet.

Use circuit breaker patterns

Moderne Anwendungen müssen regelmäßig mit anderen Anwendungen kommunizieren. Da diese anderen Anwendungen ihre eigenen Deployment-Zyklen, Ausfallzeiten und Verfügbarkeiten haben, kann die Netzwerkverbindung zu diesen Anwendungen Probleme haben. Wenn die andere Anwendung nicht erreichbar ist, schlagen alle Netzwerkanfragen gegen diese Anwendung fehl und zukünftige Anfragen sind aussichtslos.

Use cloud native network security tools and controls

Netzwerk- & Web-Application-Firewalls bieten Schutz gegen die meisten gängigen Angriffe und das Abblocken schädlicher Bots. Diese Tools helfen, unnötige Datenübertragungen zu entfernen und die Belastung der Cloud-Infrastruktur zu reduzieren, während sie gleichzeitig weniger Bandbreite und Infrastruktur benötigen.

Use DDoS protection

Distributed Denial of Service (DDoS)-Angriffe werden eingesetzt, um die Serverlast zu erhöhen, sodass legitime Anfragen nicht mehr beantwortet werden können. Dies geschieht meist, um dem Betreiber des Dienstes oder der Hardware zu schaden. Aufgrund der Natur des Angriffs werden viele Umweltressourcen durch sinnlose Anfragen verbraucht.

Use cloud native processor VMs

Cloud-VMs verfügen über unterschiedliche Fähigkeiten, basierend auf verschiedenen Hardware-Prozessoren. Daher wirkt sich die Nutzung von VMs, die auf der Effizienz ihrer Prozessoren basieren, auf die Hardware-Effizienz aus und reduziert CO2-Emissionen.

Use serverless cloud services

Serverlose Cloud-Services sind Dienste, die der Cloud-Anbieter für die Anwendung verwaltet. Diese skalieren dynamisch mit der Arbeitslast, die zur Erfüllung der Dienstaufgabe erforderlich ist, und wenden Best Practices an, um die Ressourcennutzung minimal zu halten.

Alle Angebote von DownToZero sind serverlose Cloud-Services.

Web

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

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