Partager via

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

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 exécutions cibles par défaut par instance proviennent des Kits de développement logiciel (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, la configuration exécutions cibles par instance est définie à 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, car 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 _exécution cible par instance est déterminée automatiquement par la fonctionnalité de concurrence 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

Remarque

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 d’écoute, la mise à l’échelle se rétablit vers une mise à l’échelle incrémentielle, car la longueur de la file d’attente ou de la rubrique ne peut pas être utilisée pour informer les 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

Pour 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 du hub d’événements dans une liste de nombres d’instances valides. 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.

Avertissement

Définir batchCheckpointFrequency au-dessus de 1 pour les plans d’hébergement pris en charge par la mise à l’échelle basée sur la cible peut entraîner un comportement incorrect de mise à l’échelle. La plateforme calcule les événements non traités comme étant « position actuelle - position de vérification », ce qui peut indiquer incorrectement des messages non traités lorsque des lots ont été traités mais pas encore vérifiés, ce qui empêche une réduction correcte de l'échelle lorsque plus aucun message ne reste.

Comportement et stabilité de la mise à l’échelle

Pour Event Hubs, les opérations de scale-in et de scale-out fréquentes peuvent déclencher un rééquilibrage de partition, ce qui entraîne des retards de traitement et une latence accrue. Pour atténuer cela :

  • La plateforme utilise une liste prédéfinie de nombres de workers valides pour guider les décisions de mise à l’échelle.
  • La plateforme garantit que la mise à l’échelle est stable et délibérée, ce qui évite les modifications perturbatrices apportées aux affectations de partition.
  • Si le nombre de workers souhaité n’est pas dans la liste valide (par exemple, 17, le système sélectionne automatiquement le plus grand nombre valide suivant, dans ce cas, 32). En outre, pour éviter une mise à l’échelle répétée rapide, les demandes de scale-in sont limitées pendant 3 minutes après le dernier scale-up. Ce délai permet de réduire le rééquilibrage inutile et contribue à maintenir l’efficacité du débit.

Nombres d’instances valides pour Event Hubs

Pour chaque nombre de partitions Event Hubs, nous calculons une liste correspondante de nombres d’instances valides pour garantir une distribution optimale et une mise à l’échelle efficace. Ces nombres sont choisis pour correspondre aux exigences en matière de partitionnement et de concurrence :

Nombre de partitions Nombres d’instances valides
1 [1]
2 [1, 2]
4 [1, 2, 4]
8 [1, 2, 3, 4, 8]
10 [1, 2, 3, 4, 5, 10]
16 [1, 2, 3, 4, 5, 6, 8, 16]
32 [1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 16, 32]

Ces nombres prédéfinis permettent de s’assurer que les instances sont distribuées aussi uniformément que possible sur plusieurs partitions, ce qui réduit les workers inactifs ou surchargés.

Remarque

Remarque : pour les niveaux hub d’événements Premium et Dédié, le nombre de partitions peut dépasser 32, ce qui permet d’obtenir des jeux de nombres d’instances valides plus volumineux. Ces niveaux prennent en charge un débit et une scalabilité plus élevés, et la liste de nombres de workers valides est étendue en conséquence pour répartir uniformément les partitions event Hub entre les instances. En outre, étant donné qu’Event Hubs est une charge de travail partitionnée, le nombre de partitions dans votre hub d’événements est la limite du nombre maximal d’instances cibles.

Paramètres Event Hubs

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
        }
    }
}

Remarque

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

Étant donné qu’Azure Cosmos DB est une charge de travail partitionnée, le nombre de partitions physiques dans votre conteneur est la limite du nombre d’instances cibles. 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 :

  • Last updated on