Ich habe die Einsätze von Cloud Agent erweitert: Hier ist meine Geschichte

Hallo zusammen, Mitstreiter im Agentenmanagement! Maya Singh hier, zurück auf agntup.com, und ich habe heute eine Geschichte für euch. Wir werden ein Thema erkunden, das mich nachts wach hält, mich tagsüber begeistert und die Quelle meiner größten Triumphe sowie meiner frustrierendsten Momente war: die Erweiterung der Bereitstellung von Cloud-Agenten.

Genauer gesagt werden wir über etwas sprechen, das ich bei unzähligen Teams, einschließlich meinem eigenen (damals, natürlich), habe scheitern sehen: die oft vernachlässigte Kunst des sanften Autoscalings für zustandsbehaftete Agenten.

Die Zweiseitigkeit des Autoscalings: Warum zustandsbehaftete Agenten anders sind

Seien wir ehrlich, Autoscaling ist ein Segen. Wer möchte um 3 Uhr morgens manuell VMs bereitstellen, weil ein plötzlicher Verkehrsgipfel eure Armee von Bots überwältigt hat? Ich nicht. Ihr auch nicht. Die Cloud-Anbieter haben uns einen Traum verkauft: unbegrenzte Kapazität, nutzungsabhängige Abrechnung, Hochskalierung, Niedrigskalierung. Und für zustandslose Webdienste funktioniert das ziemlich gut. Eure Anfrage erreicht jeden verfügbaren Server, der Server bearbeitet sie, sendet sie zurück und vergisst sie. Einfach.

Aber dann kamen die Agenten. Meine Leidenschaft. Unser Brot und Butter. Viele der Agenten, die wir bauen und bereitstellen – besonders die, die schwere Arbeit verrichten, langwierige Aufgaben erledigen oder dauerhafte Verbindungen aufrechterhalten – sind nicht zustandslos. Sie sind oft *sehr* zustandsbehaftet. Sie könnten sein:

• Offene WebSocket-Verbindungen zu externen Diensten aufrechterhalten.
• Aufgaben in einem In-Memory-Warteschlangenmodell speichern, die sie gerade bearbeiten.
• Zwischenergebnisse komplexer Berechnungen speichern.
• Sitzungen mit externen APIs authentifizieren, die bandbreitenabhängige Limits für bestimmte IPs oder Client-Instanzen haben.

Und hier wird der „sanfte“ Teil des Autoscalings entscheidend. Denn während das Hochskalieren in der Regel einfach ist (einfach mehr Instanzen starten!), ist das Herunterskalieren von zustandsbehafteten Agenten, ohne Datenverluste, unterbrochene Verbindungen oder verärgerte Benutzer zu verursachen, eine ganz andere Herausforderung. Es ist wie der Versuch, einen Ziegelstein aus einem Jenga-Turm zu entfernen, während das Spiel noch läuft. Man muss überlegt, sanft und mit einem Plan vorgehen.

Mein eigener Albtraum des Autoscalings: Der Vorfall der „plötzlichen Trennung“

Ich erinnere mich an ein Projekt, wahrscheinlich vor fünf Jahren. Wir bauten eine Flotte von Datenaufnahme-Agenten, die sich mit verschiedenen öffentlichen APIs verbanden. Diese Agenten stellten langfristige Verbindungen her, holten Daten ab, verarbeiteten sie in Echtzeit und schoben sie dann in eine zentrale Datenbank. Wir führten sie auf AWS EC2-Instanzen aus, verwaltet von einer Auto-Scaling-Gruppe (ASG) und einer einfachen CloudWatch-Metrik für die CPU-Nutzung.

Alles funktionierte wunderbar während der Spitzenzeiten. Mehr CPU? Starte eine weitere Instanz. Super. Aber dann, als der Verkehr abends zurückging, begann die ASG, Instanzen zu beenden, um Kosten zu sparen. Und genau dann begannen die Warnmeldungen zu schreien. Unsere Überwachung zeigte plötzliche Rückgänge des Datenstroms, Verbindungsfehler und frustrierte Nachrichten von Benutzern über fehlende Datenpunkte.

Was passierte? Unsere Agenten waren, als eine Instanz beendet wurde, einfach… tot. Während der Verarbeitung. Sie hatten aktive Verbindungen, teilweise verarbeitete Datenmengen im Speicher und keinen Weg, ihre Arbeit sanft zu übertragen. Die ASG, Gott segne sie, sah nur eine nun nutzlose Instanz und schaltete sie ab. Es war ein Massaker an digitalen Arbeitern.

Wir brauchten Wochen, um dieses Chaos zu entwirren, geeignete Shutdown-Hooks einzuführen und eine Entlade-Strategie zu implementieren. Aber die Lektion war in meinem Kopf verankert: Das Autoscaling von zustandsbehafteten Agenten erfordert mehr als nur einfache CPU-Metriken und eine gewünschte Kapazität.

Die Kunst des sanften Entladens: Ein praktischer Leitfaden

Wie vermeiden wir also, dass unsere Agenten ein plötzliches und schändliches Ende finden? Wir führen das Konzept des „Entladens“ ein. Das Entladen ist der Prozess, bei dem man einem Agenten sanft sagt: „Hey, du wirst bald beendet. Bitte beende, was du tust, nimm keine neuen Arbeiten an und schalte dich dann sauber aus.“

So gehen wir es an, in der Regel unter Einbeziehung einer Kombination aus Anwendungslogik und Cloud-Infrastrukturkonfiguration.

1. Sanfte Shutdown-Hooks auf Anwendungsebene

Das ist die absolute Grundlage. Euer Agent *muss* in der Lage sein, auf ein Beendigungssignal (wie SIGTERM auf Linux) zu reagieren, indem er:

1. Neue Arbeiten stoppen: Sofort aufhören, neue Aufgaben, Verbindungen oder Nachrichten anzunehmen.
2. Aktuelle Arbeit beenden: Allen laufenden Operationen, offenen Verbindungen oder gepufferten Daten erlauben, sich zu beenden und entladen zu werden. Das kann eine Wartezeit erfordern.
3. Kritischen Zustand bewahren: Wenn es einen Zustand gibt, der *unbedingt* überleben muss, stellt sicher, dass er in einem dauerhaften Speicher (Datenbank, S3, persistente Warteschlange) vor dem Shutdown geschrieben wird.
4. Ressourcen freigeben: Schließt die Verbindungen zur Datenbank, die Dateideskriptoren, die Netzwerk-Sockets.
5. Sauber aussteigen: Sobald die gesamte Arbeit abgeschlossen und die Ressourcen freigegeben sind, mit einem Erfolgscode aussteigen.

Schauen wir uns ein vereinfachtes Beispiel in Python für einen Agenten an, der Aufgaben aus einer Warteschlange verarbeitet:

import signal
import sys
import time
from queue import Queue

class MyAgent:
 def __init__(self):
 self.task_queue = Queue()
 self.running = True
 self.processing_task = False
 signal.signal(signal.SIGTERM, self.handle_shutdown_signal)
 signal.signal(signal.SIGINT, self.handle_shutdown_signal) # Für lokale Tests

 def handle_shutdown_signal(self, signum, frame):
 print(f"[{time.time()}] Shutdown-Signal empfangen ({signum}). Initiierung des sanften Shutdowns...")
 self.running = False

 def enqueue_task(self, task):
 if self.running:
 self.task_queue.put(task)
 print(f"[{time.time()}] Aufgabe hinzugefügt: {task}")
 else:
 print(f"[{time.time()}] Der Agent wird heruntergefahren, hinzugefügte Aufgabe verworfen: {task}")

 def process_task(self, task):
 self.processing_task = True
 print(f"[{time.time()}] Verarbeitung der Aufgabe: {task}...")
 time.sleep(5) # Simuliert Arbeit
 print(f"[{time.time()}] Verarbeitung der Aufgabe abgeschlossen: {task}")
 self.processing_task = False

 def run(self):
 print(f"[{time.time()}] Agent gestartet.")
 while self.running or not self.task_queue.empty() or self.processing_task:
 if not self.task_queue.empty():
 task = self.task_queue.get()
 self.process_task(task)
 elif not self.running and self.task_queue.empty() and not self.processing_task:
 # Alle Aufgaben bearbeitet, keine neue Arbeit, und nichts zu verarbeiten
 break
 else:
 # Keine Aufgabe, der Agent läuft noch oder wartet darauf, dass die aktuelle Aufgabe abgeschlossen wird
 time.sleep(1) # Vermeidung aktiver Wartezeiten
 print(f"[{time.time()}] Agent sauber heruntergefahren.")

if __name__ == "__main__":
 agent = MyAgent()
 # Simuliere einige anfängliche Aufgaben
 agent.enqueue_task("Aufgabe A")
 agent.enqueue_task("Aufgabe B")
 time.sleep(2) # Etwas Zeit für die Verarbeitung lassen
 agent.enqueue_task("Aufgabe C")
 agent.run()

Dieses einfache Beispiel zeigt, wie das Flag `running` und die Überprüfung des Warteschlangen-/Verarbeitungsstatus es dem Agenten ermöglichen, seine bestehende Arbeit auch nach Erhalt eines Shutdown-Signals abzuschließen. Das ist entscheidend!

2. Entlade-Mechanismen des Cloud-Anbieters (Beispiel AWS)

Wie lassen wir den Cloud-Anbieter wissen, dass er *warten* soll, bis unser Agent seinen sanften Shutdown durchführt? Hier kommen die cloud-spezifischen Merkmale ins Spiel. Bei AWS verwenden wir:

• Lifecycle Hooks der EC2 Auto Scaling Gruppe: Diese sind Gold wert. Sie ermöglichen es euch, eine Instanz in einen Zustand „Beendigung: Warten“ zu versetzen, bevor sie tatsächlich aus der ASG entfernt wird. Während dieser Pause könnt ihr benutzerdefinierte Aktionen ausführen.
• Abmeldeverzögerung der Zielgruppe: Wenn eure Agenten hinter einem Application Load Balancer (ALB) oder einem Network Load Balancer (NLB) stehen, ist diese Einstellung entscheidend. Wenn eine Instanz zur Beendigung markiert wird, hört der Lastverteiler auf, neue Anfragen an sie zu senden, wird aber *warten*, bis die konfigurierten Verbindungen entladen sind, bevor sie aus der Zielgruppe entfernt wird.

Die Lifecycle Hooks nutzen:

Hier ist der allgemeine Ablauf für eine AWS-Konfiguration:

1. Eine EC2-Instanz wird vom ASG zur Beendigung markiert (zum Beispiel aufgrund eines Ereignisses zur Größenreduzierung).
2. Das ASG löst einen Lifecycle-Hook „Terminating: Wait“ aus.
3. Dieser Hook kann ein Ereignis senden (zum Beispiel an eine SQS-Warteschlange oder eine Lambda-Funktion).
4. Ein Prozess auf der Instanz selbst (oder ein separater Überwachungsdienst) erhält dieses Signal.
5. Bei Erhalt des Signals beginnt der Agent mit seinem sanften Shutdown auf Anwendungsebene (wie in unserem obigen Python-Beispiel). Er hört auf, neue Aufgaben anzunehmen, und beendet die laufenden Aufgaben.
6. Sobald der Agent fertig ist, signalisiert er dem ASG, dass er bereit ist, beendet zu werden. Dies geschieht in der Regel durch den Aufruf von complete_lifecycle_action über die AWS CLI oder SDK.
7. Wenn der Agent innerhalb eines konfigurierten Zeitrahmens nicht das Ende signalisiert, wird das ASG ihn schließlich zur Beendigung zwingen (besser als nichts, aber nicht ideal).

Um dies über die AWS CLI (vereinfacht) zu konfigurieren:

# 1. Erstellen Sie den Lifecycle Hook
aws autoscaling put-lifecycle-hook \
 --lifecycle-hook-name MyAgentTerminatingHook \
 --auto-scaling-group-name MyAgentASG \
 --lifecycle-transition "autoscaling:EC2_INSTANCE_TERMINATING" \
 --heartbeat-timeout 300 \ # 5 Minuten für den Abschluss des Shutdowns
 --default-result CONTINUE \
 --notification-target-arn arn:aws:sqs:REGION:ACCOUNT_ID:MyAgentTerminationQueue \
 --role-arn arn:aws:iam::ACCOUNT_ID:role/ASGLifecycleHookRole

# 2. Auf der Instanz muss Ihr Agent oder ein Wrapper-Skript dies tun, wenn es bereit ist:
# (Dies muss von einer IAM-Rolle ausgeführt werden, die die Berechtigungen zum Aufrufen von autoscaling:CompleteLifecycleAction hat)
aws autoscaling complete-lifecycle-action \
 --lifecycle-hook-name MyAgentTerminatingHook \
 --auto-scaling-group-name MyAgentASG \
 --lifecycle-action-result CONTINUE \
 --instance-id i-xxxxxxxxxxxxxxxxx

Der --heartbeat-timeout ist hier entscheidend. Er gibt Ihrem Agenten ein Zeitfenster (zum Beispiel 300 Sekunden), um seine Arbeit abzuschließen. Wenn er mehr Zeit benötigt, kann Ihr Agent regelmäßig record_lifecycle_action_heartbeat aufrufen, um die Frist zu verlängern, aber Sie sollten auf eine vorhersehbare Shutdown-Zeit abzielen.

3. Überwachung und Warnungen

Selbst mit der besten Drainagestrategie können Probleme auftreten. Ihre Agenten können sich aufhängen, während des Shutdowns auf einen nicht behandelten Fehler stoßen oder ihre Drainagezeit überschreiten. Eine solide Überwachung ist entscheidend:

• CloudWatch-Warnungen: Überwachen Sie Instanzen, die zu lange im Zustand „Terminating:Wait“ bleiben, ohne die Lifecycle-Aktion abzuschließen.
• Anwendungsprotokolle: Stellen Sie sicher, dass Ihre Agenten ihren Shutdown-Prozess klar protokollieren. Stoppen sie neue Arbeiten? Beenden sie die alte Arbeit? Speichern sie den Zustand?
• Metriken: Verfolgen Sie „laufende Aufgaben“, „offene Verbindungen“ oder „Warteschlangentiefe“ während des Shutdowns. Diese sollten idealerweise gegen null tendieren, bevor die Instanz vollständig beendet wird.

Mein früheres Team hat schließlich eine Warnung eingerichtet, die ausgelöst wurde, wenn eine Instanz mehr als 10 Minuten im Zustand `Terminating:Wait` verbrachte. Das bedeutete in der Regel, dass unser Agent sich aufgehängt hatte, und wir mussten der Ursache nachgehen, warum er den Abschluss nicht signalisierte. Das hat uns mehr als einmal vor potenziellen Dateninkonsistenzen bewahrt.

Über die Grundlagen hinaus: Fortgeschrittene Überlegungen

Idempotenz und Wiederholungen

Selbst mit einem sanften Shutdown sollten Sie einen Fehler annehmen. Gestalten Sie Ihre Agenten und die Dienste, mit denen sie interagieren, so, dass sie idempotent sind. Wenn ein Agent aufgrund eines komplizierten Shutdown-Szenarios eine Nachricht zweimal sendet, sollte der empfangende Dienst dies ohne Nebenwirkungen verarbeiten. Implementieren Sie robuste Wiederholungsmechanismen für alle externen Aufrufe, insbesondere während der Shutdown-Sequenz.

Verteilte Zustandsverwaltung

Für wirklich komplexe Agenten, die stark auf den Zustand angewiesen sind, sollten Sie in Erwägung ziehen, kritische Zustände in einen externen, gemeinsamen Speicher auszulagern. Denken Sie an Redis, eine persistente Nachrichtenwarteschlange wie Kafka oder eine Datenbank. So kann, wenn ein Agent unerwartet *hängt*, ein anderer Agent seine Arbeit von einem bekannten und guten Zustand aus fortsetzen. Dies ist eine größere architektonische Änderung, kann jedoch die Resilienz erheblich stärken.

Blue/Green Deployments für Updates ohne Ausfallzeiten

Obwohl es nicht strikt um Autoscaling geht, ist ein sanfter Shutdown ein zentrales Element, um Updates ohne Ausfallzeiten für Ihre Agenten zu erreichen. Mit denselben Drainagemethoden können Sie den Verkehr schrittweise von alten Versionen Ihrer Agenten auf neue umleiten und sicherstellen, dass die bestehenden Aufgaben auf der alten Flotte abgeschlossen werden, bevor sie deaktiviert wird.

Umsetzbare Tipps für Ihr nächstes Agenten-Deployment:

1. Implementieren Sie einen sanften Shutdown auf Anwendungsebene: Das ist nicht verhandelbar. Ihr Agent muss SIGTERM (oder das Äquivalent) verarbeiten, indem er neue Arbeiten stoppt, laufende Arbeiten beendet und Ressourcen freigibt. Testen Sie dies gründlich!
2. Verwenden Sie cloud-spezifische Drainage-Tools: Ob AWS Lifecycle Hooks, Kubernetes Pod Disruption Budgets oder Azure Scale Set-Benachrichtigungen, kennen und nutzen Sie die Mechanismen Ihres Cloud-Anbieters, um die Beendigung auszusetzen.
3. Setzen Sie realistische Fristen: Konfigurieren Sie Ihre Drainagefristen (zum Beispiel heartbeat-timeout) so, dass sie lang genug sind, damit Ihr Agent seine längste geplante Aufgabe abschließen kann, aber nicht so lang, dass ein blockierter Agent die Ressourcen unbegrenzt monopolisiert.
4. Überwachen Sie den Drainageprozess: Gehen Sie nicht einfach davon aus, dass es funktioniert. Erstellen Sie Warnungen für Instanzen, die nicht erfolgreich entleert werden oder zu viel Zeit in Anspruch nehmen. Protokollieren Sie den Shutdown-Prozess Ihres Agenten klar.
5. Entwickeln Sie für Idempotenz: Gehen Sie vom Schlimmsten aus. Wenn ein Agent nicht perfekt entleert wird, stellen Sie sicher, dass alle externen Aktionen, die er durchgeführt hat, sicher wiederholt oder ignoriert werden können.
6. Testen Sie regelmäßig Reduzierungsevents: Warten Sie nicht auf einen Vorfall in der Produktion. Simulieren Sie Reduzierungsevents in Ihrer Staging-Umgebung, um sicherzustellen, dass Ihr sanfter Shutdown wie vorgesehen funktioniert. Ich habe zu viele Teams gesehen, die nur die Erhöhung getestet haben!

Die Skalierbarkeit von zustandsbehafteten Agenten ist ein nuanciertes Spiel, keine brutale Operation. Indem Sie die notwendige Zeit investieren, um einen sanften Shutdown zu implementieren, vermeiden Sie unzählige Kopfschmerzen, verhindern Datenverluste und stellen sicher, dass Ihre Agentenflotte mit der Zuverlässigkeit funktioniert, die Ihre Benutzer erwarten. Bis zum nächsten Mal, halten Sie diese Agenten am Laufen!

🕒 Published: March 29, 2026