Autoscaling

Wie Systeme Kapazität an echte Nachfrage anpassen, ohne Kosten, Leistung und Sicherheitsgrenzen aus dem Blick zu verlieren

Die automatische Anpassung von Compute-Ressourcen basierend auf Last – mehr Server bei hoher Nachfrage, weniger bei niedriger. Kosteneffizient und performant.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. Skaliert automatisch basierend auf Metriken (CPU, Requests, Queue)
  2. Horizontal (mehr Instanzen) oder Vertikal (größere Instanzen)
  3. Spart Kosten bei niedriger Last, garantiert Performance bei hoher

Sofortantwort

Autoscaling einfach erklärt

Automatische Anpassung von Ressourcen basierend auf Auslastung.

Kurz gesagt
Skaliert automatisch basierend auf Metriken (CPU, Requests, Queue)
Typischer Einsatz
Web-Traffic, ML-Inference, Batch-Processing
Wichtig zu wissen
Spart Kosten bei niedriger Last, garantiert Performance bei hoher

Autoscaling im Überblick

Autoscaling passt die Anzahl deiner Server automatisch an die aktuelle Last an. Mehr Nutzer = mehr Server. Weniger Nutzer = weniger Server (und Kosten).

Ohne Autoscaling:

Feste Kapazität: immer gleich viele Server

Niedrige Last:  viele Ressourcen idle, unnötige Kosten
Peak:           zu wenig Kapazität, langsam oder fehleranfällig

Mit Autoscaling:

Niedrige Last:  wenige Instanzen → kosteneffizient
Normale Last:   passende Kapazität → stabil
Peak:           zusätzliche Instanzen → bessere Performance

Technisch betrachtet

Kubernetes HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

KEDA für Event-driven Scaling

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    name: worker-deployment
  minReplicaCount: 0  # Scale to Zero!
  maxReplicaCount: 50
  triggers:
    - type: rabbitmq
      metadata:
        queueName: tasks
        queueLength: "10"  # 1 Worker pro 10 Messages

AWS Auto Scaling

# Terraform
resource "aws_autoscaling_group" "api" {
  name                = "api-asg"
  min_size            = 2
  max_size            = 20
  desired_capacity    = 5
  
  launch_template {
    id      = aws_launch_template.api.id
    version = "$Latest"
  }
}

resource "aws_autoscaling_policy" "scale_up" {
  name                   = "scale-up"
  autoscaling_group_name = aws_autoscaling_group.api.name
  policy_type            = "TargetTrackingScaling"
  
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

Scaling-Strategien

StrategieTriggerUse Case
CPU-basiertCPU-Auslastung über ZielwertCompute-intensive Workloads
Memory-basiertMemory-Auslastung über ZielwertMemory-intensive Apps
Request-basiertRequests/SekundeWeb-APIs
Queue-basiertQueue-LängeAsync Workers
Schedule-basiertUhrzeitVorhersehbare Patterns
Custom MetricsBusiness-MetrikenSpezifische Anforderungen

Cooldown und Stabilisierung

# Kubernetes HPA Behavior
behavior:
  scaleDown:
    stabilizationWindowSeconds: 300  # 5 Min warten
    policies:
      - type: Percent
        value: 10
        periodSeconds: 60  # Max 10% pro Minute runter
  scaleUp:
    stabilizationWindowSeconds: 0  # Sofort hoch
    policies:
      - type: Percent
        value: 100
        periodSeconds: 15  # Schnell hochskalieren

Kosten-Optimierung

Strategie: geeigneter Instanz-Mix für Autoscaling

- Basis-Last: stabile Kapazität für planbare Nachfrage
- Peaks: flexible oder unterbrechbare Kapazität, wenn Workload das erlaubt
- Steuerung: Limits, Budgets und Alerts gegen unerwartete Skalierungskosten

Schritt für Schritt

Wie Autoscaling verlässlich arbeitet

  1. Last und Serviceziel verstehen

    Beschreibe typische und außergewöhnliche Nachfrage, Engpässe und das erwartete Nutzererlebnis. Eine Skalierungsregel benötigt ein klares Serviceziel, nicht nur eine technische Metrik ohne Zusammenhang.

  2. Geeignete Signale und Grenzen wählen

    Wähle Kennzahlen, die Kapazitätsbedarf wirklich abbilden, und definiere Mindest-, Höchst- und Sicherheitsgrenzen. Berücksichtige, dass Datenbanken, externe Dienste oder Warteschlangen andere Engpässe haben können.

  3. Hoch- und Herunterskalieren testen

    Prüfe Anlaufzeit, Verteilung neuer Last und Verhalten bei plötzlichen Spitzen. Besonders wichtig ist, dass das System beim Verringern von Kapazität keine laufenden Aufgaben oder Daten verliert.

  4. Kosten und Wirkung fortlaufend prüfen

    Beobachte Leistung, Fehler, Warteschlangen und Kosten gemeinsam. Passe Regeln an echte Nutzungsmuster an, statt immer mehr Kapazität als Antwort auf ein unbekanntes Problem bereitzustellen.

Konkretes Beispiel

Eine Nachfrage-Spitze wird ohne Überreaktion behandelt

Ein Dienst erlebt nach einer Kampagne deutlich mehr Anfragen. Das Team möchte die Antwortzeiten schützen, aber nicht dauerhaft unnötige Infrastruktur vorhalten.

Skalierungshypothese

Eine hohe CPU-Auslastung löst bisher sofort neue Instanzen aus. Die Regel berücksichtigt jedoch nicht, dass einige Anfragen an einem externen Dienst warten und mehr Instanzen das Problem nicht lösen würden.

Abgestimmte Regel

Das Team kombiniert Warteschlangenlänge, Latenz und gesunde Kapazität mit klaren Grenzen. Es testet die Reaktion unter Last und überprüft nach der Kampagne Wirkung, Kosten und unerwartete Engpässe.

Einordnung

Vorteile und Grenzen

Das spricht dafür

  • Passt verfügbare Kapazität an wechselnde Nachfrage und schützt damit das Nutzererlebnis.
  • Kann Kosten reduzieren, wenn ungenutzte Kapazität kontrolliert wieder abgebaut wird.
  • Macht Annahmen über Last, Engpässe und Serviceziele messbar und überprüfbar.

Das solltest du beachten

  • Falsche Metriken können hektische Skalierung auslösen, ohne die echte Ursache zu lösen.
  • Startzeiten und Abhängigkeiten begrenzen, wie schnell zusätzliche Kapazität tatsächlich hilft.
  • Höhere Kapazität schützt nicht automatisch vor fehlerhaftem Code, Datenbankengpässen oder Angriffen.
Vertiefung · für Fortgeschrittene

Nachfrage in gesunde Kapazität übersetzen

Wissenskarte

Kapazität nach Bedarf

Monitoring
Kontinuierliche Überwachung von KI-Systemen zur Fehlererkennung.
Kubernetes
Plattform zur Automatisierung von Container-Anwendungen.
Observability
Fähigkeit, den Zustand eines Systems durch Logs, Metrics und Traces zu verstehen.
Caching
Zwischenspeichern von Daten zur Beschleunigung von Anfragen.
Load Balancing
Eingehende Anfragen werden auf mehrere Server verteilt, um Überlastung zu vermeiden.
Autoscaling verbindet Nutzungsnachfrage mit geeigneten Signalen, gesunden Grenzen und der Beobachtung, ob zusätzliche Kapazität das eigentliche Serviceziel verbessert. Autoscaling gliedert sich in: Monitoring, Kubernetes, Observability, Caching, Load Balancing.

01Einsatzbereiche

Wann ist Autoscaling sinnvoll?

Geeignet für

  • Web-TrafficMehr Server bei Traffic-Spitzen (Black Friday, Kampagnen)
  • ML-InferenceGPU-Instanzen nach Bedarf hoch- und runterfahren
  • Batch-ProcessingWorker für Queue-Verarbeitung skalieren
  • KostenoptimierungNachts und am Wochenende runterskalieren

↑ Inhalt

02Werkzeuge

Womit Autoscaling umgesetzt wird

↑ Inhalt

Merksatz

Autoscaling ist wie ein Supermarkt, der automatisch mehr Kassen öffnet wenn die Schlangen lang werden, und sie wieder schließt wenn es ruhiger wird – immer genau so viele wie nötig.

  1. Skaliert automatisch basierend auf Metriken (CPU, Requests, Queue)
  2. Horizontal (mehr Instanzen) oder Vertikal (größere Instanzen)
  3. Spart Kosten bei niedriger Last, garantiert Performance bei hoher

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu Autoscaling

Horizontal vs. Vertikal – was ist besser?

Horizontal skalieren ist oft flexibler und ausfallsicherer, vertikal skalieren kann bei einfachen Setups leichter sein. Die bessere Wahl hängt von Architektur, State Management, Datenbank, Kosten und Betriebsmodell ab.

Wie schnell skaliert Autoscaling?

Abhängig von Plattform, Metriken, Cooldowns, Image-Startzeit und Ressourcenverfügbarkeit. Für plötzliche Spikes helfen Mindestkapazität, Predictive Scaling oder vorgewärmte Instanzen.

Was ist Scale-to-Zero?

Bei keiner Last auf 0 Instanzen runterskalieren. Spart Kosten, aber Cold Start bei erstem Request. Serverless macht das automatisch.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

  • Grundlage nachholen

    Load Balancing

    Eingehende Anfragen werden auf mehrere Server verteilt, um Überlastung zu vermeiden.

↑ Inhalt