Grüner coden: Ressourcen im Blick

Inhaltsverzeichnis

Um die Auswirkungen des Klimawandels zu reduzieren und die Erde für zukünftige Generationen lebenswert zu erhalten, sind wir alle gefordert, zur Reduzierung des CO₂-Ausstoßes beizutragen – auch die IT. Dabei sind zwei Aspekte zu berücksichtigen: Zum einen hat IT einen positiven Effekt auf den Ressourcenverbrauch, da die Digitalisierung dazu beiträgt, Rohstoffe und Ressourcen zu schonen – unter anderem durch das Einsparen von Papier und Reisen. Auf der anderen Seite verbraucht die IT schon angesichts der steigenden Zahl an Rechenzentren selbst immer mehr Energie. Derzeit ist unklar, ob der gestiegene Energieverbrauch die erzielten Einsparungen nicht bereits übersteigt. Konsequenterweise sollte sich die Branche darauf konzentrieren, ihren Energiehunger zu begrenzen und den Ressourcenverbrauch zu reduzieren (siehe Bitkom-Studie: Klimaeffekte der Digitalisierung).

Richard Attermeyer

Richard Attermeyer arbeitet als Chief Solution Architect bei Opitz Consulting. Sein aktueller Fokus liegt auf der Modernisierung von großen Geschäftsanwendungen.

Oft sind dabei nur energieeffiziente Hardware und der Gesamtenergieverbrauch von Rechenzentren im Blick. Ansätze wie der Einsatz von Strom aus erneuerbaren Energiequellen oder die Nutzung der Abwärme weisen den Weg. Aber der ressourcenschonende Betrieb von Rechenzentren ist nur eine Seite der Medaille. Wichtiger wäre es, den Ressourcenverbrauch schon direkt bei den darin betriebenen Applikationen zu minimieren. Es stellt sich daher die Frage, ob sich bereits bei der Softwareentwicklung entscheidende Weichen stellen lassen – etwa durch geeignete Entwurfsentscheidungen. Voraussetzung wäre jedoch, dass sich die CO₂-Emissionen von Software nachvollziehbar messen lassen. Dafür existieren (noch) keine anerkannten Standards. Und was man nicht messen kann, kann man schlecht kontrollieren.

Grundsätzlich ist zudem die Entscheidung zu fällen, ob nur die Emissionen zur Laufzeit der Software berücksichtigt werden sollen oder auch die bei deren Erstellung. Letzteres betrifft unter anderem das Kompilieren und Testen des Codes, aber auch die Kosten für das Training eines ML-Modells, wenn KI zum Einsatz kommt. Trotz dieser zwiespältigen Ausgangslage lassen sich ein paar grundlegende Überlegungen treffen, die im Folgenden behandelt werden.

Als generelles Prinzip gilt: unnötigen Ressourcenverbrauch vermeiden. Das betrifft alle Bereiche: das Erstellen von Software und KI-Modellen, die Speicherung und Verarbeitung von Daten sowie den Betrieb der Software.

Aus diesem Prinzip leiten sich konkrete Entwurfsstrategien und Handlungsempfehlungen ab. Eine Quelle ist das Handbook of Sustainable Design of Digital Services vom Institute for Sustainable IT. Das Institut bietet Awareness-Schulungen zum Thema und ist Mitglied im Verbund "European Institutes for sustainable IT".

Eine Auswahl und die Gruppierung der im Handbuch beschriebenen Taktiken zeigt Abbildung 1. Die folgende Aufstellung geht auf einige Handlungsempfehlungen näher ein – die Green Software Foundation spricht dabei von Green Software Patterns.

CPU-Zeit sparen

Angesichts der hohen Arbeitsgeschwindigkeit aktueller Computersysteme gehen viele Anwenderinnen und Anwender verschwenderisch mit der verfügbaren Leistung um. Probleme mit schlechtem Laufzeitverhalten ineffizienter Software lösen sie im Zweifelsfall durch den Einsatz von mehr Hardware.

Ziel sollte es jedoch sein, CPU-Zyklen nicht unnötig zu verschwenden, sondern Probleme mit effizienten Algorithmen zu lösen. Allerdings ist nicht allein das Laufzeitverhalten des Algorithmus entscheidend, sondern auch die Wahl der Programmiersprache. Denn diese unterscheiden sich hinsichtlich ihrer Energieeffizienz deutlich. Laut einer Vergleichsstudie zur Energieeffizienz verschiedener Programmiersprachen ist C im Hinblick auf Energie und Zeitverbrauch zur Laufzeit die beste Option. Rust schneidet nur unwesentlich schlechter ab und Java findet sich hinter C++ und ADA auf Platz 5. Dabei ist Java die einzige nicht direkt kompilierte Sprache, die sich weit vorne im Ranking platzieren konnte. TypeScript und Python finden sich im unteren Drittel.

Wie bei den meisten Architekturentscheidungen ist die Wahl der Programmiersprache eine Frage der individuellen Vor- und Nachteile für das Projekt. Auch wenn C bei Energie und Geschwindigkeit punkten kann, ist Java – etwa wegen seiner Speichersicherheit – zu bevorzugen.

Ein weiterer Ansatz, um CPU-Zeit zu sparen, ist das Caching der berechneten Daten. Wenn bei jedem Zugriff Webseiten und zugehörige Daten aus der Datenbank geholt, verarbeitet und ausgegeben werden, erfordert das mehr CPU-Zeit, als wenn sie direkt aus dem Cache einfließen. Der Cache trägt in der Regel außerdem zu verkürzten Antwortzeiten bei und verbessert damit die User-Experience.

Richtig messen und überwachen

Standardisierte Verfahren zum Messen der CO₂-Emissionen durch den Softwarebetrieb existieren nicht, aber es gibt Projekte, die zumindest den Energieverbrauch unter bestimmten Bedingungen nachvollziehbar machen. Das Projekt Kepler erlaubt das Messen des CPU-Verbrauchs in Kubernetes-Clustern. Zusammen mit den Statistiken von cgroups und sysfs lassen sich die Daten aus Kepler an ML-Modelle übergeben, um den Energieverbrauch von Kubernetes-Pods zu ermitteln. Die Metriken lassen sich über einen Prometheus-Exporter zur Verfügung stellen, um sie, wie in Abbildung 2 zu sehen, mit einem Observability- und Visualisierungstool wie Grafana auszuwerten.

Der steigende Energieverbrauch der IT steht nicht erst seit dem KI-Hype in der Kritik. Derzeit ist unter Nachhaltigkeitsaspekten aber vor allem die Betrachtung von KI relevant, denn dabei sind sowohl das Training der Modelle als auch die Inference (das Ableiten von Aussagen) zu berücksichtigen. Zwar verbraucht bereits das Erzeugen von Modellen Energie, je mehr von ihnen aber tatsächlich genutzt werden, desto stärker schlägt der Betrieb zu Buche. Einen rasanten Aufschwung erleben Anwendungen mit generativer KI. Entwicklerinnen und Entwickler sollten sich daher zunehmend Gedanken machen, ob und in welchen Bereichen sie KI einsetzen.

Bandbreite im Netzwerk sparen und Datenmenge reduzieren

Was beim Programmieren gerne unbeachtet bleibt, ist die Tatsache, dass der Netzwerkverkehr zwischen Servern in Rechenzentren und den Anwendersystemen nicht unerheblich zum Energieverbrauch beiträgt. Einfache Maßnahmen zum Reduzieren der Last sind etwa Kompression (die im Gegenzug aber CPU-Zyklen verbraucht) und der Einsatz von GraphQL anstelle von REST. GraphQL vermeidet durch Parameterisierung der Anfragen das Übertragen nicht benötigter Daten, wie es häufig bei REST-Schnittstellen der Fall ist. Es wird nur das übertragen, was zum Umsetzen des gerade betrachteten Anwendungsfalls notwendig ist.

Während GraphQL und REST sich eher auf Textdaten beziehen, tragen vor allem Bilder und Videos zu hohem Datenvolumen bei. Daher sollten Bilder möglichst in geeigneter Skalierung übertragen werden, statt sie auf dem Client zu skalieren. Auch die Wahl geeigneter Formate wie webp hilft, Daten zu sparen.

Bei typischen Geschäftsanwendungen ist es wichtig, ein Data-Lifecycle-Management zu implementieren und überflüssig gewordene Daten aus der "heißen" Datenbank zu entfernen, in der die aktuell benötigten Daten liegen, auf die häufig zugegriffen wird. Je nach Anwendungsfall sind bestimmte Vorhaltefristen für Daten einzuhalten, um eine flüssige Verarbeitung zu gewährleisten. Danach lassen sie sich in andere Speicherbereiche verlagern. Diese Form der Reduktion kann sich positiv auf die Menge der zu lesenden Daten für die Beantwortung einer Abfrage auswirken – bringt darüber hinaus aber auch Vorteile beim Backup. Zum Thema Datenhaltung gehört auch die Optimierung des Zugriffs. Database-Tuning ist daher eine wichtige Aufgabe, sowohl aus Performance- als auch aus Energieeffizienzgründen.

Entwicklerinnen und Software-Architekten haben häufig nur die direkt verarbeiteten Daten im Blick. Wie aber ist mit weiteren Daten umzugehen, etwa Log- und Metrikdaten? Ist die Menge der gesammelten Daten dem Zweck des Softwaresystems und der Umgebung angemessen? Wie sind Vorhaltezeiten definiert und welche Aufräumprozeduren sind vorgesehen? Auch hier lohnt ein genauer Blick, denn angesichts der über lange Zeit gesunkenen Kosten für Speicherplatz hat sich Sorglosigkeit im Umgang mit den Storage-Ressourcen breitgemacht.

Hosting und Service Operations – FinOps

Eine sorgfältige Planung beim Thema Hosting und Operations hilft, unnötigen Ressourcenverbrauch und damit auch Kosten zu vermeiden. Insbesondere in größeren Cloud-Umgebungen ist dabei die Rede von FinOps. Wichtige, darin zu berücksichtigende Aspekte sind:

• Ist sichergestellt, dass sich ungenutzte Ressourcen entdecken und freigeben lassen?
• Erfolgt ein kontinuierliches Rightsizing? Sind etwa im Container-Umfeld Faktoren wie Memory, CPU Requests und Limits richtig gesetzt oder werden Ressourcen verschwendet?
• Werden ungenutzte Ressourcen (etwa Entwicklungs- und Testumgebungen) wieder freigegeben und heruntergefahren?

Dieser kurze Überblick zu den Handlungsempfehlungen macht deutlich, dass viele Designentscheidungen Einfluss auf den Ressourcenverbrauch haben. Es zeigt sich vor allem in Cloud-Umgebungen, dass sich der finanzielle Aspekt als Proxy nutzen lässt, um den Umwelteinfluss zu reduzieren. FinOps hat in der Cloud nicht nur den Effekt, die Kosten für die Cloud-Nutzung im Blick zu haben, sondern auch etwas für die Umwelt zu bewegen.

Microservices und Echtzeitverarbeitung

Für die Gestaltung von IT-Systemen haben sich eine Vielzahl an Trends herauskristallisiert – darunter etwa Microservices und Echtzeitverarbeitung. Wie sich die oben vorgestellten Einzelmaßnahmen für mehr Nachhaltigkeit und Ressourcenschonung im Hinblick auf diese Trends schlagen, zeigen die nachfolgenden Betrachtungen.

Microservices sind ein Architekturstil, der ein IT-System als Menge unabhängiger Services umsetzt. Unabhängigkeit bezieht sich dabei sowohl auf die Laufzeitumgebung als auch auf die Daten. Eine Folge ist, dass mehr CPU-Leistung und Speicher benötigt werden und sowohl direkte Aufrufe als auch die Datenreplikation das Netzwerk belasten.

Viele Projekte steigen zu früh auf Microservices um. Die Verteilung sollte immer durch entsprechende Business-getriebene Qualitätsaspekte begründet werden. Häufig ist es daher empfehlenswert, mit einem fachlich gut strukturierten Monolithen zu starten (Modulith) und erst später dort auf verteilte Dienste umzusteigen, wo der Nutzen die zusätzlichen Kosten und den Ressourcenbedarf übersteigt.

iX/Developer Sonderheft zu moderner Softwarearchitektur

Dieser Artikel knüpft inhaltlich an das iX/Developer-Sonderheft "Praxis Softwarearchitektur" an, das sich an Softwarearchitektinnen und Softwarearchitekten richtet. Neben den klassischen Architekturinhalten zu Methoden und Pattern gibt es Artikel zu Soziotechnischen Systemen, Qualitätssicherung oder zu Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies und Green Scrum.

Als Autoren konnten wir bekannte Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln sowohl für Architektureinsteiger als auch Spezialistinnen weitergeben.

Auf der anderen Seite kann auch das Verteilen zur Reduzierung des Ressourcenverbrauchs beitragen, wenn es unterschiedliche Einsatzszenarien für die einzelnen Services gibt, etwa im Hinblick auf Verfügbarkeiten oder unterschiedliche Skalierungsanforderungen. Monolithischen Applikationen stellt man häufig den Maximalbedarf an Ressourcen zur Verfügung. Viele Ressourcen bleiben dann lange ungenutzt und verursachen einen hohen Leerlaufverbrauch. Es ist so, als ob man ein SUV kauft und 30.000 Kilometer im Jahr damit fährt, obwohl man es eigentlich nur für zwei Wochen im Jahr zum Ziehen des Wohnwagens benötigt. Ein Kleinwagen und ein geliehenes Wohnmobil wären günstiger und umweltfreundlicher.

Echtzeitverarbeitung löst immer mehr Batch-orientierte Verfahren ab, ein prominentes Beispiel ist Instant Payment im Finanzwesen. Banken, deren Payment-Infrastruktur komplett auf Batch-orientierte Verfahren setzt, haben Schwierigkeiten, die zeitlichen Anforderungen an Sofortüberweisungen zu erfüllen.

Batch-Verarbeitung hat den Vorteil, die Arbeitslast in Zeiten verschieben zu können, in denen mehr erneuerbare Energie bereitsteht. In Deutschland ist dies häufig zwischen 10 und 17 Uhr, wie die Zahlen von Agora Energiewende zeigen.

Alternativ lässt sich die Verarbeitung auch in Zeiten verschieben, in denen die Ressourcen ungenutzt sind (etwa nachts), um keine zusätzlichen für die Echtzeitverarbeitung vorhalten zu müssen. Darüber hinaus kann man KI-Modelle in Regionen trainieren, in denen weniger Strom für die Kühlung von Rechenzentren notwendig ist und dieser auch noch CO₂-neutral erzeugt wird. Ein Beispiel wäre Skandinavien.

Energieeffizienz über den gesamten DevOps Lifecycle

Die Energieeffizienz als einen wesentlichen Treiber für die Architektur von IT-Systemen zu berücksichtigen, führt dazu, dass eine Reihe zusätzlicher Trade-offs beachtet werden müssen. Daher ist eine kontinuierliche Auseinandersetzung über den gesamten DevOps-Lebenszyklus wichtig.

Viele der relevanten Aspekte sind weiter oben im Rahmen der Lösungsstrategien bereits behandelt, in Abbildung 3 findet sich aber noch der interessante Punkt Purposeful Tests, der sich auf das Optimieren des CI/CD-Prozesses hinsichtlich Energieeffizienz bezieht. Idealerweise sollte möglichst jeder einzelne Commit daraufhin getestet werden, ob er die Software weiterhin in einem Release-fähigen Zustand belässt. Dabei macht es jedoch einen Unterschied, ob Entwicklerinnen und Entwickler auf einem Feature-Branch arbeiten, einen Pull-Request dafür erstellen oder ihren Development-Branch in den Master-Branch mergen.

Gerade angesichts der Vielzahl unterschiedlicher Tests im Rahmen der CI/CD-Pipeline stellt sich die Frage, wann und gegebenenfalls wie häufig sie laufen müssen. Wie oft sollten Security-Scans oder eine statische Code-Analyse erfolgen? Lassen sich die Tests auf jene Teile des Codes beschränken, die gerade neu bearbeitet wurden? Sollten Build-Caches zum Einsatz kommen? Zeitnahes Feedback korreliert dabei stark mit Energieeinsparung und erhöht zudem die Entwicklerzufriedenheit.

Ein Vorteil vieler Entscheidungen für die Architektur energieeffizienter Systeme ist, dass sie häufig neben einem ökologischen gleichzeitig einen ökonomischen Nutzen liefern. Viele der im Artikel besprochenen Taktiken sowie einige weitere fasst Abbildung 4 zusammen.

Taktik individuell anpassen

Eine konkrete Auswahl der Taktiken und deren Trade-off-Analyse muss pro Use-Case erfolgen. Software, die nur von wenigen Anwenderinnen und Anwendern genutzt wird, ist über ihren Lebenszyklus anders zu bewerten als häufig verwendete Applikationen. Inhaltszentrierte Webseiten mit viel statischem Content erfordern andere Taktiken als klassische Geschäftsanwendungen, deren Inhalt auf spezifische Nutzer fokussiert ist. Über die Energieeffizienz der eigenen Software nachzudenken, sollte im Sinne von mehr Nachhaltigkeit für jede Entwicklerin und jeden Entwickler zur Selbstverständlichkeit werden.

(map)