Infrastruktur an den tatsächlichen Bedarf anpassen

Ein Server, der zu zehn Prozent ausgelastet ist, verbraucht nicht zehn Prozent seines Stroms. Er verbraucht typischerweise die Hälfte. Diese Leerlaufaufnahme ist der unangenehmste Befund der Serverhardware: Zwischen „eingeschaltet und tut nichts“ und „eingeschaltet und arbeitet“ liegt energetisch weniger, als jeder Betreiber gerne hätte. Und weil in vielen Rechenzentren die durchschnittliche Auslastung im niedrigen zweistelligen Prozentbereich liegt, läuft ein erheblicher Teil der weltweiten Serverkapazität dauerhaft im teuersten Betriebszustand: fast leer, aber voll unter Strom. Genau hier setzt Guideline 4.11 an. Ihr Leitsatz verlangt eine Infrastruktur, die sich am Bedarf ausrichtet und effizient skaliert, statt vorsorglich zu groß gebaut zu werden.

Meine Einordnung

Ein zu schwacher Server schadet der Umwelt. Das ist die vertraute Hälfte der Wahrheit: lange Antwortzeiten, wartende Geräte, abbrechende Besucher, wiederholte Anfragen. Die unvertraute Hälfte ist die andere Richtung. Ein zu leistungsfähiger Server schadet ebenfalls, nur unsichtbarer. Er zieht seine Grundlast, ob Du ihn brauchst oder nicht. Er wurde produziert, mit allem was an Material, Energie und Wasser darin steckt. Und diese Herstellungsemissionen fallen einmalig an, unabhängig davon, ob Du die Maschine später zu 8 oder zu 80 Prozent nutzt. Verteilt auf tatsächlich geleistete Arbeit wird ein überdimensionierter Server pro Anfrage regelrecht teuer.

Bemerkenswert finde ich den zweiten Satz des Kriteriums: eigenständige Instanzen vor verteilten Aufbauten. Das läuft dem verbreiteten Reflex entgegen, Verfügbarkeit immer durch Vervielfachung zu lösen. Drei Zonen bedeuten dreimal Grundlast, dreimal Hardware, dreimal Wartung. Für einen Bezahldienst mit vertraglicher Verfügbarkeitszusage kann das richtig sein. Für die meisten Unternehmenswebsites ist es Vorsorge gegen ein Ereignis, das seltener eintritt als der Konfigurationsfehler, den die zusätzliche Komplexität erst ermöglicht.

Der dritte Satz ist der praktisch folgenreichste. Für Durchschnittslast dimensionieren, nicht für Spitzenlast. In der Praxis passiert fast immer das Gegenteil: Jemand erinnert sich an den einen Newsletter-Versand oder den einen Messetag, an dem es eng wurde, und bucht dauerhaft die nächstgrößere Stufe. Damit ist ein Ausnahmefall von wenigen Stunden zur Grundlage für 8.760 Betriebsstunden im Jahr geworden.

Wo ich weiter gehe

Die Guideline beantwortet die Frage „wie groß soll die Maschine sein“. Ich stelle vorher eine andere: Warum braucht diese Website überhaupt so viel Rechenleistung?

In meiner Beratung sehe ich regelmäßig Server, die deshalb groß dimensioniert sind, weil bei jedem Seitenaufruf ein CMS Datenbankabfragen ausführt, Templates rendert und Plugins durchläuft, um ein Ergebnis zu erzeugen, das sich seit Wochen nicht geändert hat. Diese Rechenleistung ist keine Anforderung, sie ist eine Folge der Architektur. Wer HTML vorab erzeugt und statisch ausliefert, senkt den Bedarf nicht um Prozente, sondern um Größenordnungen. Dieselbe Seite läuft dann auf einer Maschine, die eine Nummer kleiner ist und trotzdem gelangweilt wirkt.

Und hier lauert die eigentliche Falle des modernen Infrastrukturdenkens.

Das ist der Rebound-Effekt in Reinform: Effizientere Bereitstellung führt nicht automatisch zu weniger Verbrauch, sondern häufig zu mehr Anspruch. Suffizienz beginnt nicht bei der Auswahl der Instanzgröße, sondern bei der Frage, welche Berechnung überhaupt stattfinden muss.

Dein erster Schritt heute

Die meisten Betreiber wissen nicht, wie ausgelastet ihr Server tatsächlich ist. Sie kennen nur das Gefühl, dass es „gut laufen“ soll.

Wenn Dir die kleinere Stufe zu knapp erscheint, dann optimiere zuerst die Seite und miss danach erneut. Fast immer verschwindet das Problem, statt kleiner zu werden.

Ein Server, der für den Ausnahmefall gebaut wurde, verbringt sein ganzes Leben mit dem Regelfall.

Quelle: W3C-Fassung von Guideline 4.11