Behebung von Auto-Scaling-Fehlern bei SageMaker während CDK-Endpoint-Aktualisierungen

Die Aktualisierung von Amazon SageMaker AI-Echtzeit-Endpoints führt häufig dazu, dass Auto-Scaling-Konfigurationen beschädigt werden, wenn AWS CloudFormation oder das AWS Cloud Development Kit (CDK) verwendet wird. Eine neue Lösung von AWS führt eine wiederverwendbare CDK-Konstruktion ein, die die Abmeldung und erneute Anmeldung skalierbarer Ziele automatisch orchestriert. Dieser Ansatz ermöglicht es Ingenieuren, Instanztypen, Anzahl oder Umgebungsvariablen in einer einzigen Bereitstellung ohne manuelle Eingriffe oder Beschädigung des Stacks zu aktualisieren.

Was ist passiert?

Entwickler, die SageMaker AI-Endpoints mit nativen CloudFormation-Auto-Scaling-Ressourcen bereitstellen, stoßen häufig auf Bereitstellungsfehler, wenn sie Endpoint-Konfigurationen ändern. Das Kernproblem entsteht dadurch, dass SageMaker AI die Abmeldung des skalierbaren Ziels erfordert, bevor ein Endpoint aktualisiert werden kann, beispielsweise beim Ändern des Instanztyps oder der Instanzanzahl. Da CloudFormation diese Ressourcen jedoch deklarativ verwaltet, kommt es zu einem Konflikt, bei dem der Dienst die Aktualisierung blockiert, solange das Auto-Scaling-Ziel noch aktiv ist.

Wenn Ingenieure versuchen, dies durch manuelles Abmelden des skalierbaren Ziels über die AWS CLI zu umgehen, stehen sie vor zwei unterschiedlichen Fehlermodi. Wenn sie nur Änderungen an der Endpoint-Konfiguration neu bereitstellen, erkennt CloudFormation keine Änderung an den Auto-Scaling-Parametern und überspringt die erneute Registrierung des Ziels. Der Endpoint wird erfolgreich aktualisiert, läuft aber ohne Auto-Scaling, was das System anfällig für Traffic-Spitzen macht, ohne dass eine Fehlermeldung das Team warnt.

Wenn sie das Ziel manuell abmelden und dann die Auto-Scaling-Parameter ändern, versucht CloudFormation, eine ScalableTarget-Ressource zu aktualisieren, die nicht mehr existiert. Dies führt zu einem „Resource not found“-Fehler. Noch kritischer ist, dass auch der Rollback-Prozess fehlschlägt und den CloudFormation-Stack im Zustand UPDATE_ROLLBACK_FAILED belässt. Die Wiederherstellung aus diesem Zustand erfordert mühsame manuelle Eingriffe in der Konsole, bricht die Automatisierungspipeline und erhöht das operative Risiko.

Wie es funktioniert

Die vorgeschlagene Lösung ersetzt die nativen Ressourcen AWS::ApplicationAutoScaling::ScalableTarget und AWS::ApplicationAutoScaling::ScalingPolicy durch drei benutzerdefinierte Ressourcen, die von einer CDK-Konstruktion verwaltet werden. Diese benutzerdefinierten Ressourcen erzwingen eine strenge Abhängigkeitsreihenfolge unter Verwendung von node.add_dependency-Aufrufen, um sicherzustellen, dass Auto-Scaling korrekt im Lebenszyklus der Endpoint-Aktualisierung behandelt wird. Der Prozess beginnt mit einer Deregister-benutzerdefinierten Ressource, die das skalierbare Ziel entfernt, bevor die Endpoint-Aktualisierung startet. Bei Erstbereitstellungen ignoriert dieser Handler Fehler elegant, falls noch kein Ziel vorhanden ist.

Sobald das skalierbare Ziel entfernt wurde, fährt CDK mit der Aktualisierung der Endpoint-Ressource selbst fort. Nachdem die Endpoint-Aktualisierung akzeptiert wurde, übernimmt eine Register Scalable Target-benutzerdefinierte Ressource. Diese Ressource nutzt ein asynchrones Abschlussmuster, bei dem ein on_event-Handler sofort zurückkehrt und ein Waiter alle 30 Sekunden einen is_complete-Handler erneut aufruft. Er wartet darauf, dass der Endpoint den Status InService erreicht, bevor er das skalierbare Ziel registriert, begrenzt durch eine Gesamt-Timeout-Dauer von einer Stunde, um Lambda-Ausführungslimits zu vermeiden.

Schließlich stellt eine Attach Scaling Policy-benutzerdefinierte Ressource sicher, dass die Richtlinie zur Nachverfolgung der Zielwerte angewendet wird. Sie nutzt ebenfalls das asynchrone Muster, um zu warten, bis das skalierbare Ziel abfragbar ist, was nach der Registrierung einen kurzen Moment dauern kann. Sobald das Ziel sichtbar ist, wendet sie die Richtlinie an. Eine ConfigHash-Eigenschaft steuert diese gesamte Sequenz und zwingt CloudFormation dazu, die Lambda-Funktionen immer dann erneut aufzurufen, wenn sich Werte der Endpoint- oder Auto-Scaling-Konfiguration ändern, wodurch beide Systeme synchron gehalten werden.

Wichtige Details

• Die Konstruktion ersetzt native CloudFormation-Auto-Scaling-Ressourcen durch drei benutzerdefinierte Ressourcen: Deregister, Register Scalable Target und Attach Scaling Policy.
• Die Reihenfolge der Abhängigkeiten wird über CDK-node.add_dependency-Aufrufe erzwungen, um die korrekte Sequenz der Vorgänge sicherzustellen.
• Asynchrone benutzerdefinierte Ressourcen nutzen ein Provider-Framework mit on_event- und is_complete-Handlern, unterstützt durch AWS Step Functions State Machines.
• Die Register Scalable Target-Ressource hat ein Gesamt-Timeout von einer Stunde, während Attach Scaling Policy ein Timeout von 15 Minuten hat.
• Eine einzelne ConfigHash-Eigenschaft löst die Orchestrierungssequenz aus, wenn sich entweder Endpoint- oder Auto-Scaling-Parameter ändern.
• Der bereitgestellte Stack umfasst zwölf Lambda-Funktionen und zwei Step Functions State Machines, von denen die meisten vom CDK-Provider-Framework generiert werden.

Warum das wichtig ist

Für Teams, die produktionsreife KI-Infrastrukturen erstellen, ist Zuverlässigkeit in Bereitstellungspipelines nicht verhandelbar. Das bisherige Verhalten, Auto-Scaling-Konfigurationen stillschweigend zu entfernen oder Stacks in einem defekten Zustand zu belassen, führte zu erheblicher operativer Schuldenlast. Ingenieure mussten sich zwischen manuellen CLI-Eingriffen entscheiden, die Infrastructure-as-Code-Prinzipien verletzen, oder das Risiko akzeptieren, Modelle ohne Auto-Scaling auszuführen. Diese Lösung stellt das Versprechen der deklarativen Infrastruktur wieder her und ermöglicht es Teams, SageMaker-Endpoints wie jede andere Cloud-Ressource zu behandeln, die sicher und vorhersehbar aktualisiert werden kann.

Darüber hinaus adressiert die Nutzung asynchroner benutzerdefinierter Ressourcen einen häufigen Schmerzpunkt in CloudFormation: langlaufende Operationen, die Lambda-Timeouts überschreiten. Durch die Auslagerung der Wartelogik an das Provider-Framework und Step Functions stellt die Konstruktion sicher, dass Bereitstellungen nicht aufgrund transienter Timing-Probleme scheitern. Diese Robustheit ist für großskalige ML-Betrieb entscheidend, da Endpoint-Aktualisierungen mehrere Minuten benötigen können, um sich über die gesamte Flotte auszubreiten.

Was Sie tun können

• Klonen Sie das Repository sample-sagemaker-endpoint-autoscaling von GitHub, um auf die Referenzimplementierung zuzugreifen.
• Installieren Sie Abhängigkeiten mit uv sync und bootstrappen Sie Ihre AWS-Umgebung mit uv run cdk bootstrap.
• Definieren Sie Ihre Endpoint- und Auto-Scaling-Einstellungen in config/config.yaml und stellen Sie sicher, dass beide Abschnitte enthalten sind, um den ConfigHash zu generieren.
• Stellen Sie den Beispiel-Stack mit uv run cdk deploy InferenceStack bereit und überprüfen Sie das skalierbare Ziel über die AWS CLI.
• Testen Sie eine Aktualisierung, indem Sie den Instanztyp in der Konfigurationsdatei ändern und neu bereitstellen, um zu bestätigen, dass Auto-Scaling intakt bleibt.
• Integrieren Sie die SagemakerAutoscalingConstruct in bestehende CDK-Stacks, indem Sie das Verzeichnis der Konstruktion kopieren und Ihre Endpoint-Ressource sowie den Konfigurations-Hash übergeben.