Escalado basado en eventos en Azure Functions
En los planes Consumo y Premium, Azure Functions escala los recursos de CPU y memoria mediante la incorporación de instancias adicionales del host de Functions. El número de instancias se determina sobre el número de eventos que desencadenan una función.
Cada instancia del host de Functions del plan de consumo tiene una limitación, normalmente, de 1.5 GB de memoria y una CPU. Una instancia del host es la aplicación de funciones completa, lo que significa que todas las funciones de una aplicación de funciones comparten recursos al mismo tiempo en una instancia y escala determinadas. Las aplicaciones de funciones que comparten el mismo plan de consumo se escalan de manera independiente. En el plan Prémium, el tamaño del plan determina la memoria y la CPU disponibles para todas las aplicaciones de ese plan en esa instancia.
Los archivos de código de función se almacenan en recursos compartidos de Azure Files en la cuenta de almacenamiento principal de la función. Al eliminarse la cuenta de almacenamiento principal de la aplicación de función, los archivos de código de función también se eliminan y no se pueden recuperar.
Escalado del entorno de tiempo de ejecución
Azure Functions usa un componente denominado controlador de escala para supervisar la tasa de eventos y determinar si se debe escalar o reducir horizontalmente. El controlador de escala usa la heurística para cada tipo de desencadenador. Por ejemplo, cuando se usa un desencadenador de Azure Queue Storage, se usa el escalado basado en el destino.
La unidad de escala de Azure Functions es la aplicación de funciones. Al escalar horizontalmente la aplicación de función, se asignan más recursos para ejecutar varias instancias del host de Azure Functions. Por el contrario, si la demanda se reduce, el controlador de escala elimina instancias del host de la función. El número de instancias se "reduce horizontalmente" cuando no se ejecuta ninguna función en la aplicación de funciones.
Arranque en frío
Una vez que la aplicación de funciones ha estado inactiva durante varios minutos, la plataforma puede escalar el número de instancias en las que la aplicación se ejecuta hasta cero. La siguiente solicitud tiene la latencia agregada al escalar de cero a uno. Esta latencia se conoce como arranque en frío. El número de dependencias que requiere la aplicación de funciones puede afectar el momento del inicio en frío. El arranque en frío es más problemático para las operaciones sincrónicas, como los desencadenadores HTTP que deben devolver una respuesta. Si los arranques en frío afectan a las funciones, considere la posibilidad de realizar las ejecuciones en un plan Premium o en un plan dedicado con la opción Always On habilitada.
Descripción de los comportamientos de escalado
El escalado puede variar en función de varios factores, y las aplicaciones se escalan de forma diferente según los desencadenadores y el idioma seleccionados. Hay algunas complejidades de los comportamientos del escalado que hay que tener en cuenta:
- Número máximo de instancias: una aplicación de funciones única solo se escala horizontalmente hasta el máximo permitido por el plan. Una única instancia puede procesar más de un mensaje o solicitud a la vez, por lo que no hay un límite establecido en el número de ejecuciones simultáneas. Puede especificar un máximo inferior para limitar la escala según se requiera.
- Nueva tasa de instancias: En el caso de los desencadenadores HTTP, solo se asignan nuevas instancias como máximo una vez cada segundo. Para los desencadenadores que no son HTTP, solo se asignan nuevas instancias como máximo una vez cada 30 segundos. El escalado es más rápido cuando se ejecuta en un plan Premium.
- Escalado basado en el destino: el escalado basado en el destino proporciona un modelo de escalado rápido e intuitivo para los clientes y actualmente se admite para colas y temas de Service Bus, colas de Storage, Event Hubs y extensiones de Cosmos DB. Asegúrese de revisar el escalado basado en el destino para comprender su comportamiento de escalado.
Límite de escalabilidad horizontal
Es posible que quiera restringir el número máximo de instancias que una aplicación usa para realizar el escalado horizontal. Esto es más común en los casos en los que un componente de nivel inferior, como una base de datos, tiene un rendimiento limitado. De forma predeterminada, las funciones del plan de consumo se escalan horizontalmente hasta un máximo de 200 instancias, mientras que las funciones del plan Prémium se escalarán horizontalmente hasta un máximo de 100 instancias. Puede especificar un máximo inferior para una aplicación específica modificando el valor functionAppScaleLimit. functionAppScaleLimit se puede establecer en 0 o null para indicar que no hay restricciones, o en un valor válido entre 1 y el máximo de la aplicación.
az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>
Comportamientos de escalado horizontal
El escalado basado en eventos reduce automáticamente la capacidad cuando se reduce la demanda de las funciones. Para ello, purga las instancias de sus ejecuciones de función actuales y, a continuación, quita esas instancias. Este comportamiento se registra como modo de purga. El período de gracia para las funciones que se están ejecutando actualmente puede extender hasta 10 minutos para las aplicaciones del plan de consumo y hasta 60 minutos para las aplicaciones de plan Premium. El escalado basado en eventos y este comportamiento no se aplican a las aplicaciones de plan dedicado.
Las consideraciones siguientes se aplican a los comportamientos de escalado horizontal:
- En el caso de las aplicaciones de funciones del plan de consumo que se ejecutan en Windows, solo las aplicaciones creadas después de mayo de 2021 tienen habilitados los comportamientos del modo de purga de forma predeterminada.
- Para habilitar el apagado correcto para las funciones mediante el desencadenador de Service Bus, use la versión 4.2.0 o una versión posterior de la extensión de Service Bus.
Procedimientos recomendados y patrones para aplicaciones escalables
Hay muchos aspectos de una aplicación de funciones que afectan a cómo se escala, como la configuración del host, la superficie del entorno de tiempo de ejecución y la eficacia de los recursos. Para obtener más información, consulte la sección de escalabilidad del artículo sobre consideraciones de rendimiento. También debe tener en cuenta cómo se comportan las conexiones a medida que la aplicación de función se escala. Para más información, consulte How to manage connections in Azure Functions (Administración de conexiones en Azure Functions).
Para obtener más información sobre el escalado en Python y Node.js, consulte la Guía de Azure Functions para desarrolladores de Python: escalado y simultaneidad y la Guía para desarrolladores de Node.js para Azure Functions: escalado y simultaneidad.
Modelo de facturación
La facturación de los diferentes planes se describe en detalle en la página de precios de Azure Functions. El uso se agrega en el nivel de la aplicación de función, y solo se cuenta el tiempo que el código de la función está en ejecución. Estas son las unidades de facturación:
- Consumo de recursos en gigabytes-segundo (GB-s) . Se calcula como una combinación del tamaño de la memoria y el tiempo de ejecución de todas las funciones de una aplicación de función.
- Ejecuciones. Se cuenta cada vez que se ejecuta una función en respuesta a un desencadenador de eventos.
Puede encontrar consultas útiles y obtener información sobre cómo comprender la factura de consumo en las P+F sobre facturación.
Pasos siguientes
Para más información, vea los siguientes artículos: