Messbarkeit indirekt produzierter Emissionen Wie sich der CO2-Ausstoß von Software berechnen lässt

Anbieter zum Thema

Thoughtworks Deutschland GmbH

Windhoff Group

Betrachtet man die Diskussionen rund um CO₂-Emissionen von Technologie fällt auf: Sie drehen sich meistens nur um die Hardware. Völlig unbeachtet bleibt häufig, welchen Anteil Software an den Gesamtemissionen eines Geräts hat – und der ist keineswegs zu vernachlässigen.

Die Zahlen sprechen für sich: Die Softwareindustrie ist für rund drei Prozent der weltweiten CO₂-Emissionen verantwortlich, was in etwa dem Anteil der Luftfahrtindustrie entspricht. Anders als bei Flugzeugen ist der Kohlendioxidausstoß von Software allerdings weniger greifbar und offensichtlich.

Schauen wir uns deshalb beispielhaft einen Laptop an: Dessen Herstellung verursacht eine gewisse Menge an Kohlendioxidemissionen, die sogenannten Basis-CO₂-Emissionen. Darüber hinaus beansprucht die Nutzung von Software-Anwendungen den Akku und den Arbeitsspeicher des Gerätes und steigert dadurch den Energieverbrauch. So werden die Software-Emissionen de facto über die Hardware freigesetzt.

Messbarkeit des CO₂-Fußabdrucks von Software

Doch wie lässt sich der CO₂-Ausstoß von Software messen? Hier setzt die Green Software Foundation (GSF) an. Als Kooperation diverser IT-Unternehmen wie Microsoft, GitHub und Thoughtworks will die Stiftung einen Standard etablieren, der die Entwicklung grüner Software erleichtert. Die „Software Carbon Intensity“ (SCI) bietet eine Methodologie, um die CO₂-Emissionen eines Softwaresystems zu berechnen und empfiehlt, jeweils nur eine Systemkomponente in die Berechnungen einzubeziehen.

Ein Beispiel veranschaulicht die Vorgehensweise: Angenommen, wir erstellen eine Backend-API für Produktlisten und führen diese lokal auf einem Laptop aus. Bevor wir die CO₂-Emissionen dieser API berechnen können, müssen wir den Energieverbrauch des Laptops im Standby betrachten. Durch die Anwendung einer Standardformel können wir die Emissionen eines Geräts im Standby (SCI) berechnen. Anschließend setzen wir die Produkt-API ein und führen erneut eine SCI-Messung durch. Die Abweichung zwischen diesen beiden Werten liefert die CO2-Emissionen der Produkt-API. Bei wiederholten Messungen sämtliche Veränderungen der Komponenten angemessen zu berücksichtigen, um letztliche präzise Ergebnisse zu erhalten.

Komponenten von Software

Die Komponenten von Software-Anwendungen kann man herunterbrechen, um deren CO₂-Fußabdruck zu messen. Dazu gehören laut GSF folgende:

• Rechenkapazität

• Speicher

• Netzwerkausstattung

• Monitoring

• Geräte im Leerlauf

• Protokollierung

• Scannen

• Pipeline-Erstellung und -Bereitstellung

• Testen

• Training von ML-Modellen

• Betrieb

• Backups

• Ressourcen für Redundanz

• Ressourcen für Ausfallsicherheit

Die SCI-Gleichung

Die Software Carbon Intensity gibt den Anteil der CO₂-Emissionen an, nicht deren Summe, und ist auf Maßnahmen ausgerichtet, mit denen CO₂-Emissionen vermieden werden. Die Gleichung zur Berechnung lautet:

Hinter „E“ steht der Energieverbrauch der Software (in kWh). „I“ sind die Kohlendioxidemissionen pro kWh Energie (in gCO₂/kWh). „M“ ist die Summe der durch Herstellung und Entsorgung von Hardware, auf der die Software läuft, verursachten Kohlendioxidemissionen. Hinter „R“ steht die funktionale Einheit, mit der die Skalierung der Software bezeichnet wird, z.B. nach Benutzer, Gerät oder API-Anfragen.

Was bedeutet das?

Die funktionale Einheit (R)

Wir bleiben bei unserem API-Beispiel. Was passiert, wenn die Anzahl der Produkte steigt oder die Anzahl der API-Aufrufe zunimmt? Ist die Berechnungsgrundlage eine Konstante? Für die gleichen Software-Komponenten wird die CO₂-Intensität steigen, da die Emissionen je nach verwendeter Energieeinheit variieren. Das wiederum hängt von der Skalierbarkeit ab. An dieser Stelle stehen wir vor ähnlichen Herausforderungen wie DevOps bei der Skalierbarkeit von Software.

Gemäß der SCI-Spezifikation nennt man die kleinste relevante Einheit der CO₂-Intensität die Funktionseinheit. Wenn ich den SCI berechne, muss ich als erstes die kleinste funktionale Einheit definieren. Der SCI-Standard gibt vor, dass wir berechnen, verbessern, neu berechnen und immer weiter verbessern müssen, um die CO₂-Emissionen zu reduzieren. Was in diesem Prozess konstant bleiben muss, ist die funktionale Einheit R.

Die Differenz im Stromverbrauch zu berechnen kann mithilfe eines Spannungsmessers relativ leicht sein – wenn man selbst vollen Einblick in die Systeme hat. Schwieriger wird es, wenn man Anwendungen in die Cloud verlagert. Die vier großen Cloud-Anbieter haben auf ihren Websites eine Stelle eingerichtet, an der Software-Entwickler einsehen können, wie viel Energie ihre Dienste verbrauchen.

Doch wie kann man wissen, wie hoch der Energieverbrauch ist, wenn man nicht mit einem dieser Cloud-Anbieter zusammenarbeitet? Oder wenn man die Details seiner Workloads nicht kennt? Dafür betrachten wir den Faktor E.

Der Energieverbrauch (E)

Genauso wie jeder Cloud-Anbieter Informationen über die verwendete Hardware zur Verfügung stellen kann, können Hardware-Anbieter Informationen über den typischen Energieverbrauch ihrer Produkte zur Verfügung stellen, wie beispielsweise den Arbeitsspeicher. Anhand dieser Daten ist es möglich, das CO₂-Äquivalent (CO₂EQ) für eine Kilowattstunde Energie zu berechnen.

Die standortbezogene marginale Kohlenstoffdioxid-Intensität (I)

Nun kenne ich zwar den Energieverbrauch meiner Software, aber wie erhalte ich daraus die CO₂-Äquivalente? Die Umrechnung dafür ist international nicht vereinheitlicht. In Australien setzt man beispielsweise auf einen Standard, der angibt, wie viel Kohlenstoff pro verbrauchter Kilowattstunde Energie freigesetzt wird. In der SCI-Berechnung wird dies als „Location-Based Marginal Carbon Intensity“ bezeichnet und mit „I“ abgekürzt. Im Zusammenhang mit „E“ wird „I“ als „O“ bezeichnet, also als „Operational Emissions“. Dies stellt die Menge an CO₂ dar, die bei einem bestimmten Prozess freigesetzt wird.

Eingebettete Emissionen (M)

Die eingebetteten Emissionen werden auch als „graue Energie“ bezeichnet, da es sich um die Menge an CO₂ handelt, die bei der Herstellung und Entsorgung eines Hardware-Geräts entsteht. Läuft auf einem Gerät Software, wird dieser ein Teil der grauen Energie zugerechnet. Dieser Anteil ist der Faktor M, der in der SCI-Gleichung berechnet wird und sich aus einem Zeit- und einem Ressourcen-Anteil zusammensetzt. Der Zeitanteil wird durch die Zeit bestimmt, die die Software auf einem Gerät ausgeführt wird. Der prozentuale Anteil der Geräteleistung, der während dieser Zeit nur für diese Anwendung reserviert ist, definiert den Ressourcen-Anteil. Im Gegensatz zu den bisherigen Berechnungen erhält man so direkt den CO₂EQ.

Mehr Transparenz schafft ein Mehr an Nachhaltigkeit

In der Software-Entwicklung steht der CO₂-Ausstoß bisher noch weniger im Fokus als andere Aspekte. Ein erster Schritt in die richtige Richtung ist es, in unseren CI/CD-Pipelines Zeit und Kapazitäten für die Messung und Überwachung des Kohlenstofffußabdrucks einzukalkulieren. Ein verantwortungsvoller Umgang mit dem SCI kann ein großer Schritt auf dem Weg zu einer umweltfreundlichen Software sein. Denn wir alle tragen Verantwortung für unsere Umwelt.

(ID:49835780)