Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Autoscaling, auto-stop y pools
Autoscaling, auto-termination y pools resuelven problemas distintos: capacidad, inactividad y latencia de aprovisionamiento.
- Duración
- 17 min aprox.
- Objetivo
- Autoscaling, auto-termination y pools resuelven problemas distintos: capacidad, inactividad y latencia de aprovisionamiento.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute clásico, serverless y SQL warehouses
Selecciona recursos por patrón de carga, aislamiento, latencia, gobernanza y coste total.
- Comparar serverless, classic y SQL warehouses
- Dimensionar sin sobredimensionar
- Aplicar auto-stop, políticas y modos de rendimiento
03OperaciónAutoscaling, auto-stop y pools
Autoscaling, auto-termination y pools resuelven problemas distintos: capacidad, inactividad y latencia de aprovisionamiento.
+
Autoscaling, auto-stop y pools
Autoscaling, auto-termination y pools resuelven problemas distintos: capacidad, inactividad y latencia de aprovisionamiento.
Autoscaling modifica el número de workers dentro de límites; no corrige un plan con skew ni garantiza que una tarea monohilo acelere. Auto-termination finaliza compute inactivo y reduce coste, pero debe equilibrarse con la experiencia interactiva.
Los pools mantienen instancias preparadas para classic compute y reducen el tiempo de arranque sin mantener clusters completos. Serverless gestiona su propio aprovisionamiento, por lo que no se combina con pools creados por el usuario.
Modelo mental
Autoscaling, auto-termination y pools actúan en momentos diferentes del ciclo de compute. Autoscaling modifica workers dentro de límites para una demanda paralelizable; no parte una única tarea sesgada ni acelera código ejecutado solo en el driver. Auto-termination apaga un recurso interactivo tras inactividad y controla ociosidad. Un pool conserva instancias clásicas preparadas para reducir aprovisionamiento, pero no mantiene un cluster completo ni se aplica al compute serverless gestionado. La pregunta útil no es cuál activar siempre, sino qué latencia o desperdicio se observa. Primero se identifica si el problema ocurre durante ejecución, durante inactividad o durante arranque; después se selecciona el mecanismo y se mide su efecto.
Aumento o reducción del número de workers disponibles para tareas paralelas.
Aclara cuándo autoscaling puede reducir duración y cuándo no.Periodo en el que un recurso permanece activo sin trabajo reconocido que justifique su coste.
Es la señal que auto-termination pretende limitar.Conjunto de instancias cloud preaprovisionadas para acelerar la creación de compute clásico.
Reduce latencia de arranque sin confundirla con capacidad durante una ejecución.{
"autoscale": {"min_workers": 2, "max_workers": 8},
"autotermination_minutes": 20,
"instance_pool_id": "pool-data-eng"
}Una compute policy debe limitar los valores permitidos en producción.
Puntos clave
- Autoscaling responde a demanda paralelizable
- Auto-termination controla inactividad
- Pools reducen el arranque de classic compute
Evita
- Usar autoscaling como solución automática al skew
- Configurar auto-termination por encima de la jornada laboral
Recuerdo activo