Construir con IA

Solución a los fallos de autoescalado de SageMaker durante las actualizaciones de endpoints con CDK

AWS ofrece una nueva construcción de CDK para gestionar la condición de carrera entre las actualizaciones de endpoints de SageMaker y el registro en Application Auto Scaling, evitando así fallos en el despliegue.

Diagrama abstracto que muestra tres engranajes conectados representando los pasos de desinscripción, actualización y registro.
Ilustración generada para este artículo

Traducido automáticamente del original en inglés.

La actualización de endpoints en tiempo real de Amazon SageMaker AI suele romper las configuraciones de autoescalado cuando se utilizan AWS CloudFormation o el AWS Cloud Development Kit (CDK). Una nueva solución de AWS introduce una construcción de CDK reutilizable que orquesta automáticamente la desinscripción y reinscripción de los objetivos escalables. Este enfoque permite a los ingenieros actualizar tipos de instancia, recuentos o variables de entorno en un único despliegue sin intervención manual ni corrupción de la pila.

Qué ocurrió

Los desarrolladores que despliegan endpoints de SageMaker AI con recursos nativos de autoescalado de CloudFormation se encuentran frecuentemente con fallos al modificar la configuración del endpoint. El problema principal surge porque SageMaker AI requiere que el objetivo escalable sea desinscrito antes de poder actualizar el endpoint, por ejemplo, al cambiar el tipo o el número de instancias. Sin embargo, CloudFormation gestiona estos recursos de forma declarativa, lo que genera un conflicto donde el servicio bloquea la actualización mientras el objetivo de autoescalado sigue activo.

Cuando los ingenieros intentan sortear esto desinscribiendo manualmente el objetivo escalable mediante la CLI de AWS, se enfrentan a dos modos de fallo distintos. Si vuelven a desplegar solo con cambios en la configuración del endpoint, CloudFormation no detecta cambios en los parámetros de autoescalado y omite la reinscripción del objetivo. El endpoint se actualiza correctamente, pero funciona sin autoescalado, dejando el sistema vulnerable a picos de tráfico sin ningún mensaje de error que alerte al equipo.

Si desinscriben manualmente y luego cambian los parámetros de autoescalado, CloudFormation intenta actualizar un recurso ScalableTarget que ya no existe. Esto resulta en un error "Resource not found" (Recurso no encontrado). Más crítico aún, el proceso de rollback también falla, dejando la pila de CloudFormation en estado UPDATE_ROLLBACK_FAILED. Recuperarse de este estado requiere tediosas intervenciones manuales en la consola, rompiendo el pipeline de automatización e incrementando el riesgo operativo.

Cómo funciona

La solución propuesta sustituye los recursos nativos AWS::ApplicationAutoScaling::ScalableTarget y AWS::ApplicationAutoScaling::ScalingPolicy por tres recursos personalizados gestionados por una construcción de CDK. Estos recursos personalizados imponen un orden de dependencias estricto utilizando llamadas a node.add_dependency, garantizando que el autoescalado se gestione correctamente alrededor del ciclo de vida de la actualización del endpoint. El proceso comienza con un recurso personalizado Deregister que elimina el objetivo escalable antes de iniciar la actualización del endpoint. En los despliegues iniciales, este handler ignora elegantemente los errores si aún no existe ningún objetivo.

Una vez eliminado el objetivo escalable, CDK procede a actualizar el recurso del endpoint en sí. Después de aceptar la actualización del endpoint, un recurso personalizado Register Scalable Target toma el control. Este recurso utiliza un patrón de finalización asincrónica, donde un handler on_event devuelve inmediatamente y un waiter vuelve a invocar un handler is_complete cada 30 segundos. Espera a que el endpoint alcance el estado InService antes de registrar el objetivo escalable, limitado por un tiempo total de una hora para evitar los límites de ejecución de Lambda.

Finalmente, un recurso personalizado Attach Scaling Policy asegura que se aplique la política de seguimiento de objetivos. También utiliza el patrón asincrónico para esperar hasta que el objetivo escalable sea consultable, lo cual puede tomar un breve momento después del registro. Una vez visible el objetivo, aplica la política. La propiedad ConfigHash impulsa toda esta secuencia, forzando a CloudFormation a volver a invocar las funciones Lambda cada vez que cambien los valores de configuración del endpoint o del autoescalado, manteniendo ambos sistemas sincronizados.

Detalles clave

  • La construcción sustituye los recursos nativos de autoescalado de CloudFormation por tres recursos personalizados: Deregister, Register Scalable Target y Attach Scaling Policy.
  • El orden de dependencias se impone mediante llamadas a node.add_dependency de CDK para asegurar la secuencia correcta de operaciones.
  • Los recursos personalizados asincrónicos utilizan un framework de proveedor con handlers on_event e is_complete, respaldados por máquinas de estados de AWS Step Functions.
  • El recurso Register Scalable Target tiene un tiempo límite total de una hora, mientras que Attach Scaling Policy tiene un tiempo límite de 15 minutos.
  • Una única propiedad ConfigHash desencadena la secuencia de orquestación cuando cambian los parámetros del endpoint o del autoescalado.
  • La pila desplegada incluye doce funciones Lambda y dos máquinas de estados de Step Functions, la mayoría generadas por el framework de proveedor de CDK.

Por qué importa

Para equipos que construyen infraestructura de IA en producción, la fiabilidad en los pipelines de despliegue es innegociable. El comportamiento anterior, que silenciosamente descartaba configuraciones de autoescalado o dejaba pilas en estados rotos, introdujo una deuda operativa significativa. Los ingenieros tenían que elegir entre intervenciones manuales vía CLI que rompían los principios de infraestructura como código o aceptar el riesgo de ejecutar modelos sin autoescalado. Esta solución restaura la promesa de la infraestructura declarativa, permitiendo a los equipos tratar los endpoints de SageMaker como cualquier otro recurso cloud que puede actualizarse de forma segura y predecible.

Además, el uso de recursos personalizados asincrónicos aborda un punto doloroso común en CloudFormation: operaciones de larga duración que exceden los tiempos límite de Lambda. Al delegar la lógica de espera al framework de proveedor y a Step Functions, la construcción asegura que los despliegues no fallen debido a problemas transitorios de temporización. Esta robustez es crítica para operaciones de ML a gran escala donde las actualizaciones de endpoints pueden tardar varios minutos en propagarse por la flota.

Qué puedes hacer

  • Clona el repositorio sample-sagemaker-endpoint-autoscaling desde GitHub para acceder a la implementación de referencia.
  • Instala las dependencias usando uv sync y realiza el bootstrap de tu entorno AWS con uv run cdk bootstrap.
  • Define tu endpoint y ajustes de autoescalado en config/config.yaml, asegurándote de incluir ambas secciones para generar el ConfigHash.
  • Despliega la pila de ejemplo usando uv run cdk deploy InferenceStack y verifica el objetivo escalable mediante la CLI de AWS.
  • Prueba una actualización cambiando el tipo de instancia en el archivo de configuración y volviendo a desplegar para confirmar que el autoescalado permanece intacto.
  • Integra la SagemakerAutoscalingConstruct en stacks de CDK existentes copiando el directorio de la construcción y pasando tu recurso de endpoint y hash de configuración.
  • #aws
  • #sagemaker
  • #cdk
  • #machine learning
  • #infrastructure

Herramientas de la Tienda de Bytechap

$89

DocBento

Gestión documental autoalojada que lee cada escaneo y responde con citas de página.

Demo en vivo
$79

WorkBento

Suite de RR. HH. y gestión del entorno laboral impulsada por IA que puedes alojar tú mismo.

Demo en vivo

Seguir leyendo

Todos los artículos