Welchen CO₂-Fußabdruck hat Software?
Welchen CO₂-Fußabdruck hat Software eigentlich und wie berechnet man ihn? Spoiler: High Level ist das recht einfach zu beschreiben. Die konkrete Messung aller Details gestaltet sich dann doch immer noch knifflig. Auch die Tools der Cloud-Anbieter arbeiten partiell mit Schätzungen. Trotzdem reicht die Genauigkeit definitiv, um die Software-Entwicklung in Richtung Green Software zu steuern. Zumal in anderen Bereichen mit weit gröberen Schätzwerten gerechnet wird, z.B. wenn ein pauschaler Emissionswert für einen Briefversand angenommen wird. Hier werden praktisch immer 20 g CO₂ angesetzt. Ein Wert, der aus einer einzigen Studie stammt, der Daten aus den USA zugrunde liegen – undifferenzierter geht es wohl kaum. Im Vergleich zu solchen Angaben sind die Messungen von Software-Emissionen hochpräzise.
Emissionen von Software
Programme an sich verursachen erst einmal keine Emissionen. Sie induzieren Emissionen indirekt über die Hardware, auf der sie laufen. Dies tun sie auf zwei Arten, die beide auch in den SCI-Index einfließen, den wir in der Green Software Foundation definiert haben, um die Klimawirkung von Software zu bewerten:
- Emissionen aus dem Stromverbrauch und
- In der Hardware gebundene Emissionen
Emissionen der Hardware ermitteln
Die genutzte Hardware muss produziert und entsorgt werden. Dabei fallen jeweils Emissionen an, sogenannte Embodied Emissions. Um diese zu verstehen, muss man im Grunde eine Lebenszyklus-Analyse der Hardware durchführen. Das ist keine leichte Aufgabe, was übrigens für auch für alle anderen Produkte gilt. Man greift dabei üblicherweise auf entsprechende Datensammlungen zurück, sogenannte Life Cycle Inventories (LCIs). Bei Hardware verlassen wir uns derzeit auf die Angaben der Hersteller oder Cloudbetreiber. Als Beispiel hier ein Data Sheet für einen Desktop. Dieses Verfahren eignet sich für Hardware, die man selbst bereitstellt und nutzt, also eigene Rechenzentren. Cloud-Provider liefern in der Regel aggregierte Daten für die verschiedenen Emissionen-Formen. Wobei z.B. Google bei der Hardware nur sogenannten „Upstream-Emissionen“ berücksichtigt, also solche aus der Produktion. Emissionen aus der Entsorgung bleiben demnach außen vor.
Emissionen aus Stromverbrauch ermitteln
Dynamischer und damit spannender für die Entwicklung von Green Software sind Emissionen, die aus dem Stromverbrauch resultieren. Der Stromverbrauch lässt sich gut ermitteln, wenn von definierter (auch virtueller) Hardware ausgegangen werden kann. Hier existieren entsprechende Tools. Auch wenn diese nicht 100 % akkurat sind, weil sie z.B. den Eigenverbrauch des Hypervisors nicht berücksichtigen, liefern sie wirklich nützliche Ergebnisse. Schwieriger wird es, wenn Software-Container von Cloud-Management-Software automatisch auf unterschiedlicher Hardware gestartet werden. Dann müsste jeweils ein passender Anteil an den Embodied Emissons der zeitlich befristet genutzten Hardware berechnet werden. Ähnliche Schwierigkeiten stellen sich bei verteilten Systemen, wenn sogenannte Shared Services genutzt werden, wie sie z.B. bei Datenbanken üblich sind oder bei SAN-Speichern.
Über den Stromverbrauch der eigentlichen Server hinaus benötigt das (Cloud-) Rechenzentrum zusätzlichen Strom, z.B. für USV und Klimatisierung. Dieser Zusatzverbrauch wird im Faktor Power Usage Efficiency (PUE) zusammengefasst. Den Gesamtverbrauch erhält man somit aus der Multiplikation von Server-Stromverbrauch mit der PUE.
Ist der Stromverbrauch bekannt, lassen sich daraus die Emissionen ableiten. Dies geschieht am sinnvollsten nach dem netzbasierten Verfahren, welches im Grunde besagt, dass aus der Steckdose derselbe Strom herauskommt, der am anderen Ende der Leitung produziert wurde. Und zwar unabhängig davon, ob man einen Ökostrom-Tarif gebucht hat oder nicht. Bei Rechenzentren in Deutschland kann man für die Umrechnung von kWh in gCO₂-Emissionen auf die Werte des Umweltbundesamtes zurückgreifen. Bei Cloud-Rechenzentren in anderen Gegenden der Welt sollte man die dortigen Emissionen zugrunde legen.
Angaben von Cloud-Anbietern
Die großen Cloud-Anbieter liefern mehr oder weniger konkrete Daten zu den Emissionen, die Software erzeugt. Oder sie stellen Tools bereit, mit denen man selbst einen Verbrauch ermitteln kann. Siehe zum Beispiel diese Berichte zu AWS-Emissionen oder Google Cloud oder das Toolkit von Azure zur Ermittlung des SCI-Scores. Wie oben schon gesagt, sind diese Daten teils nicht vollständig und enthalten immer teils Schätzungen. Aber sie sind gut und auf jeden Fall sehr hilfreich.
Messung in Produktion oder auf einem Testsystem?
Wo messe ich eigentlich am sinnvollsten? In der Produktionsumgebung oder auf einem dedizierten Testsystem? Das kommt darauf an, wozu ich die Ergebnisse nutzen will. Für Nachhaltigkeitsberichte sind die Emissionen in Produktion relevant. Dort liegt auch die tatsächliche Nutzung der Software durch die Anwender zugrunde. Die Messwerte sind somit realistischer, aber auch komplizierter zu ermitteln und dadurch womöglich nur auf andere Weise unpräzise als auf einem Testsystem. Ein dediziertes Testsystem hat den Vorteil, dass man volle Kontrolle über das System hat. Störungen werden vermieden und Hardware-Ressourcen sind konkret zurechenbar (weil z.B. Speicher nicht in ein SAN ausgelagert ist). Dadurch kann der Einfluss von Software-Änderungen auf einzelne Hardware-Komponenten besser nachvollzogen werden. Allerdings kann man das Nutzerverhalten hier nur simulieren.
Um die eigene Software-Entwicklung in Richtung von Green Software zu steuern, empfiehlt sich die regelmäßige Messung auf einem festen Testsystem. So erkennt man präzise die Wirkungen der aktuellen Weiterentwicklung und kann nötigenfalls rechtzeitig gegensteuern. Auch der SCI-Wert wurde für solche Vergleiche über die Zeit hinweg konzipiert. Die Auswertung verfügbarer Daten aus dem Monitoring der Produktionsumgebung ist ergänzend sinnvoll. Hier erkennt man vor allem Verbesserungspotentiale in der Abstimmung der Software auf die Hardware und das Load Management in Produktion.