Sustainability in Software Engineering, Teil 4: Zombies

Martin Lippert

Der Klimawandel ist real, und jeder muss einen Beitrag dazu leisten, ihn zu stoppen – auch und vielleicht sogar gerade Softwareentwickler. Aber wie?

Die ersten drei Teile dieser Serie haben gezeigt, wie hoch der Energiebedarf zum Betrieb von Software ist. Der Energieverbrauch und die damit verbundenen CO₂-Emissionen setzen sich aus einer Vielzahl von Faktoren zusammen. Dazu gehören der eigentliche Stromverbrauch für die Hardware, die Datenübertragung über das Netzwerk, die Kühlung des Rechenzentrums und die Herstellung der verwendeten Hardware. Je weniger Ressourcen die Software benötigt, desto weniger CO₂-Emissionen verursacht ihr Betrieb.

Einen Weg, den Ressourcenverbrauch erheblich zu reduzieren, hat die Serie bisher noch nicht beleuchtet: Die Software gar nicht – oder zumindest nicht immer – laufen zu lassen. Das mag trivial klingen, aber ein Blick auf konkrete Daten gibt Einblick in das Potenzial.

Energiehungrige Zombies

Jon Taylor von Anthesis und Jonathan Koomey von der Stanford University haben 2017 die Studie [5] "Zombie/Comatose Servers Redux" veröffentlicht, in der sie die Auslastung von reservierten Maschinen in Rechenzentren über einen längeren Zeitraum untersucht haben. Ziel war es herauszufinden, ob und wie stark für eine Software in Betrieb befindliche physikalische und virtuelle Maschinen tatsächlich ausgelastet und genutzt werden.

Das Ergebnis der Studie überrascht: Grob vereinfacht zeigt sie, dass in den untersuchten Rechenzentren zwischen 25 und 30 Prozent der physikalischen Server sogenannte Zombies waren. Selbst bei den untersuchten virtuellen Maschinen (VMs) gehörten 30 Prozent zu der Zombiegruppe, obwohl sie eigentlich das Auslastungsproblem lösen sollten.

Als Zombie gilt eine Maschine oder eine VM, die über mindestens sechs Monate keine Anzeichen von Netzwerk-, CPU-, Memory- oder Benutzer-Aktivität zeigt. Zwar ist dabei der Energieverbrauch deutlich geringer als der von Maschinen, die unter Last laufen. Mit Blick auf alle Faktoren wie CPU, reserviertem Speicher, Hardwareherstellung und Kühlung verbraucht ein Zombie in der Praxis jedoch immer noch etwa halb so viel Energie wie ein produktives System. Das ist vor allem mit Blick auf den hohen Anteil der Maschinen im Zombiemodus ein beachtlicher Wert.

Daneben zeigt die Studie einen weiteren nennenswerten Bereich: physikalische Server und virtuelle Maschinen im Status "Idle". Laut Definition handelt es sich um Maschinen, die maximal über fünf Prozent der betrachteten Zeit Aktivität im Netzwerk- und CPU--Bereich aufweisen. Das bedeutet, dass sie über 95 Prozent der Zeit nicht aktiv sind, aber ebenso wie Zombies in signifikantem Ausmaß Ressourcen verbrauchen.

Großes Potenzial

Der Blick auf die Zahlen zeigt, dass in Rechenzentren viel Energie schlicht verschwendet wird, weil Software läuft, die nicht oder nur selten produktiv arbeitet. Wir müssen daher konsequent die nicht genutzte Software abschalten, reservierte Ressourcen im Rechenzentrum freigeben und Software nur betreiben, wenn wir sie benötigen und nutzen. Was trivial klingt, geschieht in der Praxis leider viel zu selten, wie die Studie eindrucksvoll belegt.

Eine Inventur des Bestands kann erstaunliche Einblicke geben und helfen, nicht genutzte Software konsequent abzuschalten.

Nach unten skaliert

Wer Software nicht komplett abschalten kann, sie aber selten nutzt, sollte einen Scale-To-Zero-Ansatz in Betracht ziehen: Die Software läuft nur bei Bedarf, und die Cloud-Plattform automatisiert den Start und das Abschalten.

Prominente Scale-To-Zero-Umsetzungen sind die sogenannten Serverless-Computing-Plattformen, die Software nur bei Bedarf starten. Im Extremfall stößt die Plattform die Software erst beim Eintreffen eines Request an und beendet sie unmittelbar danach wieder.

Nicht jede Software ist von Haus aus für einen solchen Einsatz geeignet. Viele herkömmliche Enterprise-Architekturen und -Anwendungen sind auf einen langfristigen Einsatz implementiert und haben Startup-Zeiten von mehreren Sekunden bis Minuten. Solche Systeme lassen sich nicht unverändert auf einer Serverless-Computing-Plattform betreiben.

Neue Architekturen, neue Wege

Gerade im Enterprise-Umfeld existieren inzwischen zahlreiche Architekturen. Die vielfältige Landschaft gibt Entwicklern Spielraum für Entscheidungen.

Das soll ein Beispiel veranschaulichen: Viele Unternehmen implementieren seit Jahren ihre Enterprise-Anwendungen mit Java und betreiben sie auf einer Java Virtual Machine (JVM). Häufig nutzen sie zusätzlich Frameworks wie Spring Boot.

An eine Startup-Zeit von wenigen Millisekunden war dabei bis vor Kurzem nicht zu denken. Das hat sich mit dem Native-Image-Ansatz von Oracles GraalVM verändert. Mit ihr lassen sich viele Java-Anwendungen in native Executables überführen, die in wenigen Millisekunden starten. Das dazu passende Spring-Native-Projekt [6] erlaubt das Erstellen solcher ohne VM laufenden Software für leicht angepasste Spring-Boot-Anwendungen. Das ist aus meiner Sicht eine sinnvolle Option angesichts von Millionen solcher Anwendungen, die weltweit in Rechenzentren laufen.

Aus Nachhaltigkeits-Perspektive ist ein weiterer Vorteil, dass eine Spring-Boot-Anwendung als natives Executable keine JVM benötigt und der damit verbundene Overhead entfällt. Die Anwendungen kommen oft mit weniger Speicher aus.

Aufräumen nicht vergessen

Dank Virtualisierung und Cloud-Plattformen lassen sich neue virtuelle Maschinen, ganze Kubernetes-Cluster, Datenbanken oder andere Ressourcen einfach auf Knopfdruck reservieren und mit Software bestücken. Wir dürfen dabei aber nicht vergessen, schonend damit umzugehen und sie wieder freizugeben. In Zukunft wird sich das vermutlich weiter automatisieren lassen. Bis dahin (und darüber hinaus) gilt: Aufräumen nicht vergessen!

Martin Lippert
arbeitet bei VMware an Entwicklungswerkzeugen und IDEs für Spring und Spring Boot. Er ist langjähriges aktives Mitglied der Eclipse Community, diente im Program Committee für zahlreiche internationale Konferenzen und blickt auf eine lange Historie von Konferenzvorträgen zurück. Das Thema Sustainability liegt ihm besonders am Herzen.

URL dieses Artikels:
https://www.heise.de/-6167056

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Sustainability-im-Software-Engineering-Teil-1-ein-Aufruf-6011723.html
[2] https://www.heise.de/hintergrund/Sustainability-im-Software-Engineering-Warum-auf-erneuerbare-Energien-warten-6029217.html
[3] https://www.heise.de/hintergrund/Sustainability-in-Software-Engineering-Teil-3-Datentransfer-im-Visier-6112966.html
[4] https://www.heise.de/hintergrund/Sustainability-in-Software-Engineering-Teil-4-Zombies-6167056.html
[5] https://www.anthesisgroup.com/report-zombie-and-comatose-servers-redux-jon-taylor-and-jonathan-koomey/
[6] https://www.heise.de/news/Java-Framework-Native-Spring-Anwendungen-laufen-ohne-die-JVM-5078681.html
[7] mailto:rme@ix.de

Adblock test (Why?)

Artikel von & Weiterlesen ( Sustainability in Software Engineering, Teil 4: Zombies - heise online )
https://ift.tt/3k74Hr4
Wissenschaft & Technik

Bagikan Berita Ini

Search

Sustainability in Software Engineering, Teil 4: Zombies - heise online