Escalado basado en eventos en Azure Functions
En los planes Consumption, Flex Consumption y Premium, Azure Functions escala los recursos agregando más instancias en función del número de eventos que desencadenan una función.
La manera en que se escala la aplicación de funciones depende del plan de hospedaje:
Plan Consumption: 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 admite toda la aplicación de funciones. Por lo tanto, todas las funciones de un recurso compartido de aplicación de funciones de una instancia se escalan al mismo tiempo. Cuando las aplicaciones de funciones comparten el mismo plan de consumo, todavía se escalan de forma independiente.
Plan Flex Consumption: El plan usa una estrategia de escalado por función determinista, donde cada función se escala de forma independiente, excepto las funciones desencadenadas por HTTP, Blob y Durable Functions que se escalan en sus propios grupos. Para obtener más información, consulte Escalado por función. A continuación, estas instancias se escalan en función de la simultaneidad de las solicitudes.
Plan Premium: El tamaño específico del plan Premium determina la memoria disponible y la CPU para todas las aplicaciones de ese plan en esa instancia. El plan escala horizontalmente sus instancias en función de las necesidades de escalado de las aplicaciones del plan y las aplicaciones se escalan dentro del plan según sea necesario.
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
Si la aplicación de funciones deja de estar inactiva durante unos minutos, la plataforma podría decidir 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 inicios en frío afectan a las funciones, considere la posibilidad de usar un plan distinto del consumo. Los otros planes ofrecen estas estrategias para mitigar o eliminar los arranques en frío:
Plan Premium: admite instancias preprocesadas y siempre listas, con un mínimo de una instancia.
Plan Flex Consumption: admite un número opcional de instancias siempre listas, que se pueden definir según el escalado de instancias.
Plan dedicado: el propio plan no se escala dinámicamente, pero puede ejecutar la aplicación continuamente con la configuración AlwaysOn 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. Sin embargo, una sola instancia puede procesar más de un mensaje o solicitud a la vez. 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 destino: escalado basado en destino proporciona un modelo de escalado rápido e intuitivo para los clientes y actualmente es compatible con colas y temas de Service Bus, colas de Storage, Event Hubs, Apache Kafka y extensiones de Azure Cosmos DB. Asegúrese de revisar el escalado basado en el destino para comprender su comportamiento de escalado.
- Escalado por función: con algunas excepciones importantes, las funciones que se ejecutan en la escala del plan de consumo flexible en instancias independientes. Las excepciones incluyen desencadenadores HTTP y desencadenadores de Blob Storage (Event Grid). Cada uno de estos tipos de desencadenadores se escala conjuntamente como un grupo en las mismas instancias. Del mismo modo, todos los desencadenadores de Durable Functions también comparten instancias y escalan juntas. Para obtener más información, consulte Escalado por función.
- Desencadenadores supervisados máximos: actualmente, el controlador de escalado solo puede supervisar hasta 100 desencadenadores para tomar decisiones de escalado. Cuando la aplicación tiene más de 100 desencadenadores basados en eventos, solo se toman decisiones de escala en función de los primeros 100 desencadenadores que se ejecutan. Para obtener más información, consulte Procedimientos recomendados y patrones para aplicaciones escalables.
Límite de escalabilidad horizontal
Puede decidir restringir el número máximo de instancias que una aplicación puede usar para 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. Para conocer los límites de escala máximo al ejecutar los distintos planes de hospedaje, consulte Límites de escalado.
Plan de Consumo flexible
De forma predeterminada, las aplicaciones que se ejecutan en un plan de consumo flexible tienen un límite de 100 instancias generales. Actualmente, el valor máximo de recuento de instancias más bajo es 40, y el valor más alto de recuento máximo de instancias admitido es 1000. Cuando use el comando az functionapp create para crear una aplicación de funciones en el plan de consumo flexible, use el parámetro --maximum-instance-count para establecer este recuento máximo de instancias para la aplicación.
Tenga en cuenta que, aunque puede cambiar el número máximo de instancias de las aplicaciones de Consumo flexible hasta 1000, las aplicaciones alcanzarán un límite de cuota antes de alcanzar ese número. Consulte Cuotas de memoria de suscripción regionales para obtener más detalles.
En este ejemplo se crea una aplicación con un recuento máximo de instancias de 200:
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200
En este ejemplo se usa el comando az functionapp scale config set para cambiar el número máximo de instancias de una aplicación existente a 150:
az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150
Planes de consumo/Premium
En un plan Consumption o Elastic Premium, puede especificar un límite máximo inferior para la aplicación modificando el valor de la configuración de sitio de 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 Flex Consumption y 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 la aplicación que se ejecuta en Windows en un plan de consumo, solo las aplicaciones creadas después de mayo de 2021 tienen los comportamientos del modo de purga habilitados 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.
Escalado por función
Solo se aplica al plan de consumo flexible.
El plan Flex Consumption es único en el sentido de que implementa un comportamiento de escalado por función. En el escalado por función, excepto los desencadenadores HTTP, los desencadenadores de Blob (Event Grid) y Durable Functions, todos los demás tipos de desencadenadores de función de la aplicación se escalan en instancias independientes. Todos los desencadenadores HTTP de la aplicación se escalan conjuntamente como un grupo en las mismas instancias, como todos los desencadenadores Blob (Event Grid) y todos los desencadenadores de Durable Functions, que tienen sus propias instancias compartidas.
Considere la posibilidad de que una aplicación de funciones hospede un plan Flex Consumption que tenga estas funciones:
| function1 | function2 | function3 | function4 | function5 | function6 | function7 |
|---|---|---|---|---|---|---|
| Desencadenador HTTP | Desencadenador HTTP | Desencadenador de orquestación (Durable) | Desencadenador de actividad (Durable) | Desencadenador de Service Bus | Desencadenador de Service Bus | Desencadenador de Event Hubs |
En este ejemplo:
- Las dos funciones desencadenadas por HTTP (
function1yfunction2) se ejecutan juntas en sus propias instancias y se escalan conjuntamente según configuración de simultaneidad HTTP. - Las dos funciones Durable (
function3yfunction4) se ejecutan juntas en sus propias instancias y se escalan juntas en función de limitaciones de simultaneidad configuradas. - La función desencadenada
function5del Service Bus se ejecuta por sí misma y se escala de forma independiente según las reglas de escalado basadas en objetivos para las colas y temas del Service Bus. - La función desencadenada
function6del Service Bus se ejecuta por sí misma y se escala de forma independiente según las reglas de escalado basadas en objetivos para las colas y temas del Service Bus. - El desencadenador de Event Hubs (
function7) se ejecuta en sus propias instancias y se escala de forma independiente según las reglas de escalado basadas en destino para Event Hubs.
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).
Si la aplicación tiene más de 100 funciones que usan desencadenadores basados en eventos, considere la posibilidad de dividir la aplicación en una o varias aplicaciones, donde cada aplicación tiene menos de 100 funciones basadas en eventos.
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.
Pasos siguientes
Para más información, vea los siguientes artículos: