Katalog
concept#Plattform#Zuverlässigkeit#Architektur#DevOps

Autoscaling

Dynamische, automatische Anpassung von Instanzen und Ressourcen an Lasten zur Verbesserung von Verfügbarkeit und Kosten.

Autoscaling passt die Ressourcen- und Instanzanzahl einer Anwendung automatisch an reale Lastbedingungen an.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Container-Orchestratoren (z. B. Kubernetes HPA)Cloud Auto‑Scaling Services (z. B. AWS Auto Scaling)Monitoring- und Observability-Tools (Prometheus, Grafana)

Prinzipien & Ziele

Skalierung auf Grundlage messbarer Metriken, nicht vermuteter Last.Definierte Mindest- und Maximalgrenzen zur Vermeidung von Über- oder Unterskalierung.Safety‑Mechanismen (Cooldown, Rate‑Limits) verhindern oszillierendes Verhalten.
Betrieb
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Oszillation durch aggressive Skalierungsraten und fehlende Cooldowns.
  • Kostenexplosion bei fehlerhaften Regeln oder Lastvorhersage.
  • Kaskadierende Fehler, wenn abhängige Systeme nicht gleichzeitig skaliert werden.
  • Konservative Default‑Grenzen und iterative Anpassung statt aggressiver Regeln.
  • Mehrere Metriken kombinieren (z. B. CPU + Latenz) statt nur einer Kennzahl.
  • Cooldowns und Hysteresis verwenden, um Oszillationen zu vermeiden.

I/O & Ressourcen

  • Metriken (CPU, Memory, custom metrics, Queue‑Depth)
  • Skalierungsregeln und Policies (Min/Max, Targets, Cooldown)
  • Monitoring, Alerting und Observability‑Daten
  • Automatisch veränderte Kapazität (Skalierung hoch/runter)
  • Messbare Auswirkungen auf Latenz und Durchsatz
  • Auditierbare Skalierungsereignisse und Logs

Beschreibung

Autoscaling passt die Ressourcen- und Instanzanzahl einer Anwendung automatisch an reale Lastbedingungen an. Es optimiert Verfügbarkeit und Kosten, indem Kapazität dynamisch skaliert wird — in der Cloud, auf Container-Orchestratoren oder in hybriden Umgebungen. Entscheidungskriterien und Metriken steuern Regeln und Grenzwerte.

✔

  • Automatische Anpassung reduziert manuelle Eingriffe und Betriebsaufwand.
  • Kosteneffizienz durch bedarfsorientierte Ressourcenbereitstellung.
  • Verbesserte Verfügbarkeit und Reaktionsfähigkeit bei Lastspitzen.

✖

  • Skalierung reagiert meist verzögert; kurzfristige Peaks können unbehandelt bleiben.
  • Falsche Metriken oder Thresholds können zu Fehlverhalten führen.
  • Nicht alle Komponenten sind ohne weiteres horizontal skalierbar (Stateful Services).

  • Replikate/Instanzen

    Anzahl laufender Instanzen oder Pods zur Kapazitätsmessung.

  • CPU-/Speicherauslastung

    Prozentuale Ressourcen­ausschöpfung zur Auslösung von Skalierungsaktionen.

  • Anfrage‑Rate / Latenz

    Durchsatz und Reaktionszeit als Indikatoren für notwendige Skalierung.

Kubernetes Horizontal Pod Autoscaler

Weit verbreitete Implementierung von Pod-basiertem Autoscaling anhand von CPU- und benutzerdefinierten Metriken.

AWS Auto Scaling Groups

Cloud‑Anbieter‑Mechanismus für automatische Skalierung von EC2-Instanzen nach Policies und Zielmetriken.

Serverless Concurrency/Provisioned Scaling

Beispiele aus Functions-as-a-Service (z. B. Provisioned Concurrency) zur Steuerung von Startzeit und Durchsatz.

1

Metriken und Observability einrichten; relevante Metriken validieren.

2

Skalierungsregeln mit Min/Max- und Cooldown-Parametern definieren.

3

Automatisches Scaling in Stufen testen (Staging → Canary → Prod) und überwachen.

⚠️ Technische Schulden & Engpässe

  • Manuelles Tuning von Thresholds ohne Automatisierung oder Tests.
  • Fehlende Kapazitätsmodelle für Template‑Berechtigungen und Quotas.
  • Unvollständige Telemetrie, die Ursachen für Skalierungsentscheidungen verschleiert.
Stateful ServicesDatenbank‑VerbindungenStartzeit (Cold start) von Instanzen
  • Autoscaling für stateful Datenbanken ohne geeignete Replikationsstrategie.
  • Aggressive Skalierungsregeln, die Kosten unkontrolliert erhöhen.
  • Skalierung nur hoch, ohne automatisches Runterskalieren bei sinkender Last.
  • Ignorieren von Abhängigkeiten, die Flaschenhälse bleiben (DB, Netzwerk).
  • Fehlende Tests für kombinierte Lastszenarien führen zu Überraschungen in Prod.
  • Blindes Vertrauen in Cloud‑Defaults ohne Anpassung an eigene Workloads.
Kenntnisse in Cloud‑Plattformen und OrchestratorenErfahrung mit Monitoring, Metriken und AlertingVerständnis von Skalierungsstrategien und -Risiken
Skalierbarkeit bei LastspitzenKostenoptimierung durch elastische BereitstellungWiederherstellbarkeit und Ausfallsicherheit
  • • Abhängigkeiten, die nicht horizontal skaliert werden können (z. B. monolithische DB).
  • • Provider‑Limits oder Quoten in der Cloud.
  • • Netzwerk- oder Storage‑Durchsatzbegrenzungen.