Correction des échecs de mise à l'échelle automatique SageMaker lors des mises à jour d'endpoints CDK

La mise à jour des endpoints en temps réel Amazon SageMaker AI casse souvent les configurations de mise à l'échelle automatique lors de l'utilisation d'AWS CloudFormation ou du AWS Cloud Development Kit (CDK). Une nouvelle solution proposée par AWS introduit un construct CDK réutilisable qui orchestre automatiquement la désinscription et la réinscription des cibles évolutives. Cette approche permet aux ingénieurs de mettre à jour les types d'instances, le nombre d'instances ou les variables d'environnement lors d'un seul déploiement, sans intervention manuelle ni corruption de la pile.

Ce qui s'est passé

Les développeurs déployant des endpoints SageMaker AI avec les ressources natives de mise à l'échelle automatique de CloudFormation rencontrent fréquemment des échecs de déploiement lorsqu'ils modifient les configurations des endpoints. Le problème principal vient du fait que SageMaker AI exige que la cible évolutive soit désinscrite avant qu'un endpoint ne puisse être mis à jour, par exemple lors d'un changement de type ou de nombre d'instances. Cependant, CloudFormation gère ces ressources de manière déclarative, créant un conflit où le service bloque la mise à jour tant que la cible de mise à l'échelle est encore active.

Lorsque les ingénieurs tentent de contourner ce problème en désinscrivant manuellement la cible évolutive via l'interface de ligne de commande AWS CLI, ils font face à deux modes d'échec distincts. S'ils redéploient uniquement avec des modifications de configuration de l'endpoint, CloudFormation ne détecte aucun changement dans les paramètres de mise à l'échelle et ignore la réinscription de la cible. L'endpoint est mis à jour avec succès, mais fonctionne sans mise à l'échelle automatique, laissant le système vulnérable aux pics de trafic sans message d'erreur pour alerter l'équipe.

S'ils désinscrivent manuellement puis modifient les paramètres de mise à l'échelle, CloudFormation tente de mettre à jour une ressource ScalableTarget qui n'existe plus. Cela entraîne une erreur « Resource not found ». Plus critique encore, le processus de retour arrière échoue également, laissant la pile CloudFormation dans un état UPDATE_ROLLBACK_FAILED. La récupération depuis cet état nécessite une intervention manuelle fastidieuse dans la console, rompant le pipeline d'automatisation et augmentant le risque opérationnel.

Comment cela fonctionne

La solution proposée remplace les ressources natives AWS::ApplicationAutoScaling::ScalableTarget et AWS::ApplicationAutoScaling::ScalingPolicy par trois ressources personnalisées gérées par un construct CDK. Ces ressources personnalisées imposent un ordre de dépendance strict en utilisant des appels node.add_dependency, garantissant que la mise à l'échelle automatique est correctement gérée autour du cycle de vie de la mise à jour de l'endpoint. Le processus commence par une ressource personnalisée Deregister qui supprime la cible évolutive avant le début de la mise à jour de l'endpoint. Lors des déploiements initiaux, ce gestionnaire ignore gracieusement les erreurs si aucune cible n'existe encore.

Une fois la cible évolutive supprimée, CDK procède à la mise à jour de la ressource endpoint elle-même. Après l'acceptation de la mise à jour de l'endpoint, une ressource personnalisée Register Scalable Target prend le relais. Cette ressource utilise un modèle d'achèvement asynchrone, où un gestionnaire on_event retourne immédiatement, et un waiter réinvoque un gestionnaire is_complete toutes les 30 secondes. Il attend que l'endpoint atteigne un statut InService avant d'inscrire la cible évolutive, avec une limite totale d'une heure pour éviter les limites d'exécution Lambda.

Enfin, une ressource personnalisée Attach Scaling Policy garantit que la politique de suivi de configuration est appliquée. Elle utilise également le modèle asynchrone pour attendre jusqu'à ce que la cible évolutive soit interrogeable, ce qui peut prendre un court instant après l'inscription. Une fois la cible visible, elle applique la politique. Une propriété ConfigHash pilote cette séquence entière, forçant CloudFormation à réinvoquer les fonctions Lambda chaque fois que les valeurs de configuration de l'endpoint ou de la mise à l'échelle changent, gardant ainsi les deux systèmes synchronisés.

Détails clés

• Le construct remplace les ressources natives de mise à l'échelle automatique de CloudFormation par trois ressources personnalisées : Deregister, Register Scalable Target et Attach Scaling Policy.
• L'ordre des dépendances est imposé via les appels CDK node.add_dependency pour garantir la séquence correcte des opérations.
• Les ressources personnalisées asynchrones utilisent un framework de fournisseur avec des gestionnaires on_event et is_complete, soutenus par des machines à états AWS Step Functions.
• La ressource Register Scalable Target a un délai total d'une heure, tandis que Attach Scaling Policy a un délai de 15 minutes.
• Une seule propriété ConfigHash déclenche la séquence d'orchestration lorsque les paramètres de l'endpoint ou de la mise à l'échelle changent.
• La pile déployée comprend douze fonctions Lambda et deux machines à états Step Functions, dont la plupart sont générées par le framework de fournisseur CDK.

Pourquoi c'est important

Pour les équipes construisant des infrastructures IA de production, la fiabilité des pipelines de déploiement est non négociable. Le comportement précédent, qui supprimait silencieusement les configurations de mise à l'échelle automatique ou laissait les piles dans des états cassés, introduisait une dette opérationnelle significative. Les ingénieurs devaient choisir entre des interventions manuelles via CLI qui violaient les principes d'infrastructure-as-code ou accepter le risque de faire tourner des modèles sans mise à l'échelle automatique. Cette solution restaure la promesse de l'infrastructure déclarative, permettant aux équipes de traiter les endpoints SageMaker comme toute autre ressource cloud pouvant être mise à jour de manière sûre et prévisible.

De plus, l'utilisation de ressources personnalisées asynchrones répond à un point de douleur courant dans CloudFormation : les opérations de longue durée dépassant les délais d'expiration Lambda. En déléguant la logique d'attente au framework de fournisseur et à Step Functions, le construct garantit que les déploiements n'échouent pas en raison de problèmes de timing transitoires. Cette robustesse est cruciale pour les opérations ML à grande échelle où les mises à jour des endpoints peuvent prendre plusieurs minutes pour se propager sur la flotte.

Ce que vous pouvez faire

• Clonez le dépôt sample-sagemaker-endpoint-autoscaling depuis GitHub pour accéder à l'implémentation de référence.
• Installez les dépendances en utilisant uv sync et initialisez votre environnement AWS avec uv run cdk bootstrap.
• Définissez vos paramètres d'endpoint et de mise à l'échelle dans config/config.yaml, en veillant à inclure les deux sections pour générer le ConfigHash.
• Déployez la pile d'exemple en utilisant uv run cdk deploy InferenceStack et vérifiez la cible évolutive via l'interface de ligne de commande AWS CLI.
• Testez une mise à jour en changeant le type d'instance dans le fichier de configuration et en redéployant pour confirmer que la mise à l'échelle automatique reste intacte.
• Intégrez le SagemakerAutoscalingConstruct dans les piles CDK existantes en copiant le répertoire du construct et en passant votre ressource endpoint et le hash de configuration.