Cómo Salesforce logró alta disponibilidad Multi-AZ con SageMaker Inference Components

Contexto y por qué importa para la región

El uso compartido de GPUs mediante Amazon SageMaker Inference Components (ICs) permite reducir significativamente costos de infraestructura —Salesforce reportó una reducción de 8x— al alojar múltiples modelos en aceleradores compartidos. Para empresas en América Latina, donde el control de costos y la continuidad operacional son prioridades, esta combinación de ahorro y resiliencia es especialmente atractiva. Sin embargo, ahorrar no debe comprometer la disponibilidad: muchos equipos y regulaciones exigen que los modelos en producción sean resistentes a la caída de una zona de disponibilidad (2-AZ).

El desafío técnico: puntos únicos de falla en despliegues por defecto

Por defecto, el algoritmo de placement de SageMaker optimiza cada operación de despliegue de forma independiente y tiende a maximizar la eficiencia de recursos. Eso significa que copias de un mismo componente de inferencia pueden concentrarse en una sola instancia o AZ, creando dos riesgos principales:

• Fallo a nivel de instancia: si la instancia que contiene todas las copias de un modelo falla, el modelo queda inaccesible.
• Fallo a nivel de AZ: si una AZ queda inservible, y todas las copias del modelo se encuentran ahí, el modelo se pierde.

Para Salesforce esto era inaceptable: su política exige soporte en al menos 2 AZs para modelos de producción. La colocación por defecto, enfocada en ahorro, no cumplía ese requisito de compliance.

La solución: SchedulingConfig en CreateInferenceComponent

AWS introdujo el parámetro SchedulingConfig en la API CreateInferenceComponent, que brinda control granular sobre cómo se colocan las copias de un Inference Component entre instancias y zonas. Dos subparámetros clave definen el comportamiento de alta disponibilidad:

• AvailabilityZoneBalance: permite balancear copias entre AZs con un umbral de tolerancia (MaxImbalance) y un modo de aplicación (EnforcementMode).
• PlacementStrategy (dentro de cada AZ): determina la distribución a nivel de instancias. SPREAD dispersa copias entre el mayor número posible de instancias para aislar fallos; BINPACK concentra copias en menos instancias para optimizar utilización.

Con estas opciones, equipos como el de Salesforce pudieron garantizar que las copias de un modelo se distribuyan entre AZs y entre instancias dentro de cada AZ, cumpliendo requisitos de 2-AZ sin renunciar a las ganancias de eficiencia.

Ejemplo práctico: distribuir 4 copias en 2 AZs

Salesforce trabajó con un endpoint multi-AZ que tenía 4 instancias repartidas en 2 AZs (2 instancias por AZ). La meta era desplegar 4 copias de un Inference Component y asegurar que quedaran equilibradas entre ambas AZs. El despliegue utilizó PlacementStrategy=SPREAD y una política de balanceo con MaxImbalance=1, lo que permite hasta una diferencia de una copia entre cualquier par de AZs.

Conceptualmente, la llamada a la API incluye parámetros clave como:

• ModelName: nombre del modelo
• ComputeResourceRequirements: cantidad de aceleradores y memoria mínima
• SchedulingConfig: PlacementStrategy (SPREAD) y AvailabilityZoneBalance (EnforcementMode y MaxImbalance)
• RuntimeConfig: CopyCount (número de copias)

Con CopyCount=4 y la configuración anterior, SageMaker distribuye las 4 copias en las 4 instancias: 2 en AZ-1 y 2 en AZ-2. Para modelos más livianos con solo 2 copias, ajustar MaxImbalance a 0 fuerza un balance estricto: exactamente 1 copia por AZ.

Escalado conservando el balance entre AZs

SchedulingConfig no solo guía el despliegue inicial: también influye en operaciones de scale-out y scale-in. Al escalar hacia arriba, SageMaker coloca nuevas copias procurando mantener la distribución equilibrada entre AZs. Al reducir CopyCount, elimina copias de forma simétrica entre AZs.

Importante: no se debe establecer CopyCount en 1 para modelos críticos de HA, porque una sola copia solo puede residir en una AZ y rompería el requisito de 2-AZ.

Además, para manejo a largo plazo —por ejemplo, tras múltiples ciclos de escalado— se recomienda configurar la ScaleInPolicy del endpoint con la estrategia CONSOLIDATION. Con CONSOLIDATION, un proceso de background consolida copias y libera instancias ociosas sin violar las restricciones de balanceo entre AZs.

Ejemplo de flujo operativo:

1. Crear o actualizar la configuración del endpoint con ManagedInstanceScaling y ScaleInPolicy: CONSOLIDATION.
2. Ajustar RuntimeConfig CopyCount para escalar.
3. SageMaker aplica SchedulingConfig en cada operación de escala y la política CONSOLIDATION se encarga de reequilibrar con el tiempo.

Los tres pilares del nuevo algoritmo de placement

La mejora introducida por AWS incorpora tres pilares que abordan directamente las necesidades de HA:

1. Distribución final balanceada: el algoritmo considera el balance del estado final, no solo la colocación inmediata.
2. Distribución consciente de disponibilidad: SageMaker procura repartir copias entre AZs de forma equitativa cuando es posible y mantiene la colocación durante actualizaciones de endpoint e IC.
3. Optimización dentro de cada AZ: la PlacementStrategy permite elegir entre SPREAD (aislamiento de fallos) o BINPACK (eficiencia de uso), según las prioridades del equipo.

Recomendaciones prácticas para equipos en América Latina

• Prioricen la definición de CopyCount acorde a los SLAs: nunca 1 en modelos HA críticos.
• Usen SPREAD si su objetivo principal es resiliencia; BINPACK cuando la limitación es costo y la carga puede tolerar mayor riesgo.
• Para entornos con restricciones de presupuesto, combinen ICs para aprovechar el ahorro en GPUs y SchedulingConfig para cumplir requisitos regulatorios y de continuidad.
• Configuren ScaleInPolicy=CONSOLIDATION para evitar fragmentación y liberar recursos a lo largo del tiempo manteniendo balance entre AZs.
• Validen su política de MaxImbalance: un valor permisivo (por ejemplo, 1) permite flexibilidad en despliegues en regiones con capacidades de instancia limitadas.

Conclusión

La capacidad de controlar el placement de Inference Components con SchedulingConfig permite a organizaciones como Salesforce conciliar la eficiencia de costos que brindan los ICs con los estrictos requisitos de alta disponibilidad Multi-AZ. Para empresas latinoamericanas en crecimiento, esta combinación es valiosa: reduce gastos de infraestructura sin sacrificar cumplimiento ni resiliencia operacional. Aprovechar SPREAD/BINPACK, AvailabilityZoneBalance y la política CONSOLIDATION ofrece un conjunto de herramientas prácticas para orquestar despliegues de modelos de inferencia seguros y eficientes en producción.