\n\n\n\n Infrastruktur des Auto-Scaling-Agenten: Tipps, Ratschläge und praktische Beispiele - AgntUp \n

Infrastruktur des Auto-Scaling-Agenten: Tipps, Ratschläge und praktische Beispiele

📖 12 min read2,265 wordsUpdated Mar 29, 2026

Einleitung : Die Notwendigkeit von Auto-Scaling für die Infrastruktur der Agenten

In der dynamischen Welt der Softwareentwicklung und -operationen ist die Fähigkeit, sich schnell an schwankende Arbeitslasten anzupassen, von größter Bedeutung. Dies gilt insbesondere für agentenbasierte Systeme, bei denen die Anzahl der benötigten Agenten je nach Nachfrage erheblich variieren kann. Egal, ob Sie CI/CD-Pipelines verwalten, eine Infrastruktur überwachen oder Echtzeitdaten verarbeiten, eine unterdimensionierte Flotte von Agenten führt zu Engpässen und Verzögerungen, während eine überdimensionierte Flotte wertvolle Ressourcen verschwendet. Hier kommt das Auto-Scaling ins Spiel, das eine leistungsstarke Lösung bietet, um sowohl die Leistung als auch die Kosten zu optimieren. Allerdings beschränkt sich die Auto-Scaling-Infrastruktur für Agenten nicht nur darauf, einen Knopf zu drücken; sie erfordert sorgfältige Planung, strategische Umsetzung und kontinuierliche Verfeinerung. In diesem praktischen Leitfaden werden wir Tipps, Ratschläge und praktische Beispiele erkunden, um Ihnen zu helfen, eine solide und effiziente Auto-Scaling-Infrastruktur für Agenten aufzubauen.

Die Grundprinzipien des Auto-Scaling Verstehen

Bevor wir in die Details eintauchen, lassen Sie uns kurz die Grundprinzipien zusammenfassen, die einem effektiven Auto-Scaling zugrunde liegen:

  • Metriken : Auto-Scaling basiert auf beobachtbaren Datenpunkten (Metriken), um Skalierungsentscheidungen zu treffen. Dazu können die CPU-Auslastung, der Speicherverbrauch, die Länge der Warteschlange, aktive Verbindungen oder anwendungsspezifische Metriken gehören.
  • Schwellenwerte : Für jede Metrik definieren Sie Schwellenwerte, die Skalierungsaktionen auslösen. Wenn beispielsweise die CPU-Auslastung 70 % für 5 Minuten überschreitet, erhöhen Sie die Kapazität. Fällt sie unter 30 % für 10 Minuten, reduzieren Sie die Kapazität.
  • Skalierungsrichtlinien : Diese definieren wie die Skalierungsaktion durchgeführt wird. Fügen Sie eine Instanz auf einmal hinzu? Ein Prozentsatz der aktuellen Flotte? Wie schnell werden die Instanzen beendet?
  • Abkühlzeiten : Um „Flapping“ (schnelles Hoch- und Herunterskalieren) zu vermeiden, führen Abkühlzeiten eine Verzögerung nach einer Skalierungsaktion ein, bevor eine weitere ausgelöst werden kann.
  • Zielverfolgung : Eine fortgeschrittenere Richtlinie, bei der Sie einen Zielwert für eine Metrik angeben (z. B. die durchschnittliche CPU-Auslastung bei 50 % zu halten), und das System die Kapazität automatisch anpasst, um dies zu erreichen.

Die Richtige Auto-Scaling-Plattform Wählen

Der erste praktische Schritt besteht darin, die richtige Plattform auszuwählen. Ihre Wahl hängt weitgehend von Ihrer bestehenden Infrastruktur und Ihrem Cloud-Anbieter ab:

  • Cloud-natives Auto-Scaling :
    • AWS Auto Scaling : Für EC2-Instanzen, ECS-Dienste, EKS-Pods und mehr. Stark integriert mit CloudWatch für Metriken.
    • Azure Virtual Machine Scale Sets (VMSS) : Für Azure-VMs, mit Integration in Azure Monitor.
    • Google Cloud Managed Instance Groups (MIGs) : Für Google Compute Engine-Instanzen, die Stackdriver (jetzt Cloud Monitoring) verwenden.
  • Container-Orchestratoren :
    • Kubernetes Horizontal Pod Autoscaler (HPA) : Um Pods basierend auf CPU, Speicher oder benutzerdefinierten Metriken zu skalieren.
    • Kubernetes Cluster Autoscaler : Um die zugrunde liegenden Knoten des Clusters zu skalieren, wenn Pods nicht geplant werden können.
    • Kubernetes KEDA (Kubernetes Event-driven Autoscaling) : Erweitert HPA, um eine Vielzahl von Ereignisquellen (Warteschlangen, Datenbanken, Nachrichtenbroker usw.) für eine anspruchsvollere Skalierbarkeit zu unterstützen.
  • Selbstverwaltete Lösungen : Obwohl weniger verbreitet für neue Bereitstellungen, könnten Sie Tools wie HashiCorp Nomad verwenden oder benutzerdefinierte Skripte mit Überwachungsagenten für On-Premise-Installationen oder Bare-Metal-Hardware erstellen.

Tipp : Nutzen Sie die nativen Auto-Scaling-Funktionen Ihres Cloud-Anbieters, wann immer möglich. Diese sind in der Regel stabiler, integriert und einfacher zu verwalten als benutzerdefinierte Lösungen.

Tipps und Ratschläge für Effektives Auto-Scaling

1. Granulare Metriken und Benutzerdefinierte Metriken Sind Ihre Besten Freunde

Obwohl die CPU- und Speicherauslastung gute Ausgangspunkte sind, erzählen sie oft nicht die ganze Geschichte für die Infrastruktur der Agenten. Berücksichtigen Sie:

  • Länge der Warteschlange : Wenn Ihre Agenten Aufgaben aus einer Nachrichtenwarteschlange abrufen (z. B. SQS, RabbitMQ, Kafka), ist die Länge der Warteschlange ein starkes Indiz für unerledigte Arbeiten.
  • Agentennutzung (Anwendungsspezifisch) : Wie viele Aufgaben bearbeitet ein Agent aktiv? Wie hoch ist seine interne Last?
  • Wartende Builds/Jobs : Für CI/CD-Agenten ist die Anzahl der wartenden Jobs in der Warteschlange ein direktes Signal, die Kapazität zu erhöhen.
  • Netzwerk-Ein-/Ausgaben : Wenn die Agenten stark auf die Netzwerkbandbreite angewiesen sind.

Praktisches Beispiel (AWS Länge der SQS-Warteschlange) :
Konfigurieren Sie eine AWS Auto Scaling-Gruppe, um die Kapazität zu erhöhen, wenn die Metrik ApproximateNumberOfMessagesVisible für Ihre SQS-Warteschlange einen bestimmten Schwellenwert (z. B. 100 Nachrichten) für 5 Minuten überschreitet. Reduzieren Sie, wenn sie unter einen unteren Schwellenwert (z. B. 10 Nachrichten) für 15 Minuten fällt.


{
 "AlarmName": "ScaleOutOnSQSQueueLength",
 "ComparisonOperator": "GreaterThanThreshold",
 "EvaluationPeriods": 1,
 "MetricName": "ApproximateNumberOfMessagesVisible",
 "Namespace": "AWS/SQS",
 "Period": 300, // 5 Minuten
 "Statistic": "Average",
 "Threshold": 100,
 "Dimensions": [
 {
 "Name": "QueueName",
 "Value": "your-agent-task-queue"
 }
 ],
 "AlarmActions": [
 "arn:aws:autoscaling:REGION:ACCOUNT_ID:scalingPolicy:POLICY_ID"
 ]
}

2. Die Startzeit der Instanzen Optimieren (Goldene AMIs/Bilder)

Die Zeit, die eine neue Agenteninstanz benötigt, um vollständig betriebsbereit zu sein, hat direkten Einfluss auf die Reaktionsfähigkeit Ihres Auto-Scaling. Minimieren Sie diese Zeit, indem Sie:

  • Goldene AMIs/Bilder : Erstellen Sie vorkonfigurierte Bilder (AMIs für AWS, benutzerdefinierte Bilder für Azure/GCP), die alle erforderlichen Software, Abhängigkeiten und Konfigurationen enthalten. Dies beseitigt die Notwendigkeit eines umfangreichen Bootstrappings beim Start.
  • Benutzerdaten/Cloud-init : Verwenden Sie diese Skripte sparsam und nur für dynamische Konfigurationen (z. B. Registrierung bei einem zentralen Orchestrator, Abrufen von Geheimnissen). Halten Sie sie leichtgewichtig.
  • Containerisierung : Für containerisierte Agenten verwenden Sie kleine optimierte Bilder und stellen Sie sicher, dass Ihre Container-Laufzeit vorinstalliert ist.

Tipp : Aktualisieren Sie regelmäßig Ihre goldenen Bilder, um die neuesten Sicherheitsupdates und Versionen der Agenten einzuschließen.

3. Robuste Gesundheitsprüfungen und Sanfte Abschaltungen Implementieren

Auto-Scaling besteht nicht nur darin, Instanzen zu starten; es geht auch darum, sie ordnungsgemäß zu stoppen.

  • Gesundheitsprüfungen : Konfigurieren Sie Ihre Auto-Scaling-Gruppe (oder die Readiness/Liveness-Probes von Kubernetes), um genau zu bestimmen, ob ein Agent gesund und bereit ist, Aufgaben zu empfangen. Wenn ein Agent bei den Gesundheitsprüfungen durchfällt, sollte er ersetzt werden.
  • Sanfte Abschaltungen : Wenn eine Instanz durch das Auto-Scaling beendet wird, sollte sie über einen Mechanismus verfügen, um alle laufenden Arbeiten abzuschließen und sich dann abzumelden. Für CI/CD-Agenten kann dies bedeuten, den aktuellen Build als ‘beendet’ oder ‘abgebrochen’ zu kennzeichnen, bevor sie sich abschaltet.
  • Lifecycle-Hooks (AWS/GCP/Azure) : Verwenden Sie Lifecycle-Hooks, um Aktionen vor der Beendigung einer Instanz durchzuführen (z. B. Verbindungen abfließen lassen, eine Benachrichtigung senden).

Praktisches Beispiel (Kubernetes) :
Definieren Sie preStop-Hooks und angemessene Grace-Perioden für die Beendigung Ihrer Agenten-Pods, um sicherzustellen, dass laufende Aufgaben abgeschlossen werden, bevor der Pod gestoppt wird.


apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-agent
spec:
 template:
 spec:
 containers:
 - name: agent-container
 image: my-agent-image:latest
 lifecycle:
 preStop:
 exec:
 command: ["/bin/sh", "-c", "/usr/local/bin/agent-drain-script.sh"]
 readinessProbe:
 httpGet:
 path: /healthz
 port: 8080
 initialDelaySeconds: 10
 periodSeconds: 5
 terminationGracePeriodSeconds: 60 # Geben Sie den Agenten 60 Sekunden, um die Aufgaben abzuschließen

4. Berücksichtigen Sie die vorausschauende Skalierung und die geplante Skalierung

Reaktive Auto-Skalierung (Skalierung basierend auf aktuellen Metriken) ist gut, aber proaktive Skalierung ist noch besser.

  • Geplante Skalierung: Wenn Sie vorhersehbare Spitzenzeiten haben (z. B. der morgendliche Arbeitsansturm, tägliche Batch-Aufgaben), planen Sie Skalierungsmaßnahmen, um die Kapazität vor dem Höhepunkt zu erhöhen und danach zu verringern.
  • Vorausschauende Skalierung (AWS Auto Scaling Predictive Scaling): Einige Cloud-Anbieter bieten vorausschauende Skalierung an, die maschinelles Lernen nutzt, um die zukünftige Last basierend auf historischen Daten vorherzusagen und proaktiv Instanzen zu skalieren.

Tipp: Kombinieren Sie geplante Skalierung für bekannte Muster mit reaktiver Skalierung für unerwartete Spitzen. So erhalten Sie das Beste aus beiden Welten.

5. Implementieren Sie einen Schutz gegen Kapazitätsreduzierung und Instanzgewichte

  • Schutz gegen Kapazitätsreduzierung: Für kritische Agenten oder Instanzen, die lange und nicht unterbrechbare Aufgaben ausführen, möchten Sie möglicherweise vorübergehend den Schutz gegen Kapazitätsreduzierung deaktivieren, um zu verhindern, dass sie vorzeitig gestoppt werden.
  • Instanzgewichte (Kubernetes KEDA): Bei der Skalierung basierend auf der Warteschlangenlänge möchten Sie möglicherweise verschiedenen Agententypen unterschiedliche ‘Gewichte’ zuweisen, wenn einige Agenten mehr Aufgaben bearbeiten können als andere.

6. Kostenoptimierung über die grundlegende Auto-Skalierung hinaus

Auto-Skalierung spart intrinsisch Kosten, indem sie die Kapazität an die Nachfrage anpasst, aber Sie können noch weiter gehen:

  • On-Demand-Instanzen/vorübergehende VMs: Für ausfallsichere Agenten-Workloads verwenden Sie kostengünstigere On-Demand-Instanzen (AWS) oder vorübergehende VMs (GCP). Entwerfen Sie Ihre Agenten so, dass sie Unterbrechungen reibungslos bewältigen.
  • Dimensionierung anpassen: Überwachen Sie kontinuierlich die Ressourcennutzung Ihrer Agenten, um sicherzustellen, dass Sie die kleinsten Instanztypen verwenden, die den Leistungsanforderungen entsprechen.
  • Reservierte Instanzen/Einsparpläne: Für Ihre ständig aktive Basisagentenkapazität ziehen Sie in Betracht, Instanzen zu reservieren, um von erheblichen Rabatten zu profitieren.

Praktisches Beispiel (AWS Spot Instances):
Konfigurieren Sie Ihre Auto-Skalierungsgruppe so, dass sie eine Mischung aus On-Demand-Instanzen und Spot-Instanzen mit einer spezifischen Verteilung verwendet, um hohe Verfügbarkeit zu gewährleisten und gleichzeitig die Kosten zu optimieren.

7. Überwachen und iterieren

Auto-Skalierung ist keine Lösung, die man einmal einrichtet und dann vergisst. Kontinuierliche Überwachung ist entscheidend:

  • Überwachen Sie Skalierungsereignisse: Verfolgen Sie, wann und warum Skalierungsmaßnahmen stattfinden. Kommen sie zu häufig vor? Nicht häufig genug?
  • Ressourcennutzung: Behalten Sie CPU, Speicher, Netzwerk und Festplatten-I/O Ihrer Agenten im Auge. Werden sie systematisch über- oder unterausgelastet?
  • Anwendungsleistung: Überwachen Sie die tatsächliche Leistung Ihrer von Agenten gesteuerten Aufgaben (z. B. Kompilierungszeiten, Verarbeitungsverzögerungen).
  • Kostenberichte: Überprüfen Sie regelmäßig Ihre Cloud-Abrechnung, um die Kosteneffizienz sicherzustellen.

Tipp: Verwenden Sie Dashboards (z. B. Grafana, CloudWatch Dashboards), um Skalierungstrends zusammen mit den Leistungsmetriken der Agenten zu visualisieren.

8. Achten Sie auf laute Herden und Kaltstarts

  • Laute Herden: Wenn ein plötzlicher Anstieg der Nachfrage das gleichzeitige Starten vieler Agenten auslöst, die alle versuchen, auf eine gemeinsame Ressource (z. B. eine Datenbank, einen zentralen Dateiserver) zuzugreifen, kann dies diese Ressource überlasten. Entwerfen Sie Ihre Agenten mit Rückstufungen und Wiederholungsversuchen.
  • Kaltstarts: Die Verzögerung zwischen einem Skalierungsereignis und einer Instanz, die vollständig betriebsbereit wird. Optimieren Sie die Startzeit, wie besprochen, und ziehen Sie bei Bedarf Vorwärmstrategien in Betracht.

Praktisches Beispiel: Auto-Skalierung von CI/CD-Agenten auf Kubernetes mit KEDA

Betrachten wir ein häufiges Szenario: Sie haben ein CI/CD-System (wie Jenkins, GitLab CI oder eine benutzerdefinierte Lösung), das Kubernetes-Pods als Build-Agenten verwendet. Diese Agenten ziehen die Build-Aufgaben aus einer Nachrichtenwarteschlange.

Problem:

Während der Spitzenzeiten verlängern sich die Build-Warteschlangen, was zu langsamen Feedback-Zyklen führt. Außerhalb der Spitzenzeiten bleiben viele Agenten-Pods inaktiv und verschwenden Ressourcen.

Lösung unter Verwendung von KEDA:

KEDA ermöglicht es Ihnen, Kubernetes-Deployments basierend auf verschiedenen externen Metriken zu skalieren. Hier verwenden wir eine SQS-Warteschlange als Auslöser.

Voraussetzungen:

  • Ein laufender Kubernetes-Cluster.
  • KEDA ist in Ihrem Cluster installiert.
  • Eine AWS SQS-Warteschlange, in die die Build-Aufgaben gesendet werden.
  • Ein Kubernetes-Deployment für Ihre CI/CD-Agenten-Pods.
  • Eine IAM-Rolle mit Lesezugriff auf SQS, die mit dem KEDA-Servicekonto oder direkt mit Ihren Agenten-Pods (wenn Sie KIAM/IRSA verwenden) verknüpft ist.

Konfiguration des KEDA ScaledObject:


apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
 name: ci-cd-agent-scaler
 namespace: default
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: ci-cd-agent-deployment # Name Ihres Agenten-Deployments
 pollingInterval: 10 # Überprüfen Sie SQS alle 10 Sekunden
 minReplicaCount: 0 # Reduzieren Sie auf 0 Agenten, wenn keine Arbeit vorhanden ist
 maxReplicaCount: 20 # Maximale Anzahl von Agenten-Pods
 triggers:
 - type: aws-sqs
 metadata:
 queueURL: "https://sqs.us-east-1.amazonaws.com/123456789012/my-ci-cd-queue"
 queueLength: "5" # Ziel: 5 Nachrichten pro Agenten-Pod
 awsRegion: "us-east-1"
 identityOwner: "pod"
 # Optional: Fügen Sie eine Authentifizierung hinzu, wenn nicht standardmäßig IRSA/KIAM verwendet wird
 # awsAccessKeyID: "IHRE_ZUGRIFFSSCHLÜSSEL_ID"
 # awsSecretAccessKey: "IHRE_GEHEIME_ZUGRIFFSSCHLÜSSEL"

Erklärung:

  • scaleTargetRef: Gibt Ihr Kubernetes-Deployment mit dem Namen ci-cd-agent-deployment an.
  • pollingInterval: KEDA wird die SQS-Warteschlange alle 10 Sekunden überprüfen.
  • minReplicaCount: 0: Dies ist eine leistungsstarke Funktion zur Kostensenkung. Wenn keine Nachrichten in der Warteschlange sind, wird KEDA das Agenten-Deployment auf null Pods reduzieren.
  • maxReplicaCount: 20: Begrenzung der maximalen Anzahl von Agenten-Pods, um eine übermäßige Skalierung zu vermeiden.
  • triggers: Definiert den Skalierungsauslöser. Hier handelt es sich um einen Typ aws-sqs.
    • queueURL: Die URL Ihrer SQS-Warteschlange.
    • queueLength: "5": Dies ist der kritische Skalierungsparameter. KEDA wird versuchen, im Durchschnitt 5 Nachrichten pro Agenten-Pod zu halten. Wenn es 50 Nachrichten gibt, wird KEDA bis zu 10 Agenten skalieren (50/5 = 10). Wenn es 2 Nachrichten gibt und minReplicaCount 0 ist, wird es auf 0 reduzieren (oder 1, wenn minReplicaCount 1 war und bereits 1 Agent vorhanden ist).
    • awsRegion: Die AWS-Region der SQS-Warteschlange.
    • identityOwner: "pod": Gibt an, dass die IAM-Rolle des Pods (über IRSA) zur Authentifizierung bei SQS verwendet werden soll.

Zusätzliche Verbesserungen für dieses Beispiel:

  • Kubernetes-Cluster-Autoscaler: Stellen Sie sicher, dass Ihr Kubernetes-Cluster selbst seine Knoten skalieren kann. Wenn KEDA die Agent-Pods skaliert, aber keine Knoten verfügbar sind, bleiben die Pods im Wartestatus. Der Cluster-Autoscaler fügt bei Bedarf neue Knoten hinzu.
  • Ressourcenanforderungen/-grenzen: Definieren Sie angemessene Anforderungen und Grenzen für Ihre Agent-Pods, um einen fairen Scheduler zu gewährleisten und Ressourcenengpässe zu vermeiden.
  • Automatische Knotenbereitstellung (GKE/EKS): Moderne Kubernetes-Angebote verfügen oft über automatische Knotenbereitstellungsfunktionen, die automatisch optimale Knotentypen auswählen und bereitstellen können.
  • Horizontaler Pod-Autoscaler (HPA) für CPU/Speicher: Während KEDA das Scaling basierend auf Ereignissen verwaltet, können Sie HPA weiterhin verwenden, um basierend auf CPU/Speicher zu skalieren, wenn die Agent-Pods selbst bei ausreichender Aufgabenanzahl überlastet werden. KEDA funktioniert in Verbindung mit HPA.

Fazit

Die Infrastruktur für selbstskalierende Agenten ist kein Luxus mehr, sondern eine Notwendigkeit für moderne und agile Operationen. Indem Sie die zugrunde liegenden Prinzipien verstehen, Ihre Plattform sorgfältig auswählen und die hier vorgestellten Tipps und Tricks umsetzen, können Sie eine hochgradig resiliente, kosteneffiziente und leistungsstarke Flotte von Agenten aufbauen. Vergessen Sie nicht, dass der Weg zu optimalem Auto-Scaling iterativ ist. Überwachen Sie kontinuierlich Ihre Metriken, analysieren Sie Ihre Skalierungsereignisse und verfeinern Sie Ihre Richtlinien, um sicherzustellen, dass sich Ihre Infrastruktur bei jeder Wendung Ihrer Arbeitslast reibungslos anpasst.

🕒 Published:

✍️
Written by Jake Chen

AI technology writer and researcher.

Learn more →
Browse Topics: Best Practices | CI/CD | Cloud | Deployment | Migration
Scroll to Top