CO₂-sparen in der Softwareentwicklung – Nur wo?

Die IT- und Softwarebranche trägt einen nicht vernachlässigbaren Anteil zu den weltweiten CO₂-Emissionen bei. Daher nehmen wir, andrena, an einer CO₂-Challenge mit dem ambitionierten Ziel teil, den CO₂-Fußabdruck unserer Software drastisch zu reduzieren. Was uns direkt zu der Frage bringt, wie wir den CO₂-Ausstoß überhaupt messen können. Denn Tools gibt es viele, ihr Nutzen-Aufwand-Verhältnis ist jedoch sehr unterschiedlich und die richtige Auswahl damit alles andere als trivial. Hier erläutern wir unseren Ansatz, unsere Ergebnisse und was sich daraus lernen lässt für die Kernfrage, wie wir validieren, ob sich bestimmte Maßnahmen lohnen.

Die CO₂-Challenge oder wie alles anfing

Auslöser unserer Aktionen war die 2024 entstandene  CO₂-Challenge (https://co2-challenge.de) des CyberForum e.V. (https://www.cyberforum.de/ueber-uns), die unter anderem durch die Wirtschaftsförderung der Stadt Karlsruhe (https://www.karlsruhe.de/wirtschaft-wissenschaft/unternehmen-investoren) unterstützt wird. Die über 20 teilnehmenden Unternehmen (Stand August 2025) setzen sich zum Ziel, innerhalb eines Jahres den CO₂-Fußabdruck ihrer Software, um beachtliche 40% zu reduzieren.

Wer misst, misst Mist?

Alle Teilnehmenden der Challenge stehen vor dem gleichen Dilemma: Einerseits wollen wir den CO₂-Ausstoß messen, weil wir sonst schlicht nicht wissen, ob unsere Maßnahmen greifen. Andererseits ist diese Messung schon allein deswegen eine schwierige Aufgabe, weil es so viele Tools und Metriken gibt. Sie versuchen auf unterschiedlichen Ebenen der Software, den Energieverbrauch und darüber den CO₂-Ausstoß zu modellieren (einen guten Tool-Überblick gibt z.B. https://landscape.bundesverband-green-software.de/). Alle Messwerte sind nur Näherungen und basieren auf vielen Annahmen.

Wir haben uns diesem Dilemma genähert, indem wir erstmal verschiedene Ansätze an einer intern entwickelten Softwareanwendung ausprobiert haben, um ein besseres Gespür dafür zu bekommen, welche Messungen uns wirklich helfen.

Die Vermessung der Software

Als erstes haben wir uns die HTTP Access Logs der Webanwendung genauer angeschaut. HTTP Access Logs zeichnen alle HTTP Requests auf, die auf unser Backend gemacht werden. Jeder Request benötigt Strom und je mehr Daten übertragen werden, desto höher der Energiebedarf.  HTTP Access Logs erlaubten uns daher eine einfache Näherung des Stromverbrauchs, der mit der Nutzung einer Webanwendung entsteht. Wir konnten z.B. über die Analyse der häufigsten und “größten” Requests einige konkrete Maßnahmen zur Optimierung des Energieverbrauchs ableiten, indem wir die Größe von Bildern verkleinert sowie nicht benötigte Funktionalität abgeschaltet haben.

Der reine Blick auf den HTTP-Verkehr zwischen Front- und Backend war uns nicht genug. Deshalb haben wir im nächsten Schritt das Green Metrics Tool (https://www.green-coding.io/products/green-metrics-tool/) von Green Coding ausprobiert. Dieses Tool baut aus allen zugehörigen Services eine containerisierte Anwendung, was es ermöglicht, Schätzwerte für den Energieverbrauch der gesamten Anwendung zu liefern. Das klingt zunächst sehr gut. Allerdings nahm in unserem Fall das Setup des Tools viel Zeit in Anspruch, weil wir die Containerisierung unserer Anwendung nicht 1:1 übernehmen konnten. Darüber hinaus erwies es sich als weitere Hürde, realistische Nutzungsszenarien nachzustellen. Der Mehrwert des Tools wurde daher für uns eher gering. Das etwas aufwendigere Setup könnte sich dann lohnen, wenn man die CO₂-Reduktion zwischen verschiedenen Implementierungen kontinuierlich mit absoluten Werten quantifizieren möchte.

Als Nächstes nutzen wir ein Strommessgerät (Voltcraft SEM5000), um den Stromverbrauch des on-premise Servers zu messen, auf dem unsere Anwendung zusammen mit weiteren Anwendungen läuft. Dabei wurde deutlich, dass der Stromverbrauch die meiste Zeit konstant bleibt, selbst während der Hauptnutzungszeiten unserer Anwendung. Im Vergleich zum Grundverbrauch des Servers ist der Energiebedarf unserer Anwendung also vernachlässigbar. Ein Blick auf die CPU-Auslastung vervollständigt das Bild: Der Anteil unserer Anwendung an der CPU-Auslastung liegt die meiste Zeit bei weniger als 1%. Insgesamt ist die CPU-Auslastung des Servers gering (die meiste Zeit deutlich unter 50%). Effizienter wäre es, den Server mehr auszulasten. Für die Energieeffizienz ist es besser, weniger Server zu nutzen und diese auszulasten, als mehrere kaum ausgelastete Server zu betreiben. In unserem Fall würde es sich anbieten, die Anwendung in die Cloud zu migrieren und den Server abzuschalten.

Wir wollten auch ein Gefühl dafür bekommen, wie viel Energie die Entwicklung unserer Software verbraucht. Dafür haben wir unsere GitLab-CI-Pipeline mit einem weiteren Tool von Green Coding analysiert: Eco CI (https://www.green-coding.io/de/products/eco-ci/). Das Setup war deutlich weniger aufwendig als beim Green Metrics Tool, etwas manueller Aufwand war trotzdem nötig. Durch das Tool haben wir einen Schätzwert bekommen, wieviel CO₂ bei einem Durchlauf der Pipeline entsteht. Gut erkennbar, und wenig überraschend, war auch, dass der Energieverbrauch stark mit der Ausführungszeit zusammenhängt. Das bedeutet, dass man zum Optimieren des Energiebedarfs der Pipeline auch einfach damit anfangen kann, dass man langlaufende Jobs seltener startet, oder in dem man die Jobdauer verkürzt.

Fazit

Die Arbeit an der CO₂-Challenge hat uns unter anderem eins gelehrt: Es gibt unterschiedlichste Möglichkeiten, den Energieverbrauch und somit den CO₂-Ausstoß unserer Software zu schätzen. Zur Verfügung stehen viele dedizierte Tools und keins davon ist perfekt, die meisten kommen mit deutlichem Einarbeitungsaufwand. Manchmal steht der Nutzen der Messung nicht im Verhältnis zum Aufwand. Denn am Ende geht es nicht darum, absolute Messwerte zu erhalten, sondern Energie zu sparen. Und dafür können, anstelle der Angaben über die absolute Einsparung (z.B. in Tonnen CO₂ pro Jahr), bereits relative Angaben ausreichen (z.B. nur noch zwei statt vier Server). Die effektivsten Maßnahmen, wie Reduktion der Bildgröße, Abschalten von nicht verwendeten Ressourcen und Migration in die Cloud, konnten wir in unserem Fall bereits mit Hilfe von einfachen Mitteln wie HTTP Access Logs, CPU-Auslastung und Ausführungszeit ableiten.