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
| Strategie | Trigger | Use Case |
|---|---|---|
| CPU-basiert | CPU-Auslastung über Zielwert | Compute-intensive Workloads |
| Memory-basiert | Memory-Auslastung über Zielwert | Memory-intensive Apps |
| Request-basiert | Requests/Sekunde | Web-APIs |
| Queue-basiert | Queue-Länge | Async Workers |
| Schedule-basiert | Uhrzeit | Vorhersehbare Patterns |
| Custom Metrics | Business-Metriken | Spezifische 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 SkalierungskostenSchritt für Schritt
Wie Autoscaling verlässlich arbeitet
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.
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.
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.
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 FortgeschritteneNachfrage in gesunde Kapazität übersetzen
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.