Partager via

Mise à l’échelle basée sur des cibles

  • Article

La mise à l’échelle basée sur des cibles fournit un modèle de mise à l’échelle rapide et intuitif pour les clients. Elle est actuellement prise en charge pour ces extensions de liaison :

La mise à l’échelle basée sur des cibles remplace le modèle de mise à l’échelle incrémentielle Azure Functions précédent comme modèle par défaut pour ces types d’extensions. La mise à l’échelle incrémentielle a ajouté ou supprimé un maximum d’un Worker à chaque nouveau taux d’instance, avec des décisions complexes quant au moment de mettre à l’échelle. En revanche, la mise à l’échelle basée sur des cibles permet la mise à l’échelle de quatre instances à la fois, et la décision de mise à l’échelle est basée sur une équation simple basée sur des cibles :

Illustration de l’équation : instances souhaitées = longueur de la source d’événement / exécutions cibles par instance.

Dans cette équation, la longueur de la source d’événement fait référence au nombre d’événements qui doivent être traités. Les valeurs d’exécutions cibles par instance par défaut proviennent des SDK utilisés par les extensions Azure Functions. Vous n’avez pas besoin d’apporter des modifications pour que la mise à l'échelle basée sur des cibles fonctionne.

Considérations

Les considérations suivantes s’appliquent lors de l’utilisation de la mise à l’échelle basée sur la cible :

  • La mise à l’échelle basée sur des cibles est activée par défaut pour les applications de fonction sur le plan Consommation, le plan Consommation flexible et les plans Elastic Premium. La mise à l’échelle basée sur les événements n’est pas prise en charge lors de l’exécution sur des plans Dédié (App Service).
  • La mise à l’échelle pilotée par les cibles est activée par défaut à partir de la version 4.19.0 du runtime Functions.
  • Lorsque vous utilisez la mise à l’échelle basée sur les cibles, les limites de mise à l’échelle sont encore honorées. Pour plus d’informations, consultez Limiter le scale-out.
  • Pour obtenir la mise à l’échelle la plus précise en fonction des métriques, utilisez uniquement une fonction déclenchée basée sur des cibles par application de fonction. Vous devez également envisager d’exécuter dans un plan Consommation flexible qui offre une mise à l’échelle par fonction.
  • Lorsque plusieurs fonctions dans la même application de fonction demandent toutes un scale-out en même temps, une somme entre ces fonctions est utilisée pour déterminer le changement dans les instances souhaitées. Les fonctions qui demandent un scale-out remplacent les fonctions demandant un scale-in.
  • Lorsqu’il existe des demandes de scale-in sans demande de scale-out, la valeur d’échelle maximale est utilisée.

Refus

La mise à l’échelle basée sur la cible est activée par défaut pour les applications de fonction hébergées sur un plan Consommation ou sur un plan Premium. Pour désactiver la mise à l’échelle basée sur la cible et revenir à la mise à l’échelle incrémentielle, ajoutez le paramètre d’application suivant à votre application de fonction :

Paramètre d'application Valeur
TARGET_BASED_SCALING_ENABLED 0

Personnalisation de la mise à l’échelle basée sur des cibles

Vous pouvez rendre le comportement de mise à l’échelle plus ou moins agressif en fonction de la charge de travail de votre application en ajustant les exécutions cibles par instance. Chaque extension a des paramètres différents que vous pouvez utiliser pour définir des exécutions cibles par instance.

Ce tableau récapitule les valeurs host.json utilisées pour les valeurs des exécutions cibles par instance et les valeurs par défaut :

Extension Valeurs de host.json Valeur par défaut
Event Hubs (Extension v5.x+) extensions.eventHubs.maxEventBatchSize 100*
Event Hubs (Extension v3.x+) extensions.eventHubs.eventProcessorOptions.maxBatchSize 10
Event Hubs (si défini) extensions.eventHubs.targetUnprocessedEventThreshold n/a
Service Bus (Extension v5.x+, répartition unique) extensions.serviceBus.maxConcurrentCalls 16
Service Bus (Extension v5.x+, répartition unique basée sur les sessions) extensions.serviceBus.maxConcurrentSessions 8
Service Bus (Extension v5.x+, traitement par lots) extensions.serviceBus.maxMessageBatchSize 1 000
Service Bus (Functions v2.x+, répartition unique) extensions.serviceBus.messageHandlerOptions.maxConcurrentCalls 16
Service Bus (Functions v2.x+, répartition unique basée sur les sessions) extensions.serviceBus.sessionHandlerOptions.maxConcurrentSessions 2000
Service Bus (Functions v2.x+, traitement par lots) extensions.serviceBus.batchOptions.maxMessageCount 1 000
File d’attente de stockage extensions.queues.batchSize 16

* La valeur par défaut maxEventBatchSize a été modifiée dans v6.0.0 du package Microsoft.Azure.WebJobs.Extensions.EventHubs. Dans les versions antérieures, cette valeur était de 10.

Pour certaines extensions de liaison, les exécutions cibles par instance sont définies à l’aide d’un attribut de fonction :

Extension Paramètre de déclencheur de fonction Valeur par défaut
Apache Kafka lagThreshold 1 000
Azure Cosmos DB maxItemsPerInvocation 100

Pour plus d’informations, consultez les exemples de configurations pour les extensions prises en charge.

Plan Premium avec supervision de mise à l’échelle du runtime activée

Lorsque la surveillance de l’échelle du runtime est activée, les extensions elles-mêmes gèrent la mise à l’échelle dynamique. Cela est dû au fait que le contrôleur de mise à l’échelle n’a pas accès aux services sécurisés par un réseau virtuel. Après avoir activé la surveillance de l'échelle d'exécution, vous devrez mettre à jour vos paquets d'extension vers ces versions minimales pour débloquer la fonctionnalité supplémentaire de mise à l'échelle basée sur les cibles :

Nom de l’extension Version minimale requise
Apache Kafka 3.9.0
Azure Cosmos DB 4.1.0
Event Hubs 5.2.0
Service Bus 5.9.0
File d’attente de stockage 5.1.0

Prise en charge de la concurrence dynamique

La mise à l’échelle basée sur des cibles introduit une mise à l’échelle plus rapide et utilise des valeurs par défaut pour les exécutions cibles par instance. Lorsque vous utilisez Service Bus, des files d’attente de stockage ou Kafka, vous pouvez également activer la concurrence dynamique. Dans cette configuration, la valeur des exécutions cibles par instance est déterminée automatiquement par la fonctionnalité d’accès concurrentiel dynamique. Elle commence par une concurrence limitée et identifie le meilleur paramètre au fil du temps.

Extensions prises en charge

La façon dont vous configurez la mise à l’échelle basée sur des cibles dans votre fichier host.json dépend du type d’extension spécifique. Cette section fournit les détails de configuration des extensions qui prennent actuellement en charge la mise à l’échelle basée sur des cibles.

Files d’attente et rubriques Service Bus

L’extension Service Bus prend en charge trois modèles d’exécution, déterminés par les attributs IsBatched et IsSessionsEnabled de votre déclencheur Service Bus. La valeur par défaut pour IsBatched et IsSessionsEnabled est false.

Modèle d’exécution IsBatched IsSessionsEnabled Paramètre utilisé pour les exécutions cibles par instance
Traitement de la répartition unique false false maxConcurrentCalls
Traitement de répartition unique (basé sur une session) false true maxConcurrentSessions
Traitement par lots true false maxMessageBatchSize ou maxMessageCount

Notes

Efficacité de la mise à l’échelle : pour l’extension Service Bus, utilisez les droits Gérer sur les ressources pour une mise à l’échelle d’une efficacité optimale. Avec les droits Écouter, la mise à l’échelle revient à une échelle incrémentielle, car la longueur de la file d’attente ou du sujet ne peut pas être utilisée pour informer des décisions de mise à l’échelle. Pour en savoir plus sur la définition de droits dans les stratégies d’accès Service Bus, consultez Stratégie d’autorisation d’accès partagé.

Traitement de la répartition unique

Dans ce modèle, chaque appel de votre fonction traite un seul message. Le paramètre maxConcurrentCalls régit les exécutions cibles par instance. Le paramètre spécifique dépend de la version de l’extension Service Bus.

Modifiez le paramètre host.jsonmaxConcurrentCalls, comme dans l’exemple suivant :

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentCalls": 16
        }
    }
}

Traitement de répartition unique (basé sur une session)

Dans ce modèle, chaque appel de votre fonction traite un seul message. Toutefois, selon le nombre de sessions actives pour votre rubrique ou file d’attente Service Bus, chaque instance loue une ou plusieurs sessions. Le paramètre spécifique dépend de la version de l’extension Service Bus.

Modifiez le paramètre host.jsonmaxConcurrentSessions pour définir les exécutions cibles par instance, comme dans l’exemple suivant :

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxConcurrentSessions": 8
        }
    }
}

Traitement par lots

Dans ce modèle, chaque appel de votre fonction traite un lot de messages. Le paramètre spécifique dépend de la version de l’extension Service Bus.

Modifiez le paramètre host.jsonmaxMessageBatchSize pour définir les exécutions cibles par instance, comme dans l’exemple suivant :

{
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "maxMessageBatchSize": 1000
        }
    }
}

Event Hubs

Par Azure Event Hubs, Azure Functions est mis à l’échelle en fonction du nombre d’événements non traités distribués sur toutes les partitions de l’Event Hub. Par défaut, les attributs host.json utilisés pour les exécutions cibles par instance sont maxEventBatchSize et maxBatchSize. Toutefois, si vous choisissez d’affiner la mise à l’échelle basée sur des cibles, vous pouvez définir un paramètre targetUnprocessedEventThreshold distinct qui définit les exécutions cibles par instance sans modifier les paramètres de lot. Si targetUnprocessedEventThreshold est défini, le nombre total d’événements non traités est divisé par cette valeur pour déterminer le nombre nécessaire d’instances qui est ensuite arrondi à un nombre d’instances de Worker créant une distribution de partition équilibrée.

Notes

Étant donné qu’Event Hubs est une charge de travail partitionnée, le nombre d’instances cibles pour Event Hubs est limité par le nombre de partitions dans votre Event Hub.

Le paramètre spécifique dépend de la version de l’extension Event Hubs.

Modifiez le paramètre host.jsonmaxEventBatchSize pour définir les exécutions cibles par instance, comme dans l’exemple suivant :

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100
        }
    }
}

Lorsqu’il est défini dans host.json, targetUnprocessedEventThreshold est utilisé comme exécutions cibles par instance au lieu de maxEventBatchSize, comme dans l’exemple suivant :

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "targetUnprocessedEventThreshold": 153
        }
    }
}

Files d’attente de stockage

Pour la version v2.x+ de l’extension de stockage, modifiez le paramètre host.jsonbatchSize pour définir des exécutions cibles par instance :

{
    "version": "2.0",
    "extensions": {
        "queues": {
            "batchSize": 16
        }
    }
}

Notes

Efficacité de la mise à l’échelle : Pour l’extension de file d’attente du stockage, les messages avec visibilityTimeout sont toujours comptabilisés dans la longueur de la source de l’événement par les API file d’attente du stockage. Cela peut entraîner une mise à l’échelle excessive de votre application de fonction. Envisagez d’utiliser des files d’attente Service Bus que des messages planifiés, de limiter le scale-out ou de ne pas utiliser visibilityTimeout pour votre solution.

Azure Cosmos DB

Azure Cosmos DB utilise un attribut au niveau de la fonction, MaxItemsPerInvocation. La façon dont vous définissez cet attribut au niveau de la fonction dépend du langage de votre fonction.

Pour une fonction C# compilée, définissez MaxItemsPerInvocation dans votre définition de déclencheur, comme illustré dans les exemples suivants pour une fonction C# In-process :

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}");
            }
        }
    }
}

Remarque

Azure Cosmos DB étant une charge de travail partitionnée, le nombre d’instances cibles pour la base de données est limité par le nombre de partitions physiques dans votre conteneur. Pour en savoir plus sur la mise à l’échelle d’Azure Cosmos DB, consultez Partitions physiques et Propriété du bail.

Apache Kafka

L’extension Apache Kafka utilise un attribut au niveau de la fonction, LagThreshold. Pour Kafka, le nombre d’instances souhaitées est calculé en fonction du décalage total du consommateur divisé par le paramètre LagThreshold. Pour un décalage donné, la réduction du seuil de décalage augmente le nombre d’instances souhaitées.

La façon dont vous définissez cet attribut au niveau de la fonction dépend du langage de votre fonction. Dans cet exemple, le seuil est fixé à 100.

Pour une fonction C# compilée, définissez LagThreshold dans votre définition de déclencheur, comme illustré dans les exemples suivants pour une fonction C# In-process pour un déclencheur Kafka Event Hubs :

[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}");
}

Étapes suivantes

Pour en savoir plus, consultez les articles suivants :