Orquestando el auto scaling de endpoints SageMaker con AWS CDK

Introducción

Actualizar un endpoint en tiempo real de Amazon SageMaker —por ejemplo cambiar tipo de instancia, número de instancias o variables de entorno— puede desencadenar fallas si el auto scaling de Application Auto Scaling está registrado. El problema surge porque SageMaker requiere que los “scalable targets” se deregistren antes de modificar ciertos aspectos del endpoint; sin embargo, si se hace esto manualmente, CloudFormation puede perder la pista de los recursos de auto scaling. En este artículo explicamos el problema, sus modos de fallo y una solución basada en un constructo reusable de AWS CDK que automatiza la orquestación con recursos personalizados de CloudFormation.

Por qué ocurre el problema

Cuando despliegan un endpoint SageMaker con recursos nativos de auto scaling en CloudFormation y luego intentan actualizar la configuración del endpoint, pueden ocurrir varias fallas según qué se cambie y cómo se intente resolver el conflicto.

• Si el scalable target sigue registrado, SageMaker rechaza la actualización con un mensaje que indica que las variantes deben ser deregistradas como “scalable targets” antes de eliminarlas o cambiar el tipo de instancia. En consecuencia, SageMaker bloquea la actualización antes de que CloudFormation alcance los recursos de auto scaling.

• Si se deregistra manualmente el scalable target (por ejemplo desde la CLI) y luego solo se cambia la configuración del endpoint, la actualización puede tener éxito, pero CloudFormation no volverá a registrar el auto scaling aunque la plantilla aún lo declare. Eso deja el endpoint operativo pero sin auto scaling, sin ningún error que alerte sobre la pérdida de la política de escalado.

• Si se deregistra manualmente y después se despliegan cambios en los parámetros de auto scaling, CloudFormation intentará actualizar un ScalableTarget que ya no existe y fallará con un error del tipo “resource not found”. Este escenario puede llevar a un UPDATE_ROLLBACK_FAILED y dejar la pila en un estado roto que necesita intervención manual para recuperarlo.

Solución: un constructo CDK que orquesta deregistrar y registrar

Para evitar estas situaciones, la solución propuesta reemplaza los recursos nativos AWS::ApplicationAutoScaling::ScalableTarget y AWS::ApplicationAutoScaling::ScalingPolicy por tres recursos personalizados (CloudFormation custom resources) gestionados desde un constructo de AWS CDK. La idea central es forzar un orden explícito de operaciones para:

1. Deregistrar el scalable target antes de que comience la actualización del endpoint.
2. Actualizar el endpoint con la nueva configuración.
3. Registrar nuevamente el scalable target cuando el endpoint esté en estado InService.
4. Adjuntar la política de escalado una vez que el scalable target sea consultable.

El constructo implementa dependencias explícitas usando node.add_dependency en CDK para garantizar que estas operaciones ocurran en orden.

Secuencia de orquestación

La secuencia completa que implementa el constructo es:

• Deregister (custom resource): elimina el scalable target antes de la actualización del endpoint. En el primer deploy, si no existe scalable target, el manejador captura el error y continúa sin bloquear.

• Endpoint update (gestionado por CDK): CDK actualiza el recurso del endpoint normalmente, aplicando la nueva configuración.

• Register Scalable Target (custom resource): espera a que el endpoint alcance el estado InService y luego registra el scalable target.

• Attach Scaling Policy (custom resource): espera a que el scalable target esté disponible para consultas y aplica la política de target tracking.

Detalles técnicos importantes

Register Scalable Target y Attach Scaling Policy utilizan el patrón de finalización asíncrona del proveedor CDK (cr.Provider). Cada recurso personalizado tiene un manejador on_event que responde de inmediato y un is_complete que verifica periódicamente la condición de completitud. El proveedor re-invoca is_complete en intervalos (cada 30 segundos) hasta que la verificación pase o hasta que se alcance un total_timeout: 1 hora para registrar el scalable target y 15 minutos para adjuntar la política de escalado. Esto evita la limitación de tiempo de una sola invocación Lambda.

Una propiedad ConfigHash en cada recurso personalizado fuerza a CloudFormation a re-invocar las funciones Lambda cuando cambian valores de configuración. Además, la configuración del endpoint y los parámetros de auto scaling se definen juntos, porque un solo ConfigHash controla la orquestación completa de auto scaling.

Aunque el constructo define tres custom resources, el stack desplegado contiene más funciones Lambda y estado porque cada recurso está respaldado por un cr.Provider. Los números relevantes observados en el enfoque son:

• Tres custom resources en la plantilla.
• Dos state machines de AWS Step Functions para manejar los waiters asíncronos.
• Doce funciones Lambda desplegadas en total.

De esas funciones, cinco contienen el código manejador del constructo (una para Deregister, y un par on_event/is_complete para cada recurso asíncrono), mientras que las siete restantes son generadas por el framework del proveedor. No es necesario implementar o mantener las funciones generadas por el framework, pero es importante considerarlas al revisar el inventario de recursos desplegados.

Consideraciones para equipos en América Latina

• Automatización y resiliencia operativa: para equipos que gestionan modelos en producción desde LATAM, eliminar la necesidad de intervención manual evita ventanas de error y reduce el riesgo operativo en despliegues críticos.

• Costos y gobernanza: al comprender que la solución despliega múltiples Lambdas y Step Functions adicionales, los equipos de infraestructura y finanzas deberían incluir esos recursos en sus estimaciones de costo y políticas de gobernanza.

• Control y trazabilidad: el uso de recursos personalizados y dependencias explícitas facilita auditar el flujo de cambio y manejar revisiones de infraestructura en entornos regulados o con requisitos de cumplimiento comunes en la región.

Walkthrough y siguientes pasos

El enfoque documentado ofrece un ejemplo de stack para desplegar un endpoint SageMaker con auto scaling usando el constructo. El walkthrough incluye pasos para clonar el repositorio de ejemplo, instalar dependencias, configurar los parámetros del endpoint y auto scaling, y desplegar para verificar que las actualizaciones de configuración funcionen sin intervención manual.

Si gestionan modelos en producción, integrar este tipo de constructo en su pipeline de despliegue reduce considerablemente el riesgo de fallas relacionadas con la orquestación de auto scaling. Revisen los recursos desplegados y ajusten timeouts y políticas según sus necesidades operativas.

Resumen

Actualizar endpoints SageMaker que tienen Application Auto Scaling registrado puede generar fallas y estados inconsistentes en CloudFormation. Reemplazar los recursos nativos de auto scaling por recursos personalizados orquestados desde un constructo CDK garantiza que el scalable target se deregistre y registre en el orden correcto, permitiendo actualizar la configuración del endpoint y las políticas de auto scaling en una sola implementación. Esta solución mejora la robustez de los despliegues y es particularmente útil para equipos que desean minimizar intervención manual y mantener trazabilidad en entornos de producción.