CO2-Fußabdruck von Software berechnen? So geht’s! 

Diskussionen rund um die CO2-Emissionen konzentrieren sich heute in der Regel auf die Hardware. Der Einfluss von Software auf die CO2-Bilanz eines Geräts ist noch wenig beachtet – zu Unrecht. Denn die Bereitstellung und Nutzung der Software trägt durchaus zu den Gesamtemissionen eines Geräts bei. [...]

Foto: RoadLight/Pixabay

Insgesamt ist die Software-Branche für etwa drei Prozent der weltweiten CO2-Emissionen verantwortlich – das entspricht ungefähr dem Anteil der Luftfahrtindustrie. Im direkten Vergleich sind die CO2-Emissionen von Software jedoch viel weniger greifbar.

Betrachten wir einen Laptop. Der Strom, den ein Laptop für den Betrieb benötigt, verursacht bei der Erzeugung eine bestimmte Menge an Emissionen. Dies ist der sogenannte Basis-CO2-Ausstoß. Nun trägt die Software allerdings unmittelbar zu einem höheren Energieverbrauch bei, da durch ihre Nutzung Akku und Arbeitsspeicher stärker beansprucht werden. Folglich kann man sagen, dass die Software ihre Emissionen über die Hardware ausstößt.

Aus diesem Grund gibt es in der Branche ein wachsendes Interesse daran, „grüne Software“ zu entwickeln, die weniger CO2-Emissionen verursacht. Eine Grundvoraussetzung dafür ist, die Emissionen erfassen zu können.

Hier kommt die Arbeit der Green Software Foundation (GSF) ins Spiel. Gegründet von IT-Unternehmen wie Microsoft, GitHub und Thoughtworks hat die Stiftung das Ziel, einen Standard zu schaffen, der die Entwicklung umweltfreundlicher Software ermöglicht.

Die CO2-Emissionen von Software messbar machen 

Es bleibt die große Frage: Wie kann man nun den CO2-Ausstoß von Software messen? Um das zu beantworten, hat die GSF einen Standard entwickelt – die „Software Carbon Intensity“ (SCI). Sie definiert eine Methodik, um die CO2-Emissionen eines Software-Systems zu berechnen.

Die Stiftung empfiehlt, bei den Berechnungen pro Durchlauf jeweils nur eine Systemkomponente zu betrachten. Generell ist es wichtig, die Berechnungen nur innerhalb der Grenzen eines Softwaresystems durchzuführen. Dies ist wichtig, da die Berechnungen im ersten Schritt für jede einzelne Komponente eines Softwaresystems durchgeführt werden müssen, bevor der SCI des gesamten Systems bestimmt werden kann.

Ein Beispiel: Wir erstellen eine Backend-API, die eine Liste von Produkten zurückgibt (eine Produkt-API), und führen diese API zunächst lokal aus – ohne sie bereitzustellen. Bevor wir nun die CO2-Emissionen dieser Produkt-API berechnen können, müssen wir uns zunächst den Laptop ansehen, auf dem sie ausgeführt wird.

Er könnte zwar im Leerlauf sein, aber auch eine Maschine im Leerlauf verbraucht Energie. Diesen Verbrauch müssen wir berechnen, wenn wir einen genauen Überblick über alles bekommen wollen, was vor sich geht.

Sobald wir das anhand einer Standardformel erledigt haben, können wir die Emissionen eines Geräts im Leerlauf berechnen (SCI). Dann können wir die Produkt-API anwenden und den SCI erneut messen. Die Differenz zwischen diesen beiden Werten ergibt dann den CO2-Ausstoß der Produkt-API. Es ist wichtig, bei wiederholten Messungen und Berechnungen jede Änderung der Komponenten zu berücksichtigen. 

Software-Grenzen 

Es gibt viele Beispiele für Software-Grenzen. Die Green Software Foundation stellt einige Beispiele auf ihrer Website zur Verfügung: 

  • Rechenkapazitäten 
  • Speicher 
  • Netzwerkausrüstung 
  • Speicher 
  • Monitoring 
  • Geräte im Leerlauf 
  • Protokollierung 
  • Scannen 
  • Erstellung und Bereitstellung von Pipelines 
  • Testen 
  • Training von ML-Modellen 
  • Betrieb 
  • Backups 
  • Ressourcen für Redundanz 
  • Ressourcen zur Ausfallsicherung 

Funktionelle Einheit (R) 

Die Frage, die wir uns stellen müssen: Ist die Basis immer die gleiche? Was ist, wenn die Anzahl der Produkte auf einem Laptop steigt? Oder wenn die Anzahl der API-Aufrufe steigt? Die CO2-Intensität wird selbst mit derselben Software-Grenze steigen, weil die CO2-Emissionen je nach den verwendeten Energieeinheiten unterschiedlich sind. Das wiederum hängt von der Skalierbarkeit ab. Und hier stehen wir vor ähnlichen Herausforderungen wie bei der Skalierung von Software in der DevOps-Welt.

In den SCI-Spezifikationen wird die kleinste relevante Einheit der CO2-Intensität als Funktionseinheit bezeichnet. Nehmen wir als Beispiel wieder eine Produkt-API. Muss ich den SCI berechnen, ist der erste Schritt, die kleinste funktionale Einheit festzulegen.

Der SCI-Standard schreibt vor, dass wir berechnen, verbessern, neu berechnen und immer weiter verbessern müssen, um die CO2-Emissionen zu senken. Was dabei konstant bleiben muss, ist die funktionelle Einheit R.

Die Differenz im Stromverbrauch zu berechnen, ist in bestimmten Situationen recht einfach, wenn ein Voltmeter zur Verfügung steht. Fließen Clouds mit in die Gleichung ein, wird es komplexer. Alle vier großen Cloud-Anbieter haben auf ihren Websites eine Stelle eingerichtet, an der Software-Entwickler:innen einsehen können, wieviel Energie ihre Dienste verbrauchen.

Wie kann man aber wissen, wie hoch der Energieverbrauch ist, wenn man nicht mit einem dieser Cloud-Anbieter zusammenarbeitet? Wenn man die Details des Energieverbrauchs seiner Arbeitslast nicht kennt?

Die SCI-Gleichung 

Die Gleichung des SCI lautet: 

SCI = ((E*I) + M) pro R 

Was steckt dahinter? Wir haben bereits R beleuchtet, betrachten wir nun E. 

(Quelle: Thoughtworks)

Energieverbrauch (E) 

Jeder Cloud-Anbieter kann Spezifikationen für die verwendete Hardware bereitstellen. Und jeder Hardware-Anbieter kann Angaben über den Energieverbrauch machen, den der Arbeitsspeicher seines Produkts (zum Beispiel) normalerweise verbraucht. Anhand dieser Daten lässt sich das CO2EQ (Kohlendioxidäquivalent) für 1 Kilowattstunde Energie berechnen. 

Standortbezogene marginale CO2-Intensität (I) 

Wenn ich nun weiß, wie viel Energie meine Software verbraucht, wie kann ich das in Kohlendioxidäquivalente umrechnen? Dafür gibt es keine allgemeingültige Formel, denn jede Region hat ihren eigenen Standard. In Australien zum Beispiel gibt es einen Standard, der angibt, wie viel Kohlenstoff pro verbrauchte Kilowattstunde Energie erzeugt wird.

In der Formel zur Berechnung des SCI wird dies als Location-Based Marginal Carbon Intensity (standortbezogene marginale CO2-Intensität) bezeichnet und mit „I“ abgekürzt. Im Kontext von „E“ wird „I“ mit „E“ als „O“ bezeichnet, also betriebliche Emissionen (Operational Emissions). Das ist die Menge an CO2, die bei einem bestimmten Prozess freigesetzt wird. 

Eingebettete Emissionen (M) 

Eingebettete Emissionen, auch „graue Energie“ genannt, sind die Menge an CO2, die bei der Herstellung und Entsorgung eines Hardware-Geräts entsteht. Läuft Software auf einem Gerät, wird ihr ein Teil der eingebetteten Emissionen zugeschrieben.

Dies ist der Wert M, der in der SCI-Gleichung berechnet wird. Dieser Anteil besteht sowohl aus einem Zeit- als auch aus einem Ressourcenanteil. Den Zeitanteil bestimmt die Dauer, die Software auf einem Gerät läuft. Der prozentuale Anteil der Geräteleistung, der während dieser Zeit nur für diese Anwendung reserviert ist, bestimmt den Ressourcenanteil. Im Gegensatz zu früheren Berechnungen erhalten wir so direkt den CO2EQ. 

Mehr Einblicke für mehr Nachhaltigkeit 

CO2-Emissionen werden bei der Software-Entwicklung oft nicht so ernst genommen wie andere Aspekte. Ein guter erster Schritt dagegen ist, in unsere CI/CD-Pipelines Zeit und Kapazitäten einzuplanen, um den CO2-Fußabdruck zu messen und zu überwachen. Denn wir alle tragen Verantwortung für die Umwelt. Ein sorgfältiger Umgang mit dem SCI kann einen großen Schritt auf dem Weg zu umweltfreundlicher Software darstellen. 

*Razin Memon hat Unternehmen bei ihren Cloud-Migrationen, der Umstrukturierung von Teams, dem Entwurf evolutionärer Architekturen und der Bildung von Communities unterstützt. Jetzt leitet er das Innovation Lab bei Thoughtworks in Indien.

powered by www.it-daily.net


Mehr Artikel

Rüdiger Linhart, Vorsitzender der Berufsgruppe IT der Fachgruppe UBIT Wien. (c) WeinwurmFotografie
Interview

IT-Berufe im Fokus: Innovative Lösungen gegen den Fachkräftemangel

Angesichts des anhaltenden IT-Fachkräftemangels ist schnelles Handeln gefordert. Die Fachgruppe IT der UBIT Wien setzt in einer Kampagne genau hier an: Mit einem breiten Ansatz soll das vielfältige Berufsbild attraktiver gemacht und innovative Ausbildungswege aufgezeigt werden. IT WELT.at hat dazu mit Rüdiger Linhart, Vorsitzender der Berufsgruppe IT der Fachgruppe UBIT Wien, ein Interview geführt. […]

News

ISO/IEC 27001 erhöht Informationssicherheit bei 81 Prozent der zertifizierten Unternehmen

Eine Umfrage unter 200 Personen verschiedener Branchen und Unternehmensgrößen in Österreich hat erstmals abgefragt, inwiefern der internationale Standard für Informationssicherheits-Managementsysteme (ISO/IEC 27001) bei der Bewältigung von Security-Problemen in der Praxis unterstützt. Ergebnis: Rund 81 Prozent der zertifizierten Unternehmen gaben an, dass sich durch die ISO/IEC 27001 die Informationssicherheit in ihrem Unternehmen erhöht hat. […]

News

Public Key Infrastructure: Best Practices für einen erfolgreichen Zertifikats-Widerruf

Um die Sicherheit ihrer Public Key Infrastructure (PKI) aufrecht zu erhalten, müssen PKI-Teams, sobald bei einer Zertifizierungsstelle eine Sicherheitslücke entdeckt worden ist, sämtliche betroffenen Zertifikate widerrufen. Ein wichtiger Vorgang, der zwar nicht regelmäßig, aber doch so häufig auftritt, dass es sich lohnt, PKI-Teams einige Best Practices für einen effektiven und effizienten Zertifikatswiderruf an die Hand zu geben. […]

News

UBIT Security-Talk: Cyberkriminalität wächst unaufhaltsam

Jedes Unternehmen, das IT-Systeme nutzt, ist potenziell gefährdet Opfer von Cyberkriminalität zu werden, denn die Bedrohung und die Anzahl der Hackerangriffe in Österreich nimmt stetig zu. Die Experts Group IT-Security der Wirtschaftskammer Salzburg lädt am 11. November 2024 zum „UBIT Security-Talk Cyber Defense“ ein, um Unternehmen in Salzburg zu unterstützen, sich besser gegen diese Bedrohungen zu wappnen. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*