Escalado basado en eventos en Azure Functions

El escalado basado en eventos no se aplica al plan Dedicado (Servicio de Apps). El plan dedicado no escala dinámicamente según los eventos. Para las opciones de escalado en el plan Dedicado, consulta Escalar una aplicación en Azure App Service.

El escalado basado en eventos no se aplica al ejecutar funciones en Azure Container Apps. Cuando se aloja en Aplicaciones Contenedor, el escalado se gestiona mediante el entorno Aplicaciones Contenedor. Para obtener más información, consulte Establecer reglas de escalado en Azure Container Apps.

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. Cuando la app de funciones escala más, asigna más recursos para ejecutar múltiples instancias del host de Azure Functions. Por el contrario, a medida que disminuye la demanda de cómputo, el controlador de escala elimina instancias de host de funciones. El número de instancias se "reduce horizontalmente" cuando no se ejecuta ninguna función en la aplicación de funciones.

Cada instancia del host de Funciones en el plan de Consumo está limitada, normalmente a 1,5 GB de memoria y una CPU. Una instancia del host soporta toda la aplicación de funciones, así que todas las funciones de una app comparten recursos y escalan al mismo tiempo. Cuando las aplicaciones de funciones comparten el mismo plan de Consumo, siguen escalando de forma independiente.

El tamaño específico del plan Premium determina la memoria y CPU disponibles 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.

A diferencia de otros planes dinámicos, el plan Flex Consumption utiliza un modelo de escalado determinista por función. En este modelo, cada función se escala de forma independiente en función del número de eventos y la configuración de concurrencia, excepto para las funciones activadas por HTTP, Blob y orquestación (Durable), que escalan en sus propios grupos. Para obtener más información, consulte Escalado por función.

La plataforma gestiona la tasa a la que añade instancias (la curva de escala), por separado del recuento máximo de instancias. Para más información sobre cómo funciona la curva de escala, el comportamiento de la limitación y las mejores prácticas para la escala de alta velocidad, véase Tasa de escalada.

Arranque en frío

Si tu app de funciones permanece inactiva unos minutos, la plataforma podría reducir el número de instancias que ejecutan tu app a cero. La siguiente petición experimenta la latencia añadida de escalar de cero a uno. Esta latencia se conoce como arranque en frío. El número de dependencias que requiere tu app de funciones puede afectar la hora de 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 están afectando a tus funciones, considera usar un plan que apoye estrategias de mitigación:

Como puedes ver en esta tabla, tanto los planes Flex Consumption como los Premium ofrecen formas de eliminar los arranques en frío en tus aplicaciones.

Descripción de los comportamientos de escalado

El escalado puede variar en función de varios factores. Las aplicaciones escalan de forma diferente según los desencadenantes y el idioma seleccionado. Ten en cuenta estas particularidades de los comportamientos de escalabilidad:

• Más casos: Una sola aplicación de función escala 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.

• Tasa de nueva instancia: Para los disparadores HTTP, la plataforma asigna nuevas instancias como máximo una vez por segundo. Para disparadores no HTTP, la plataforma asigna 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: El escalado basado en destino proporciona un modelo de escalado rápido e intuitivo para los clientes. Actualmente, este método de escalado se admite para colas y tópicos de Service Bus, colas de almacenamiento, Event Hubs, Apache Kafka, así como 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, los desencadenadores de todas las instancias de Durable Functions también comparten instancias y escalan juntas. Para obtener más información, consulte Escalado por función.

• Disparadores máximos monitorizados: Actualmente, el controlador de báscula solo puede monitorizar hasta 100 disparadores para tomar decisiones de escalado. Cuando tu app tiene más de 100 disparadores basados en eventos, las decisiones de escala se basan solo en los primeros 100 disparadores 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. Esta limitación 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.

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 1, 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.

El recuento máximo de instancias se aplica a instancias bajo demanda en cada grupo de escala por función (grupo de funciones) en lugar de a las instancias combinadas de la app. Las instancias siempre listas no están limitadas por el número máximo de instancias ni cuentan para él.

Aunque puedes cambiar el recuento máximo de instancias de las aplicaciones Flex Consumption hasta 1000, el límite de cuota para tus aplicaciones se alcanza antes de llegar a 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-account <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

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>

$resource = Get-AzResource -ResourceType Microsoft.Web/sites -ResourceGroupName <RESOURCE_GROUP> -Name <FUNCTION_APP-NAME>/config/web
$resource.Properties.functionAppScaleLimit = <SCALE_LIMIT>
$resource | Set-AzResource -Force

Tasa de escalabilidad

En el plan Flex Consumption, la plataforma también gestiona la tasa a la que añade instancias (la curva de escala), por separado del recuento máximo de instancias. Para cómo funciona la curva de escala, el comportamiento de limitación y las mejores prácticas para escalar a altas tasas, véase Tasa de escalada.

Tasa de escalabilidad

En los planes de Consumo y Premium, el controlador de báscula gestiona la velocidad a la que se añaden nuevas instancias. En el caso de los desencadenadores HTTP, solo se asignan nuevas instancias como máximo una vez cada segundo. Para disparadores no HTTP, 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.

Comportamientos de escalado horizontal

El escalado basado en eventos reduce automáticamente la capacidad cuando se reduce la demanda de las funciones. Hace esta reducción al drenar instancias de sus ejecuciones de función actuales y, a continuación, eliminar 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 Consumo flexible 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 las aplicaciones que se ejecutan 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

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 una aplicación de funciones hospedada por un plan de consumo flexible que tenga las siguientes funciones:

En este ejemplo:

• Las dos funciones desencadenadas por HTTP (function1 y function2) se ejecutan juntas en sus propias instancias y se escalan conjuntamente según configuración de simultaneidad HTTP.
• Las dos funciones Durable (function3 y function4) se ejecutan juntas en sus propias instancias y se escalan juntas en función de limitaciones de simultaneidad configuradas.
• La función desencadenada function5 del 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 function6 del 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

Muchos aspectos de una aplicación de funciones influyen en su escala, incluyendo la configuración del host, la huella en tiempo de ejecución y la eficiencia 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 tu app tiene más de 100 funciones que usan disparadores basados en eventos, considera dividirla en una o más aplicaciones, donde cada app tenga menos de 100 funciones basadas en eventos.

Para más información sobre el escalado en Python y Node.js, consulte la sección Escalado y rendimiento de la guía para desarrolladores de Python de Azure Functions y la sección Escalado y simultaneidad de la guía para desarrolladores de Azure Functions Node.js.