Die Informationslage, wie man einen ESG-Report schreibt und was da drinnen stehen soll, ist äußerst dürftig. Es gibt ein paar brauchbare Beispiele, aber gerade in unserem Umfeld – Softwareentwicklung – ist wenig zu finden. Des Googelns überdrüssig haben wir uns daher gedacht, wir machen es einfach. Wir nehmen ein kleines internes Projekt und erstellen einen ESG-Bericht. Fokussiert auf den Bereich, den wir unter Kontrolle haben, in dem wir uns auskennen: Softwareentwicklung, Deployment und Performanceoptimierung. Die Wahl fiel auf MEGA- Make Monatsabrechnung Great Again.
- Learning Friday
- Software-Entwicklung
ESG in a Nutshell
ESG steht für Environmental – Social – Governance und ist eine Verordnung der EU, mit der Sozial- und Umweltstandards in der EU verbessert werden sollen. Unter anderem soll damit auch der CO2-Ausstoß in der EU verringert werden. Der erste Schritt dazu ist, dass Firmen ESG-Berichte abliefern, in denen sie die ESG-Themen beleuchten und Strategien beschreiben, mit denen sie Verbesserungen erreichen wollen.
Gepardec ist zwar noch zu klein, um direkt von der Verordnung betroffen zu sein, aber erstens wachsen wir, zweitens haben wir einige Kund:innen, die davon betroffen sind, und abgesehen von der Berichtspflicht hat das Einsparen von Ressourcen (Energie) auch handfeste finanzielle Vorteile, die wir gemeinsam mit unseren Kund:innen nutzen können.
Koalition!
Einen Report zu schreiben, zu erkennen, wo es Einsparungspotential gibt, ist eine Sache, aber schließlich wollen wir ja die Welt nicht nur beschreiben, sondern auch ändern, verbessern. Daher haben wir ein paar Gepardenkolleg:innen eingefangen und überzeugt, dass sie helfen, unsere Verbesserungsvorschläge umzusetzen.
Ziele
Ungefähr zu wissen, wo man hin will, wenn man gemeinsam losgeht, halten wir für einen guten Ansatz. Daher haben wir uns ein Ziel überlegt:
Der Ausstoß von CO2 Äquivalenten von MEGA ist bis Ende Mai 2024 auf 30% im Vergleich zu Anfang 2024 reduziert.
Das war Ende März 2024. 70% Einsparung in zwei Monaten. MEGA ist zwar nicht mega, aber das ist trotzdem ein gutes Ziel. Wir wussten auch noch nicht, wo die Schwachstellen, die Energiefresser liegen.
Messen, messen, messen
Jetzt ging es ums Messen. Glücklicherweise hatten wir einen DevOps Engineer im Team und unser OpenShift Cluster ist mit Loki und Grafana ausgestattet. Damit haben wir gute Voraussetzungen, um Leistungsdaten, auch aus der Vergangenheit, zu bekommen.
Die erste Analyse des CPU-Verbrauchs ergab die erste wichtige Erkenntnis: Das größte Problem war nicht unbedingt durch die Last der Produktionsumgebung gegeben, sondern durch die hohe Anzahl an Testumgebungen. Grafisch dargestellt:
Der Hintergrund ist, dass wir ein ziemlich praktisches System aufgebaut haben, so dass beim Erzeugen eines Branches auch gleich eine Testumgebung zum Testen des Codes erzeugt wird. Sehr cool, aber die Kehrseite ist, dass, wenn Branches nicht regelmäßig gelöscht werden, auch Testumgebungen liegen bleiben. Mit dem Löschen von ein paar Branches konnten wir schnell Abhilfe schaffen, aber mittelfristig müssen wir organisatorische Maßnahmen ergreifen, um hier effizient zu bleiben.
Energie!
CPU-Seconds sind das eine, aber was bedeutet das an Energieverbrauch und an CO2-Äquivalenten? Hier ist einerseits Rechnen angesagt, andererseits begeben wir uns auf schwammiges Terrain, da die Umrechnung von vielen Variablen abhängt, über die wir noch wenig Informationen haben.
Um von den virtuellen CPU-Sekunden auf reale Werte des Stromverbrauchs zu kommen, haben wir eine Referenz-CPU herangezogen. Die Auswahl dieser war arbiträr.
Der tatsächliche Verbrauch setzt sich aus der Grundlast (Idle) und dem Verbrauch der CPU bei Berechnungen zusammen. Die Grundlast ist abhängig von den für den Namespace reservierten CPU Sekunden, repräsentiert durch die Metrik der “Requested CPU Seconds”. Diese Last entsteht immer, auch wenn die Pods keine CPU Zeit verbrauchen, da CPU Zeit reserviert wird. Diese Grundlast wird mit dem Stromverbrauch im Idle berechnet.
Der Stromverbrauch der tatsächlich verwendeten CPU wird mithilfe der gemessenen CPU Sekunden und dem Stromverbrauch bei maximaler Auslastung berechnet.
Grundlast = CPUreq Pidle
Verbrauch = (Pmax – Pidle) CPUused
Der tatsächliche Verbrauch setzt sich aus einer Idle Grundlast in Gelb und den verbrauchten CPU Sekunden in Rot zusammen.
Kohlendioxid
Aus den obigen Werten für den Stromverbrauch können wir die verbrauchten CO2-Äquivalente abschätzen.
Für eine genaue Berechnung des im Betrieb verursachten CO2-Ausstoßes sind folgende Informationen notwendig:
- der tatsächliche Stromverbrauch
- die CO2-Intensität des verbrauchten Stroms
Der Stromverbrauch wird in unserem Fall aus den gemessenen CPU-Sekunden ermittelt.
Informationen zu der CO2-Intensität des verbrauchten Stroms sind mitunter schwierig zu ermitteln. Mögliche Quellen sind:
- WattTime (https://watttime.org/) – kommerziell
- Electricity Maps (https://www.electricitymaps.com/) – kommerziell
- Our World in Data (https://ourworldindata.org/grapher/carbon-intensity-electricity)
Die öffentlich verfügbaren Daten sind eher grobgranular und erlauben nur eine grobe Abschätzung des tatsächlichen CO2-Fußabdrucks.
Daraus ergeben sich für die Kalenderwochen 8 bis 12 folgende CO2-Äquivalente:
| Alle Namespaces | KW-8 | KW-10 | KW-11 | KW-12 |
|---|---|---|---|---|
| CPU Seconds Average | 0.1064 | 0.1188 | 0.1061 | 0.1361 |
| Idle Grundverbrauch | 3.589 W | 3.916 W | 4.380 W | 5.406 W |
| Actual CPU Verbrauch | 0.682 W | 0.762 W | 0.680 W | 0.873 W |
| Anteil CPU gemessen an Gesamt | 15.97% | 16.29% | 13.44% | 13.90% |
| Aufs Monat gerechnet | 3.118 kWh | 3.415 kWh | 3.694 kWh | 4.584 kWh |
| Aufs Jahr gerechnet | 37.413 kWh | 40.977 kWh | 44.325 kWh | 55.003 kWh |
| ~ Ausstoß an kgCO₂ eq / Jahr | 6.14 kgCO₂ | 6.72 kgCO₂ | 7.27 kgCO₂ | 9.02 kgCO₂ |
Cheeseburger!
Aus der Analyse der Daten haben wir folgende Empfehlungen abgeleitet:
- Als unmittelbar wirksamste Maßnahme empfehlen wir eine Reduktion der Anzahl der Non-Prod Umgebungen.
- Aktuell werden mehr als 80% der Energie durch Leerlauf (Idle) verbraucht. Wir empfehlen eine Reduktion der “requested CPU”, damit sie näher am tatsächlichen Verbrauch liegt.
- Um außerhalb der Nutzungszeiten (zum Monatswechsel, tagsüber) den CO2 Verbrauch zu optimieren, empfehlen wir die Deployments zu diesen Zeiten auf Null zu skalieren (LightSwitchOps Konzept). Dafür empfehlen wir das Aufsetzen eines entsprechenden Projektes.
Die Umsetzung der Maßnahmen ergäbe, auf ein Jahr gerechnet, ein Einsparungspotential von ca. 5 kg CO2, das entspricht ca. zwei Cheeseburgern!
Zur Feier des Tages genehmigten wir uns je einen Cheesburger.
Fazit
Auch wenn an diesem Beispiel keine nennenswerten Einsparungen an CO2-Äquivalenten realistisch sind, zeigt dieses kleine Beispiel doch, wie man auch in größeren Installationen eine Abschätzung des CO2-Verbrauchs durchführen kann. Wir glauben, dass die Problembereiche für diese Anwendung auch für größere Anwendungen relevant sind und dass dort größere Einsparungen, sowohl bei CO2-Äquivalenten, aber auch aus rein finanzieller Sicht, möglich sind.
