Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Dans Azure Functions, une seule instance d’application de fonction permet de traiter plusieurs événements simultanément. Étant donné que ceux-ci s’exécutent sur la même instance de calcul, ils partagent la mémoire, le processeur et les ressources de connexion. Dans certains plans d’hébergement, la forte demande sur une instance spécifique entraîne la création automatique par l’hôte Functions de nouvelles instances pour gérer la charge accrue. Dans ces plans d’échelle dynamique , il existe un compromis entre la concurrence et les comportements de mise à l’échelle. Pour mieux contrôler l’exécution de votre application, Functions vous permet de gérer le nombre d’exécutions simultanées.
Functions fournit deux méthodes principales de gestion de la concurrence :
- Concurrence fixe par instance : vous pouvez configurer des limites au niveau de l'hôte sur la concurrence spécifique à chaque déclencheur. Ce modèle est le comportement de concurrence par défaut pour Functions.
- Concurrence dynamique : pour certains types de déclencheurs, l’hôte Functions peut déterminer automatiquement le meilleur niveau de concurrence pour ce déclencheur dans votre application de fonction. Vous devez choisir ce modèle de concurrence.
Cet article décrit les comportements de concurrence des déclencheurs pilotés par les événements dans Functions et comment ces comportements affectent la mise à l’échelle dans les plans dynamiques. Il compare également les modèles de concurrence fixe par instance et dynamique.
Mise à l’échelle et concurrence
Pour les fonctions qui utilisent des déclencheurs basés sur des événements ou répondent aux requêtes HTTP, vous pouvez rapidement atteindre les limites des exécutions simultanées pendant des périodes de forte demande. Pendant ces périodes, vous devez être en mesure de mettre à l’échelle votre application de fonction en ajoutant des instances pour éviter un backlog dans le traitement des requêtes entrantes. La façon dont nous mettons à l’échelle votre application dépend de votre plan d’hébergement :
| Type d’échelle | Plans d’hébergement | Description |
|---|---|---|
| Mise à l’échelle dynamique (pilotée par les événements) |
Consommation Consommation flexible Prime |
Dans un plan d’échelle dynamique, l’hôte met à l’échelle le nombre d’instances d’application de fonction vers le haut ou vers le bas en fonction du nombre d’événements entrants. Pour plus d’informations, consultez la mise à l’échelle basée sur les événements dans Azure Functions. |
| Mise à l’échelle manuelle | Plans (App Service) dédiés | Lorsque vous hébergez votre application de fonction dans un plan dédié, vous devez configurer manuellement vos instances pendant des périodes de charge plus élevée ou configurer un schéma de mise à l’échelle automatique. |
Avant toute mise à l’échelle, votre application de fonction tente de gérer les augmentations de charge en gérant plusieurs appels du même type dans une seule instance. Par conséquent, ces exécutions simultanées sur une instance donnée ont un impact direct sur les décisions d’échelle. Par exemple, lorsqu’une application d’un plan de mise à l’échelle dynamique atteint une limite d’accès concurrentiel, il peut être nécessaire de procéder à une mise à l’échelle pour suivre la demande entrante.
L’équilibre entre la mise à l’échelle et la concurrence que vous essayez d’atteindre dans votre application dépend de l’endroit où les goulots d’étranglement peuvent se produire : dans le traitement (limitations de processus nécessitant beaucoup d’UC) ou dans un service en aval (limitations basées sur les E/S).
Correction de la concurrence par instance
Par défaut, la plupart des déclencheurs prennent en charge un modèle de configuration concurrentiel par instance fixe via la mise à l’échelle basée sur la cible. Dans ce modèle, chaque type de déclencheur a une limite de concurrence par instance.
Vous pouvez remplacer les valeurs par défaut de concurrence pour la plupart des déclencheurs en définissant une concurrence par instance spécifique pour ce type de déclencheur. Pour de nombreux déclencheurs, vous configurez les paramètres d’accès concurrentiel dans le fichierhost.json. Par exemple, le déclencheur Azure Service Bus fournit à la fois un MaxConcurrentCalls paramètre et un MaxConcurrentSessions paramètre dans host.json. Ces paramètres fonctionnent ensemble pour contrôler le nombre maximal de messages que chaque application de fonction traite simultanément sur chaque instance.
Dans certains scénarios de mise à l’échelle basés sur la cible, par exemple lorsque vous utilisez un déclencheur Apache Kafka ou Azure Cosmos DB, la configuration de la concurrence se trouve dans la déclaration de fonction, et non dans le fichier host.json . D’autres types de déclencheurs ont des mécanismes intégrés pour l’équilibrage de charge des appels entre les instances. Par exemple, Azure Event Hubs et Azure Cosmos DB utilisent tous deux un schéma basé sur une partition.
Les paramètres de simultanéité sont appliqués à toutes les instances en cours d'exécution pour les types de déclencheurs qui supportent la configuration de la simultanéité. De cette façon, vous pouvez contrôler la concurrence maximale pour vos fonctions sur chaque instance. Par exemple, lorsque votre fonction est gourmande en ressources ou nécessitant beaucoup d’UC, vous pouvez choisir de limiter la concurrence pour maintenir l’intégrité des instances. Dans ce cas, vous pouvez vous appuyer sur la mise à l’échelle pour gérer des charges accrues. De même, lorsque votre fonction envoie des requêtes à un service en aval qui est limité, vous devez également envisager de limiter la concurrence pour éviter de surcharger le service en aval.
Concurrence du déclencheur HTTP
S’applique uniquement au plan Flex Consumption
La concurrence du déclencheur HTTP est un type de concurrence fixe particulier par instance. Dans la concurrence du déclencheur HTTP, la concurrence par défaut dépend également de la taille de l’instance.
Le plan Consommation flexible met à l’échelle toutes les fonctions de déclencheur HTTP ensemble en tant que groupe. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle par fonction.
Le tableau suivant indique le paramètre d’accès concurrentiel par défaut pour les déclencheurs HTTP sur une instance donnée, en fonction de la taille de mémoire de l’instance configurée :
| Taille de l’instance (Mo) | Concurrence par défaut* |
|---|---|
| 512 | 4 |
| 2 048 | 16 |
| 4 096 | 32 |
*Dans les applications Python, toutes les tailles d’instance utilisent un niveau d’accès concurrentiel de déclencheur HTTP d’un par défaut.
Ces valeurs par défaut doivent fonctionner correctement pour la plupart des cas, et vous pouvez commencer par les utiliser. N’oubliez pas qu’à un nombre donné de requêtes HTTP, l’augmentation de la valeur de concurrence HTTP réduit le nombre d’instances requises pour gérer les requêtes HTTP. De même, la diminution de la valeur de concurrence HTTP nécessite davantage d’instances pour gérer la même charge.
Si vous devez affiner la concurrence HTTP, vous pouvez le faire à l’aide d’Azure CLI. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Définir les limites de concurrence HTTP.
Les valeurs par défaut de concurrence dans le tableau précédent s'appliquent uniquement lorsque vous ne définissez pas votre propre paramètre de concurrence de HTTP. Lorsque vous ne définissez pas explicitement de paramètre d’accès concurrentiel HTTP, la concurrence par défaut augmente comme indiqué dans la table lorsque vous modifiez la taille de l’instance. Une fois que vous avez défini spécifiquement une valeur de concurrence HTTP, cette valeur est conservée malgré les modifications du paramètre de la taille d’instance.
Déterminer l'optimale concurrence fixe par instance
Les configurations d’accès concurrentiel par instance fixes vous permettent de contrôler certains comportements de déclencheur, tels que la limitation de vos fonctions. Mais il peut être difficile de déterminer les valeurs optimales pour ces paramètres. En règle générale, vous devez obtenir des valeurs acceptables par un processus itératif de test de charge. Même après avoir déterminé un ensemble de valeurs qui fonctionnent pour un profil de charge particulier, le nombre d’événements qui arrivent de vos services connectés peut changer de jour en jour. Cette variabilité peut entraîner l’exécution de votre application avec des valeurs non optimales. Par exemple, votre application de fonction peut traiter des charges utiles de message exigeantes le dernier jour de la semaine, ce qui vous oblige à limiter la concurrence. Toutefois, pendant le reste de la semaine, les charges utiles des messages peuvent être plus légères, ce qui signifie que vous pouvez utiliser un niveau de concurrence plus élevé.
Dans l’idéal, le système devrait permettre aux instances de traiter autant de travail que possible tout en gardant chaque instance performante et en maintenant de faibles latences. La concurrence dynamique est conçue à cet effet.
Concurrence dynamique
Functions fournit un modèle de concurrence dynamique qui simplifie la configuration de la concurrence pour toutes les applications de fonction qui s’exécutent dans le même plan.
Remarque
La concurrence dynamique est actuellement prise en charge uniquement pour les déclencheurs Stockage Blob Azure, Stockage File d’attente Azure et Service Bus. Vous devez également utiliser les versions d’extension répertoriées dans la prise en charge de l’extension, plus loin dans cet article.
Avantages
La concurrence dynamique offre les avantages suivants :
- Configuration simplifiée : vous n’avez plus besoin de déterminer manuellement les paramètres de concurrence par déclenchement. Le système apprend les valeurs optimales pour votre charge de travail au fil du temps.
- Ajustements dynamiques : l’accès concurrentiel est ajusté dynamiquement en temps réel, ce qui permet au système de s’adapter à la modification des modèles de charge dans le temps.
- Protection de l’intégrité de l’instance : le runtime limite la concurrence aux niveaux qu’une instance d’application de fonction peut gérer confortablement. Ces limites protègent l'application contre la surcharge en évitant de prendre plus de travail que nécessaire.
- Débit amélioré : le débit global est amélioré, car les instances individuelles n’extrayent pas plus de travail qu’elles ne peuvent rapidement traiter. Par conséquent, le travail est réparti de manière équilibrée et efficace entre les instances. Pour les fonctions qui peuvent gérer des charges plus élevées, vous pouvez obtenir un débit plus élevé en augmentant la concurrence pour les valeurs au-dessus de la configuration par défaut.
Configuration de la concurrence dynamique
Vous pouvez activer la concurrence dynamique au niveau de l’hôte dans le fichier host.json . Lorsqu’elle est activée, les niveaux d’accès concurrentiel de toutes les extensions de liaison qui prennent en charge cette fonctionnalité sont ajustés automatiquement en fonction des besoins. Dans ces cas, les paramètres de concurrence dynamique remplacent tous les paramètres de concurrence configurés manuellement.
Par défaut, la concurrence dynamique est désactivée. Lorsque vous activez la concurrence dynamique, la concurrence commence à un niveau d’une pour chaque fonction. Le niveau d’accès concurrentiel est ajusté jusqu’à une valeur optimale, que l’hôte détermine.
Vous pouvez activer la concurrence dynamique dans votre application de fonction en ajoutant les paramètres suivants à votre fichier host.json :
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
Quand snapshotPersistenceEnabled est true, qui est la valeur par défaut, les valeurs de simultanéité apprises sont régulièrement enregistrées dans le stockage. De nouvelles instances commencent à partir de ces valeurs au lieu de partir d’un niveau initial et de devoir recommencer l’apprentissage.
Gestionnaire d’accès concurrentiel
En arrière-plan, lorsque la concurrence dynamique est activée, un processus de gestionnaire de concurrence s’exécute. Ce gestionnaire surveille en permanence les mesures d’intégrité de l’instance, comme l’utilisation du processeur et des threads, et modifie les limitations en fonction des besoins. Quand une ou plusieurs limitations sont activées, la concurrence des fonctions est ajustée jusqu’à ce que l’hôte soit de nouveau sain. Lorsque les limitations sont désactivées, la concurrence peut augmenter. Diverses méthodes heuristiques sont utilisées pour ajuster intelligemment la concurrence en fonction des besoins selon ces limitations. Au fil du temps, la concurrence pour chaque fonction se stabilise à un niveau particulier. Étant donné qu’il peut prendre du temps pour déterminer la valeur d’accès concurrentiel optimale, utilisez la concurrence dynamique uniquement si une valeur non optimale est acceptable pour votre solution initialement ou après une période d’inactivité.
Les niveaux de concurrence sont gérés pour chaque fonction individuelle. Plus précisément, le système équilibre entre les fonctions gourmandes en ressources qui nécessitent un faible niveau d’accès concurrentiel et des fonctions plus légères qui peuvent gérer une concurrence plus élevée. L’équilibre de la concurrence pour chaque fonction permet de maintenir la santé globale de l’instance de l’application fonctionnelle.
Lorsque la concurrence dynamique est activée, vous trouvez des décisions de concurrence dynamique dans vos journaux d’activité. Par exemple, les entrées de journal sont ajoutées lorsque différents limiteurs sont activés, et chaque fois que le parallélisme est augmenté ou diminué pour chaque fonction. Ces logs sont écrits sous la catégorie de log Host.Concurrency dans la table traces.
Extensions prises en charge
La concurrence dynamique est activée pour une application de fonction au niveau de l’hôte, et toutes les extensions qui prennent en charge la concurrence dynamique s’exécutent dans ce mode. La concurrence dynamique nécessite une collaboration entre l’hôte et les extensions de déclencheur individuelles. Seules les versions listées des extensions suivantes prennent en charge la concurrence dynamique.
| Extension | Version | Description |
|---|---|---|
| Stockage de files d’attente | Version 5.x (extension de stockage) | Le déclencheur Stockage File d’attente possède sa propre boucle d’interrogation des messages. Lorsque vous utilisez une configuration fixe par instance, les options de configuration BatchSize et NewBatchThreshold régissent la concurrence. Lorsque vous utilisez la concurrence dynamique, ces valeurs de configuration sont ignorées. La concurrence dynamique est intégrée à la boucle de message. Par conséquent, le nombre de messages récupérés par itération est ajusté dynamiquement. Lorsque les contrôles de débit sont activés, l’hôte est surchargé. Le traitement des messages est suspendu jusqu’à ce que les contrôleurs de débit soient désactivés. Lorsque les limitations sont désactivées, la concurrence augmente. |
| Stockage Blob | Version 5.x (extension de stockage) | En interne, le déclencheur Stockage Blob utilise la même infrastructure que le déclencheur Stockage File d’attente. Lorsque des objets blob nouveaux ou mis à jour doivent être traités, les messages sont écrits dans une file d’attente de contrôle gérée par la plateforme. Cette file d’attente est traitée avec la même logique que celle utilisée pour le déclencheur de stockage de file d’attente. Lorsque la concurrence dynamique est activée, la concurrence pour le traitement de cette file d’attente de contrôle est gérée dynamiquement. |
| Service Bus | Version 5.x | Le déclencheur Service Bus prend actuellement en charge trois modèles d’exécution. La concurrence dynamique affecte ces modèles d’exécution de la manière suivante :MaxConcurrentCalls régit la concurrence. Lorsque vous utilisez la concurrence dynamique, cette valeur de configuration est ignorée et la concurrence est ajustée dynamiquement.MaxConcurrentSessions régissent la concurrence. Lorsque la concurrence dynamique est activée, la MaxConcurrentSessions valeur est ignorée et le nombre de sessions que chaque instance traite est ajusté dynamiquement.MaxMessageCount paramètre. Étant donné que les appels par lots sont en série, la concurrence pour votre fonction déclenchée par lot est toujours une, et la concurrence dynamique ne s’applique pas. |
Étapes suivantes
Pour plus d’informations, consultez les ressources suivantes :