Kapazitätsplanung ist die Praxis, vorherzusagen, wie viel Rechen-, Speicher-, Storage- und Netzwerkkapazität ein System benötigt, um die erwartete Nachfrage unter Einhaltung seiner Zuverlässigkeits- und Performance-Ziele zu bedienen. Sie verbindet Auslastungs- und Sättigungsmetriken, Nachfrageprognosen, Lasttests und Vorlaufzeiten zu der Entscheidung, wann und wie stark skaliert wird.
Was ist Kapazitätsplanung?
Kapazitätsplanung beantwortet eine einfache Frage mit vielen Nuancen: Erfüllt das System seine Ziele auch nächste Woche, im nächsten Quartal und bei der nächsten Lastspitze, und was muss sich ändern, damit das so bleibt? Sie umfasst Rechenleistung, Speicher, Storage, Netzwerk, Datenbankverbindungen, Durchsatz von Queues, Lizenzgrenzen und Cloud-Quotas, kurz jede Ressource, die ausgehen kann.
Autoscaling in der Cloud hat Kapazitätsplanung nicht überflüssig gemacht, sondern die Fragen verschoben: Wo liegen Skalierungsgrenzen und Quotas, wie schnell reagiert die Skalierung im Vergleich zu Lastspitzen, welche Komponenten wie Datenbanken skalieren nicht horizontal, und was kostet die zusätzliche Kapazität?
Kapazitätsplanung ist außerdem nicht dasselbe wie Performance-Tuning. Tuning sorgt dafür, dass eine Komponente mit denselben Ressourcen mehr leistet. Kapazitätsplanung entscheidet, wie viele Ressourcen wo und bis wann gebraucht werden. Beides greift ineinander, denn jeder Effizienzgewinn verändert die Prognose.
Warum Kapazitätsplanung wichtig ist
- Zuverlässigkeit: Ressourcen nahe der Erschöpfung verursachen steigende Latenz und Fehler lange vor 100 %, weil sich Warteschlangen aufbauen.
- Kosten: Überdimensionierung verschwendet Geld, Unterdimensionierung führt zu Incidents und Notkäufen.
- Vorlaufzeit: Neue Hardware, Reserved Instances, Quota-Erhöhungen oder eine Datenbankmigration dauern Wochen und müssen geplant werden, bevor sie dringend sind.
- Geschäftsereignisse: Produktstarts, Kampagnen oder saisonale Spitzen brauchen Kapazität, die historische Durchschnittswerte nicht zeigen.
Wichtige Kennzahlen für die Kapazitätsplanung
Ein guter Ausgangspunkt ist die USE-Methode: Betrachten Sie für jede Ressource Auslastung, Sättigung und Fehler. Ergänzen Sie diese um Nachfragemetriken:
| Kategorie | Beispiele |
|---|---|
| Nachfrage | Requests pro Sekunde, aktive Nutzer, Nachrichten pro Sekunde, aufgenommene Daten pro Tag |
| Auslastung | CPU, Speicher-Working-Set, Plattenbelegung, Netzwerkbandbreite, Auslastung des Connection-Pools |
| Sättigung | Queue-Tiefe, CPU-Throttling, Länge der Run Queue, Consumer Lag, Wartezeit auf Verbindungen |
| Ergebnis | Latenz-Perzentile und Fehlerrate im Vergleich zum SLO |
Am nützlichsten ist oft das Verhältnis von Nachfrage zu Ressourcenverbrauch, etwa CPU-Sekunden pro tausend Requests. Es übersetzt eine Traffic-Prognose in eine Ressourcenprognose und macht Effizienzrückschritte nach Releases sichtbar.
Der Ablauf der Kapazitätsplanung
- Ist-Zustand messen, als Zeitreihen mit genug Historie, um Tages-, Wochen- und Saisonmuster zu erkennen.
- Grenze finden: per Lasttest für jede Komponente den Durchsatz ermitteln, ab dem Latenz oder Fehler das SLO verletzen, nicht den Punkt, an dem der Server abstürzt.
- Nachfrage prognostizieren aus Trends plus bekannten Geschäftsereignissen.
- Reserve festlegen: Puffer für Spitzen, für den Ausfall einer Zone oder eines Nodes (N+1) und für die Zeit, die das Bereitstellen neuer Kapazität dauert.
- Handeln und überprüfen: skalieren, optimieren oder umbauen, dann Prognose und Realität vergleichen und das Modell anpassen.
Wiederholen Sie diesen Zyklus in einem festen Rhythmus, etwa monatlich für schnell wachsende Dienste und quartalsweise für stabile, und zusätzlich vor jeder bekannten Lastspitze. Wichtig ist die Zuständigkeit: Jedes Service-Team sollte seine eigenen Grenzen und Prognosen kennen, während ein Plattform- oder SRE-Team sie für gemeinsam genutzte Ressourcen wie Cluster, Datenbanken und Netzwerkverbindungen zusammenführt.
Beispiel: eine einfache Kapazitätsrechnung
Ein illustratives Szenario: Lasttests zeigen, dass eine Instanz einer API die p99-Latenz bis 400 Requests pro Sekunde innerhalb des SLO hält. Die heutige Spitze liegt bei 2.000 Requests pro Sekunde, die Prognose erwartet in den nächsten sechs Monaten 30 % Wachstum, also etwa 2.600 Requests pro Sekunde. Der Dienst läuft in drei Zonen und muss den Verlust einer Zone überstehen. Der reine Bedarf beträgt 2.600 / 400 = 6,5, also 7 Instanzen. Damit nach Ausfall einer Zone weiterhin 7 Instanzen bereitstehen, müssen die beiden verbleibenden Zonen sie tragen, also 4 pro Zone und 12 insgesamt. Little's Law (Parallelität = Ankunftsrate × Verweildauer) lässt sich ebenso nutzen, um Connection-Pools und Worker-Anzahl aus Durchsatz und Latenz abzuleiten.
Typische Fehler
- Planung mit Durchschnittswerten statt mit Spitzen und Perzentilen. Ein Tagesmittel verschleiert die Stunde, in der das System tatsächlich an seine Grenze stößt.
- Lasttests mit unrealistischen Daten oder Zugriffsmustern, etwa ohne kalte Caches oder mit zu wenigen unterschiedlichen Nutzern, die zu optimistische Grenzwerte liefern.
- Sehr hohe Zielauslastung: Die Latenz steigt stark an, je näher die Auslastung an die Sättigung rückt.
- Nicht skalierbare Komponenten übersehen, etwa eine einzelne primäre Datenbank, eine Drittanbieter-API mit Rate Limits oder Cloud-Quotas.
- Kapazitätsplanung als jährliche Tabellenübung statt als laufende Überprüfung entlang von Durchsatz-Trends und Releases.
Wie Obseria hilft
Obseria bewahrt Metriken 13 Monate auf, sodass saisonale Muster und Vorjahresvergleiche für Prognosen verfügbar sind. Sie fragen Nachfrage und Ressourcenverbrauch mit PromQL oder SQL ab, setzen sie in Bezug zu den Golden Signals jedes Dienstes und erkennen unerwartetes Wachstum früh per Anomalieerkennung. Das Cloud-Kostenmanagement verknüpft Kapazitätsentscheidungen mit den Ausgaben.
