Glossar
Rightsizing
Auch: Right Sizing · Ressourcen anpassen
Ressourcen auf die tatsächlich benötigte Größe bringen, statt auf die, die beim Anlegen gewählt wurde.
Fast jede Instanz, jeder Container und jede Datenbank ist beim Anlegen größer gewählt worden als nötig. Das ist kein Versehen, sondern eine rationale Reaktion auf die Anreizlage: Wer zu klein dimensioniert und damit einen Ausfall verursacht, hat ein Gespräch vor sich. Wer doppelt so groß baut wie nötig, hat keins, weil die Kosten niemandem auffallen.
Rightsizing heißt deshalb nicht, an einem Regler zu drehen, sondern die Angst durch Daten zu ersetzen. Grundlage sind Auslastungswerte über mindestens vierzehn Tage, damit Wochenrhythmus und Monatsspitzen enthalten sind. Erst dann lässt sich sagen, ob eine Reservierung von acht Gigabyte bei einem Wochenmittel von 1,2 Gigabyte wirklich gebraucht wird.
Bei Containern ist die Reservierung der Hebel, nicht die tatsächliche Nutzung: Bei ECS auf Fargate wird nach reservierter CPU und reserviertem Speicher abgerechnet, unabhängig davon, ob die Aufgabe sie nutzt. Eine Task mit vier Gigabyte Reservierung und 700 Megabyte Verbrauch kostet das Vierfache dessen, was sie müsste.
Bei Lambda funktioniert es umgekehrt zur Intuition: Die Speichereinstellung bestimmt auch die zugeteilte CPU, abgerechnet wird in Gigabyte-Sekunden. Mehr Speicher lohnt sich genau dann, wenn die Laufzeit überproportional fällt. Es gibt Funktionen, die mit doppeltem Speicher günstiger laufen als vorher.
Der Reihenfolge nach gehört Rightsizing nach hinten, nicht nach vorn. Wer eine Last verkleinert, die im nächsten Schritt ohnehin wegoptimiert wird, hat die Sorgfalt verschwendet. Erst löschen, was niemand braucht, dann Beobachtbarkeit und Daten in den Griff bekommen, dann verkleinern.
Woran Sie es erkennen
- CPU-Auslastung im Wochenmittel unter zehn Prozent bei mehreren Instanzen.
- Task-Definitionen mit Reservierungen, die seit dem ersten Tag unverändert sind.
- Kapazität für einen Lastfall, der zweimal im Jahr eintritt, wird rund um die Uhr vorgehalten.
Nicht zu verwechseln mit
- Auto Scaling
- Passt die Anzahl der Einheiten an die Last an. Rightsizing passt die Größe einer Einheit an. Beides zusammen ist sinnvoll, aber Auto Scaling auf falsch dimensionierten Einheiten skaliert die Verschwendung mit.
- Savings Plans
- Ein Rabatt auf das, was läuft. Wer vor dem Rightsizing committet, zementiert die zu große Dimensionierung für ein bis drei Jahre.
- Spot-Instances
- Günstigere Kapazität für unterbrechbare Lasten, unabhängig von der Größe. Ändert den Preis pro Einheit, nicht die Frage, ob die Einheit zu groß ist.
Wann es trägt
- Es liegen mindestens vierzehn Tage Auslastungsdaten vor.
- Die Bereinigung ungenutzter Ressourcen ist bereits durch.
- Die Architektur der betroffenen Komponente ist stabil, es steht kein Umbau an.
Wann nicht
- Vor dem Aufräumen. Eine Ressource, die gelöscht gehört, muss nicht verkleinert werden.
- Bei Komponenten, deren Lastprofil sich gerade ändert, etwa nach einer Migration.
- Ohne Rückweg. Jede Verkleinerung braucht einen Weg zurück und eine Woche Beobachtung.
Wie man rangeht
- Auslastung über vierzehn Tage erhebenContainer Insights, CloudWatch-Agent oder die Metriken des jeweiligen Dienstes. Wichtig sind Mittelwert und Perzentile, nicht der Spitzenwert allein: ein einzelner Ausschlag rechtfertigt keine dauerhafte Reservierung.
- Eine Stufe kleiner, nicht dreiWer in einem Schritt auf ein Viertel springt, erzeugt den Ausfall, der das ganze Vorhaben diskreditiert. Eine Stufe runter, eine Woche beobachten, dann die nächste.
- Lambda ausmessen statt schätzenMit Lambda Power Tuning die Kurve aus Speicher, Laufzeit und Kosten je Funktion ermitteln. Eine halbe Stunde pro Funktion, und das Ergebnis widerspricht regelmäßig der Erwartung.
- Graviton mitnehmen, wo es ohne Aufwand gehtBei Managed Services bringt der Wechsel auf ARM-Instanzen rund 20 Prozent bei minimalem Aufwand. Bei eigenen Workloads dort, wo Container ohnehin multi-arch gebaut werden.
- Wirkung nachmessenNicht die geschätzte Ersparnis notieren, sondern die tatsächliche aus dem Cost and Usage Report. Die Differenz zwischen beiden ist die Lernkurve.
Häufig gefragt
Wie viel bringt Rightsizing typischerweise?
In gewachsenen Umgebungen regelmäßig zwischen 20 und 40 Prozent der Rechenkosten. In einem Projekt über zwölf Monate waren es rund 2.000 Euro im Monat, allerdings erst nachdem Löschen, Beobachtbarkeit und Datenmengen abgearbeitet waren. Vorher hätte dieselbe Arbeit an Lasten stattgefunden, die danach ohnehin weg waren.
Reichen die Empfehlungen von AWS Compute Optimizer?
Als Ausgangspunkt ja, als Entscheidung nein. Der Dienst sieht Metriken, nicht Fachlichkeit. Er kennt weder den Jahresabschluss, an dem die Last dreifach ist, noch die Tatsache, dass eine Komponente in sechs Wochen abgeschaltet wird.
Was ist mit dem Risiko?
Es wird durch die Schrittfolge klein gehalten: eine Stufe, eine Woche Beobachtung, dann weiter. Jede Änderung ist in Minuten rückgängig zu machen. Das eigentliche Risiko liegt nicht im Verkleinern, sondern im Verkleinern ohne Rückweg und ohne Alarm.
Warum kommt Rightsizing erst spät in der Reihenfolge?
Weil die vorherigen Schritte die Grundgesamtheit verändern. Wer eine Instanz verkleinert, deren Last durch einen Cache oder einen abgeschalteten Polling-Prozess ohnehin verschwindet, hat zweimal gearbeitet. Nach dem Aufräumen ist außerdem klar, welche Last dauerhaft bleibt, und nur die gehört dimensioniert.