Escalado basado en el destino
El escalado basado en el destino proporciona a los clientes un modelo de escalado rápido e intuitivo y actualmente se admite para estas extensiones de enlace:
El escalado basado en el destino reemplaza el modelo de escalado incremental anterior de Azure Functions de forma predeterminada para esos tipos de extensiones. El escalado incremental agregaba o eliminaba como máximo un trabajo en cada nueva tasa de instancias, con las consiguientes decisiones complejas sobre cuándo escalar. En cambio, el escalado basado en el destino permite escalar cuatro instancias a la vez, en tanto que la decisión de escalado se basa en una ecuación sencilla basada en el destino:
En esta ecuación, longitud del origen del evento hace referencia al número de eventos que se deben procesar. Los valores predeterminados de ejecuciones de destino por instancia proceden de los SDK usados por las extensiones de Azure Functions. No es necesario hacer ningún cambio para que el escalado basado en el destino funcione.
Consideraciones
Las siguientes consideraciones se aplican cuando se utiliza el escalado basado en objetivos:
- El escalado basado en destino está habilitado de forma predeterminada para las aplicaciones de funciones en el plan de consumo, el plan de consumo flexible y los planes Elastic Premium. El escalado controlado por eventos no se admite cuando se ejecuta en planes dedicados (App Service).
- El escalado basado en destino está habilitado de forma predeterminada a partir de la versión 4.19.0 del entorno de ejecución de Functions.
- Cuando se usa el escalado basado en destino, se siguen respetando los límites de escala. Para obtener más información, consulte Limitar escalado.
- Para conseguir el escalado más preciso basado en métricas, utilice solo una función activada basada en objetivos por aplicación de función. También debe considerar la posibilidad de ejecutarse en un plan de consumo flexible, que ofrece escalado por función.
- Cuando varias funciones de la misma aplicación de funciones solicitan la reducción de escala al mismo tiempo, se utiliza una suma de todas esas funciones para determinar el cambio en las instancias deseadas. Las funciones que solicitan escalar horizontalmente invalidan las funciones que solicitan reducir horizontalmente.
- Cuando hay solicitudes de escalabilidad horizontal sin ninguna solicitud de reducir horizontalmente, se utiliza el valor máximo de escalabilidad horizontal.
No participar
El escalado basado en objetivos está activado de manera predeterminada para las aplicaciones de funciones hospedadas en un plan de Consumo o en un plan Premium. Para desactivar el escalado basado en objetivos y volver al escalado incremental, añada la siguiente configuración de aplicación a su aplicación de funciones:
| Configuración de aplicación | Value |
|---|---|
TARGET_BASED_SCALING_ENABLED |
0 |
Personalización del escalado basado en el destino
Para que el comportamiento de escalado sea más o menos acusado en función de la carga de trabajo de la aplicación, puede ajustar las ejecuciones de destino por instancia. Cada extensión tiene una configuración diferente que puede usar para establecer ejecuciones de destino por instancia.
En esta tabla se resumen los valores host.json que se usan para los valores de ejecuciones de destino por instancia y los valores predeterminados:
| Extensión | Valores host.json | Valor predeterminado |
|---|---|---|
| Event Hubs (extensión v5.x+) | extensions.eventHubs.maxEventBatchSize | 100* |
| Event Hubs (extensión v3.x+) | extensions.eventHubs.eventProcessorOptions.maxBatchSize | 10 |
| Event Hubs (si se define) | extensions.eventHubs.targetUnprocessedEventThreshold | N/D |
| Service Bus (extensión v5.x+, distribución única) | extensions.serviceBus.maxConcurrentCalls | 16 |
| Service Bus (extensión v5.x+, basado en sesiones de distribución única) | extensions.serviceBus.maxConcurrentSessions | 8 |
| Service Bus (extensión v5.x+, procesamiento por lotes) | extensions.serviceBus.maxMessageBatchSize | 1000 |
| Service Bus (funciones v2.x+, distribución única) | extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls | 16 |
| Service Bus (funciones v2.x+, basado en sesiones de distribución única) | extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions | 2000 |
| Service Bus (funciones v2.x+, procesamiento por lotes) | extensions.serviceBus.batchOptions.maxMessageCount | 1000 |
| Cola de almacenamiento | extensions.queues.batchSize | 16 |
* El valor predeterminado de maxEventBatchSize cambió en la versión 6.0.0 del paquete Microsoft.Azure.WebJobs.Extensions.EventHubs. En versiones anteriores, este valor era 10.
Para algunas extensiones de enlace, el valor de ejecuciones de destino por instancia se establece mediante un atributo de función:
| Extensión | Configuración de desencadenador de función | Valor predeterminado |
|---|---|---|
| Apache Kafka | lagThreshold |
1 000 |
| Azure Cosmos DB | maxItemsPerInvocation |
100 |
Para más información, consulte las configuraciones de ejemplo de las extensiones admitidas.
Plan Premium con la supervisión de escalado en tiempo de ejecución habilitada
Cuando se habilita la supervisión de escalado en tiempo de ejecución, las propias extensiones controlan el escalado dinámico. Esto se debe a que el controlador de escalado no tiene acceso a los servicios protegidos por una red virtual. Después de habilitar la supervisión de escalado en tiempo de ejecución, deberá actualizar los paquetes de extensión a estas versiones mínimas para desbloquear la funcionalidad adicional de escalado basado en destino:
| Nombre de la extensión | Versión mínima necesaria |
|---|---|
| Apache Kafka | 3.9.0 |
| Azure Cosmos DB | 4.1.0 |
| Event Hubs | 5.2.0 |
| Azure Service Bus | 5.9.0 |
| Cola de almacenamiento | 5.1.0 |
Compatibilidad con la simultaneidad dinámica
El escalado basado en el destino ofrece un escalado más rápido y usa valores predeterminados para las ejecuciones de destino por instancia. Al usar Service Bus, colas de Storage o Kafka, también puede habilitar la simultaneidad dinámica. En esta configuración, la característica de simultaneidad dinámica determina automáticamente el valor de las ejecuciones de destino por de instancia. Comienza con una simultaneidad limitada e identifica la mejor configuración a lo largo del tiempo.
Extensiones admitidas
Deberá configurar el escalado basado en el destino en el archivo host.json en función del tipo de extensión específico. En esta sección se proporcionan los detalles de configuración de las extensiones que admiten actualmente el escalado basado en el destino.
Colas y temas de Service Bus
La extensión de Service Bus admite tres modelos de ejecución, determinados por los atributos IsBatched y IsSessionsEnabled del desencadenador de Service Bus. El valor predeterminado de IsBatched y IsSessionsEnabled es false.
| Modelo de ejecución | IsBatched | IsSessionsEnabled | Configuración usada para las ejecuciones de destino por instancia |
|---|---|---|---|
| Procesamiento de distribución única | false | false | maxConcurrentCalls |
| Procesamiento de distribución única (basado en sesión) | false | true | maxConcurrentSessions |
| Procesamiento por lotes | true | false | maxMessageBatchSize o maxMessageCount |
Nota:
Eficiencia de escalado: para la extensión de Service Bus, use los derechos de administración en los recursos para lograr el escalado más eficaz. Con los derechos de escucha, vuelve a ser incremental porque no se puede utilizar la longitud de la cola o del tema para informar sobre las decisiones de escalado. Para más información sobre cómo establecer derechos en las directivas de acceso de Service Bus, consulte Directivas de autorización de acceso compartido.
Procesamiento de distribución única
En este modelo, cada invocación de la función procesa un único mensaje. El valor maxConcurrentCalls rige las ejecuciones de destino por instancia. El valor específico depende de la versión de la extensión de Service Bus.
Modifique el valor de host.jsonmaxConcurrentCalls tal como se muestra en el ejemplo siguiente:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentCalls": 16
}
}
}
Procesamiento de distribución única (basado en sesión)
En este modelo, cada invocación de la función procesa un único mensaje. No obstante, en función del número de sesiones activas para el tema o la cola de Service Bus, cada instancia concede una o varias sesiones. El valor específico depende de la versión de la extensión de Service Bus.
Modifique el valor de host.jsonmaxConcurrentSessions para establecer las ejecuciones de destino por instancia tal como se muestra en el ejemplo siguiente:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxConcurrentSessions": 8
}
}
}
Procesamiento por lotes
En este modelo, cada invocación de la función procesa un lote de mensajes. El valor específico depende de la versión de la extensión de Service Bus.
Modifique el valor de host.jsonmaxMessageBatchSize para establecer las ejecuciones de destino por instancia tal como se muestra en el ejemplo siguiente:
{
"version": "2.0",
"extensions": {
"serviceBus": {
"maxMessageBatchSize": 1000
}
}
}
Event Hubs
En el caso de Azure Event Hubs, Azure Functions escala en función del número de eventos no procesados distribuidos en todas las particiones del centro de eventos. De forma predeterminada, los atributos host.json que se usan para las ejecuciones de destino por instancia son maxEventBatchSize y maxBatchSize. Sin embargo, si quiere ajustar el escalado basado en el destino, puede definir un parámetro targetUnprocessedEventThreshold independiente que invalide el establecimiento de ejecuciones de destino por instancia sin cambiar la configuración del lote. Si el parámetro targetUnprocessedEventThreshold está establecido, el recuento total de eventos no procesados se dividirá por este valor para determinar el número de instancias, que se redondeará a un recuento de instancias de trabajo que cree una distribución de particiones equilibrada.
Nota:
Dado que Event Hubs es una carga de trabajo con particiones, el recuento de instancias de destino de Event Hubs está limitado por el número de particiones del centro de eventos.
El valor específico depende de la versión de la extensión de Event Hubs.
Modifique el valor de host.jsonmaxEventBatchSize para establecer las ejecuciones de destino por instancia tal como se muestra en el ejemplo siguiente:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"maxEventBatchSize" : 100
}
}
}
Cuando se define en host.json, targetUnprocessedEventThreshold se usa como ejecuciones de destino por instancia en lugar de maxEventBatchSize, como en el ejemplo siguiente:
{
"version": "2.0",
"extensions": {
"eventHubs": {
"targetUnprocessedEventThreshold": 153
}
}
}
Colas de almacenamiento
Para la v2.x+ de la extensión de Storage, modifique el valor de host.jsonbatchSize para establecer las ejecuciones de destino por instancia:
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 16
}
}
}
Nota
Eficiencia de escala: para la extensión de cola de almacenamiento, las API de Storage Queue siguen contando los mensajes con visibilityTimeout en la longitud del origen del evento. Esto puede provocar un escalado excesivo de la aplicación de funciones. Considere la posibilidad de usar mensajes programados por colas de Service Bus, limitar el escalado horizontal o no usar visibilityTimeout para la solución.
Azure Cosmos DB
Azure Cosmos DB usa un atributo de nivel de función: MaxItemsPerInvocation. Deberá establecer este atributo de nivel de función según el lenguaje de la función.
Para una función de C# compilada, establezca MaxItemsPerInvocation en la definición del desencadenador, tal como se muestra en los ejemplos siguientes para una función de C# en proceso:
namespace CosmosDBSamplesV2
{
public static class CosmosTrigger
{
[FunctionName("CosmosTrigger")]
public static void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
collectionName: "Items",
MaxItemsPerInvocation: 100,
ConnectionStringSetting = "CosmosDBConnection",
LeaseCollectionName = "leases",
CreateLeaseCollectionIfNotExists = true)]IReadOnlyList<Document> documents,
ILogger log)
{
if (documents != null && documents.Count > 0)
{
log.LogInformation($"Documents modified: {documents.Count}");
log.LogInformation($"First document Id: {documents[0].Id}");
}
}
}
}
Nota:
Dado que Azure Cosmos DB es una carga de trabajo con particiones, el recuento de instancias de destino de la base de datos está limitado por el número de particiones físicas del contenedor. Para más información sobre el escalado de Azure Cosmos DB, consulte las particiones físicas y la propiedad de concesión.
Apache Kafka
La extensión de Apache Kafka usa un atributo de nivel de función, LagThreshold. Para Kafka, el número de instancias deseadas se calcula en función del retraso total del consumidor dividido por el valor de LagThreshold. Para un retraso determinado, reducir el umbral de retraso aumenta el número de instancias deseadas.
Deberá establecer este atributo de nivel de función según el lenguaje de la función. En este ejemplo, se establece el umbral en 100.
Para una función de C# compilada, establezca LagThreshold en la definición del desencadenador, tal como se muestra en los ejemplos siguientes para una función de C# en proceso para un desencadenador de Event Hubs de Kafka:
[FunctionName("KafkaTrigger")]
public static void Run(
[KafkaTrigger("BrokerList",
"topic",
Username = "$ConnectionString",
Password = "%EventHubConnectionString%",
Protocol = BrokerProtocol.SaslSsl,
AuthenticationMode = BrokerAuthenticationMode.Plain,
ConsumerGroup = "$Default",
LagThreshold = 100)] KafkaEventData<string> kevent, ILogger log)
{
log.LogInformation($"C# Kafka trigger function processed a message: {kevent.Value}");
}
Pasos siguientes
Para más información, vea los siguientes artículos: