Vertiefende Analyse · Etwa 6 Min. Lesezeit
Der CDK-Leitfaden von AWS macht Endpoint-Skalierung zur Frage der Bereitstellungsreihenfolge
Eine Anleitung für SageMaker AI koordiniert Deregistrierung, Endpoint-Updates und Skalierungsbereitschaft. Wartezeiten, Beispielkapazitäten und erzeugte Ressourcen sind gesondert zu prüfen.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
Der AWS-Leitfaden von Lauren Eterno vom 23. Oktober behandelt ein Bereitstellungsproblem: einen SageMaker-AI-Endpoint zu aktualisieren und dabei seine Konfiguration für Application Auto Scaling zu erhalten. Er schlägt ein wiederverwendbares CDK-Konstrukt vor und kündigt weder ein neues Modell noch einen neuen Dienst an. Die Analyse von AISubHub verfolgt die Zustandsübergänge und die betrieblichen Prüfungen, die über einen erfolgreichen Bereitstellungsbefehl hinaus nötig bleiben.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Die Abfolge lautet Deregistrierung, Endpoint-Update, Bereitschaft im Zustand InService, Zielregistrierung und Abfragbarkeit des Ziels, bevor eine Richtlinie angehängt wird.
- Beide Konfigurationsabschnitte müssen in ConfigHash eingehen. Abfragen alle 30 Sekunden und Wartegrenzen von einer Stunde beziehungsweise fünfzehn Minuten sind keine Wiederherstellungsgarantien.
- Drei benutzerdefinierte Ressourcen erzeugen zwölf Lambda-Funktionen und zwei Step-Functions-Zustandsmaschinen; Beispielkapazitäten und Richtlinienwerte sind keine Empfehlungen für den Produktionsbetrieb.
Drei Fehler entstehen aus unterschiedlichen Zuständen
Der Leitfaden beschreibt drei Abläufe, wenn native CloudFormation-Ressourcen für automatische Skalierung ein Endpoint-Update begleiten. Erstens kann SageMaker das Update ablehnen, wenn das skalierbare Ziel registriert bleibt. Zweitens können eine manuelle Deregistrierung und eine Änderung nur der Endpoint-Konfiguration zu einer erfolgreichen Bereitstellung führen, bei der die automatische Skalierung fehlt: Unveränderte Vorlagenparameter veranlassen CloudFormation nicht, das Ziel oder die Richtlinie neu anzulegen.
Drittens versucht CloudFormation nach einer manuellen Deregistrierung und anschließenden Änderungen der Skalierungsparameter, ein nicht mehr vorhandenes Ziel zu aktualisieren. AWS beschreibt einen Fehler wegen der fehlenden Ressource und einen gescheiterten Rollback mit UPDATE_ROLLBACK_FAILED, der eine manuelle Wiederherstellung erfordert. Diese Fälle unterscheiden ein abgelehntes Update, einen unbemerkten Verlust der Skalierung und einen beschädigten Stack. Sie als ein allgemeines Wiederholungsproblem zu behandeln, würde ihre unterschiedlichen Zustände übersehen.
Änderungen ordnen und anschließend die Bereitschaft prüfen
Das Konstrukt ersetzt native ScalableTarget- und ScalingPolicy-Ressourcen durch drei benutzerdefinierte Ressourcen. Deregister läuft vor dem durch CDK verwalteten Endpoint-Update. Die Registrierungsressource wartet anschließend darauf, dass der Endpoint InService erreicht, registriert das Ziel und wird vor der Richtlinienressource ausgeführt. Diese letzte Ressource wartet, bis sich das Ziel abfragen lässt, bevor sie ihre Zielverfolgungsrichtlinie anwendet.
Aufrufe von CDK node.add_dependency drücken die Reihenfolge aus, während Handler die Bereitschaft feststellen. Der Deregistrierungs-Handler toleriert bei einer ersten Bereitstellung eine ObjectNotFoundException. Die Registrierungsprüfung verwendet describe_endpoint, wartet bei Zuständen ungleich InService weiter und löst bei Failed einen Fehler aus. AISubHub versteht dies als Unterschied zwischen dem Anordnen einer API-Aktion und dem Überprüfen des für den nächsten Schritt nötigen Zustands, nicht als Garantie für einen Betrieb ohne Ausfallzeit.
Eine Änderung der gemeinsamen Konfiguration muss die Abfolge auslösen
Endpoint- und Skalierungseinstellungen stehen in der Beispielkonfiguration zusammen. Eine ConfigHash-Eigenschaft jeder benutzerdefinierten Ressource veranlasst CloudFormation, die Handler erneut aufzurufen, wenn sich die darin berücksichtigte Konfiguration ändert. Das Integrationsbeispiel serialisiert ausdrücklich sowohl Endpoint- als auch Skalierungswerte in config_hash, sodass eine Änderung in einem der beiden Abschnitte die Orchestrierung auslöst.
Die technische Schlussfolgerung von AISubHub lautet, diesen Auslöser zusammen mit dem Abhängigkeitsgraphen zu prüfen. Würden nur Skalierungsfelder einbezogen, könnte eine Endpoint-Änderung den vorgesehenen Auslöser verfehlen; würden nur Endpoint-Felder einbezogen, könnten Skalierungsänderungen fehlen. Ein Hash signalisiert eine Eingabeänderung und prüft nicht, ob bereitgestellte Ressourcen der Datei entsprechen. Die tatsächliche Zielregistrierung und die Richtlinienwerte müssen nach der Bereitstellung weiterhin zurückgelesen werden.
Abfragegrenzen begrenzen das Warten, nicht die Wiederherstellungszeit
Registrierung und Anfügen der Richtlinie nutzen den asynchronen Abschlussmechanismus des CDK-Providers. Ihre on_event-Handler kehren sofort zurück; der Provider ruft is_complete alle 30 Sekunden auf. Für die Registrierung gilt ein total_timeout von einer Stunde, für das Anfügen der Richtlinie gelten fünfzehn Minuten. Diese Werte begrenzen die Wartezeit des Providers, nicht die Dauer eines einzelnen Lambda-Aufrufs, eine Wiederherstellungs-SLA oder ein Versprechen auf einen erfolgreichen Abschluss.
Die zweite Bereitschaftsprüfung behandelt die kurze Spanne, nachdem RegisterScalableTarget zurückgekehrt ist, das Ziel aber noch nicht abgefragt werden kann. Erst danach wendet der Handler die Richtlinie an. Die Abfolge Deregistrieren–Aktualisieren–Registrieren schafft außerdem eine Phase ohne die normale Skalierungskonfiguration. Nach der Analyse von AISubHub müssen Teams Kapazität während dieses Zeitfensters, Behandlung von Zeitüberschreitungen und Rollback-Verhalten für ihre Arbeitslast bewerten; der Artikel weist keinen unterbrechungsfreien Dienst nach.
Bereitgestellte Komponenten und Voraussetzungen vollständig zählen
Drei benutzerdefinierte Ressourcen bedeuten nicht drei Lambda-Funktionen. AWS zählt zwölf: Fünf enthalten die eigenen Handler des Konstrukts, sieben erzeugt das Provider-Framework. Die beiden asynchronen Provider erstellen außerdem zwei Step-Functions-Zustandsmaschinen. Vom Framework erzeugte Funktionen bleiben bereitgestellte Ressourcen, auch wenn Nutzer ihren Code nicht schreiben. Die Ressourcenprüfung sollte sie berücksichtigen und nicht nur sichtbare Handler zählen.
Die Anleitung setzt AWS CDK v2, Python 3.12 oder neuer, uv sowie ein AWS-Konto mit Berechtigungen für SageMaker AI, Lambda, IAM, Application Auto Scaling und CloudWatch voraus. Sie nennt ein S3-Modellartefakt und ein ECR-Image oder den dort beschriebenen Weg über einen Container mit integriertem Algorithmus. AISubHub empfiehlt, vor der Anpassung des Beispiels Berechtigungen nach dem Prinzip der geringsten Rechte, den Artefaktzugriff und die betriebliche Zuständigkeit zu prüfen. Dies ist technische Analyse und kein verifiziertes IAM-Audit.
Update und Bereinigung getrennt validieren
Das Beispiel verwendet minimale und maximale Kapazitäten von 1 und 10, target_value 100, scale_in_cooldown 600 und scale_out_cooldown 120. Dies sind Beispielfelder, keine empfohlenen Produktionskapazitäten, kein Durchsatz-Benchmark und keine Kostenschätzung. Die Anleitung prüft nach der Bereitstellung das skalierbare Ziel und die Skalierungsrichtlinie, ändert einen Endpoint-Wert, stellt erneut bereit und prüft, ob Registrierung und aktualisierte Werte weiterhin vorhanden sind.
Bei der Bereinigung werden Endpoint, Endpoint-Konfiguration, Modell, Lambda-Funktionen, IAM-Rollen und durch die Richtlinie erzeugte CloudWatch-Alarme entfernt sowie das Ziel deregistriert, um künftige Gebühren zu vermeiden. AISubHub hat diese Schritte nicht ausgeführt. Für ein Betriebsteam geht eine nützliche Abnahmeprüfung über einen erfolgreichen Stack-Status hinaus: Es muss die aktive Konfiguration, das Skalierungsverhalten, die Wiederherstellung nach Fehlern und den Umfang der Bereinigung unter eigenen Berechtigungen und eigenem Datenverkehr prüfen, ohne anzunehmen, das Beispiel beweise diese Eigenschaften.
Warum es wichtig ist
Die übertragbare Idee besteht darin, Bereitstellungsabhängigkeiten, Bereitschaftsprüfungen und Auslöser für Konfigurationsänderungen ausdrücklich zu machen. AISubHub leitet daraus ab, dass sich der Skalierungslebenszyklus so leichter untersuchen lassen kann. Die Übernahme des Konstrukts bringt jedoch zusätzliche, vom Provider verwaltete Komponenten und betriebliche Pflichten mit sich. Der Erfolg muss für den jeweiligen Endpoint und die Arbeitslast des Teams nachgewiesen und darf nicht aus den Beispielparametern abgeleitet werden.
Grenzen und Verfügbarkeit
Dies ist eine Analyse der technischen AWS-Anleitung von Lauren Eterno vom 23. Oktober, gelesen am 24. Oktober. Wir haben ihren Code nicht ausgeführt, keine kostenpflichtigen Ressourcen bereitgestellt, das verlinkte Repository nicht auditiert, keine Leistung gemessen und weder eine bestimmte Region noch ein bestimmtes Konto geprüft. Wartegrenzen sind keine SLA, Beispielwerte sind keine Empfehlungen, und weder ein bestimmtes zugrunde liegendes Modell noch die Veröffentlichung eines neuen Dienstes ist belegt.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.