Mise à l’échelle basée sur les événements dans Azure Functions

La mise à l’échelle événementielle ne s’applique pas au plan dédié (App Service). Le forfait dédié ne s’adapte pas dynamiquement aux événements. Pour les options de montée en échelle dans le forfait dédié, voir Scale up an app dans Azure App Service.

La mise à l'échelle pilotée par événements ne s'applique pas lors de l'exécution de fonctions sur Azure Container Apps. Lorsqu’il est hébergé sur des applications conteneur, l’échelle est gérée par l’environnement des applications conteneures. Pour plus d’informations, consultez Définir des règles de mise à l’échelle dans Azure Container Apps.

Mise à l’échelle du runtime

Azure Functions utilise un composant appelé contrôleur de mise à l’échelle pour surveiller la fréquence des événements et déterminer s’il convient d’effectuer un scale-out ou un scale-in. Le contrôleur de mise à l’échelle utilise une méthode heuristique pour chaque type de déclencheur. Par exemple, lorsque vous utilisez un déclencheur de stockage File d’attente Azure, il utilise la mise à l’échelle basée sur la cible.

L’unité d’échelle pour Azure Functions est la Function App. Lorsque l’application de fonctions évolue, elle alloue plus de ressources pour exécuter plusieurs instances de l’hôte Azure Functions. Inversement, à mesure que la demande de calcul diminue, le contrôleur d’échelle supprime les instances hôtes de fonction. Le nombre d’instances est finalement réduit si aucune fonction n’est exécutée dans une application de fonction.

Chaque instance de l’hôte Fonctions dans le plan Consommation est limitée, généralement à 1,5 Go de mémoire et un CPU. Une instance de l’hôte prend en charge l’ensemble de l’application de fonctions, donc toutes les fonctions d’une application partagent les ressources et évoluent simultanément. Lorsque les applications fonctionnelles partagent le même forfait Consommation, elles évoluent toujours indépendamment.

La taille spécifique du forfait Premium détermine la mémoire et le CPU disponibles pour toutes les applications de ce forfait dans cette instance. Le plan effectue un scale-out de ses instances en fonction des besoins de mise à l’échelle des applications dans le plan et les applications se mettent à l’échelle au sein du plan en fonction des besoins.

Contrairement aux autres plans dynamiques, le plan Flex Consumption utilise un modèle déterministe d’échelle par fonction. Dans ce modèle, chaque fonction est mise à l’échelle indépendamment en fonction du nombre d’événements et des paramètres de concurrence, sauf pour les fonctions déclenchées par HTTP, Blob et orchestration (durable) qui évoluent dans leurs propres groupes. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle par fonction.

La plateforme gère le taux auquel elle ajoute des instances (la courbe d’échelle), indépendamment du nombre maximal d’instances. Pour plus d’informations sur le fonctionnement de la courbe d’échelle, le comportement de limitation et les bonnes pratiques pour l’échelle à taux élevé, voir Taux d’échelle.

Démarrage à froid

Si votre application de fonctions reste inactive quelques minutes, la plateforme peut réduire à zéro le nombre d’instances exécutant votre application. La requête suivante subit la latence supplémentaire de l’échelle de zéro à un. Cette latence est appelée démarrage à froid. Le nombre de dépendances requises par votre application de fonctions peut influencer l’heure de démarrage à froid. Le démarrage à froid est plus problématique pour les opérations synchrones, telles que les déclencheurs HTTP, qui doivent retourner une réponse. Si les démarrages à froid affectent vos fonctions, envisagez d’utiliser un plan qui soutient des stratégies d’atténuation :

Comme vous pouvez le voir dans ce tableau, les forfaits Flex Consumption et Premium offrent tous deux des moyens d’éliminer les démarrages à froid dans vos applications.

Présentation des comportements de mise à l’échelle

La mise à l’échelle peut varier en fonction de plusieurs facteurs. Les applications évoluent différemment selon les déclencheurs et la langue choisie. Soyez conscient de ces subtilités des comportements d’échelle :

• Nombre maximal de cas : Une application à fonction unique s’étend jusqu’au maximum autorisé par le plan. Toutefois, une seule instance peut traiter plusieurs messages ou requêtes à la fois. Vous pouvez spécifier une valeur maximale inférieure pour limiter l’échelle en fonction des besoins.

• Nouveau taux d’instance : Pour les déclencheurs HTTP, la plateforme alloue de nouvelles instances au maximum une fois par seconde. Pour les déclencheurs non HTTP, la plateforme alloue de nouvelles instances au maximum toutes les 30 secondes. La mise à l’échelle est plus rapide lors de l’exécution dans plan Premium.

• 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. Actuellement, cette méthode de mise à l’échelle est prise en charge pour les files d’attente et rubriques Service Bus, les files d’attente de stockage, Event Hubs, Apache Kafka et les extensions Azure Cosmos DB. Veillez à passer en revue la mise à l’échelle basée sur la cible pour comprendre leur comportement de mise à l’échelle.

• Mise à l’échelle par fonction : à quelques exceptions notables près, les fonctions exécutées dans le cadre du plan Consommation flexible sont mises à l’échelle sur des instances indépendantes. Les exceptions incluent des déclencheurs HTTP et des déclencheurs de stockage Blob (Event Grid). Chacun de ces types de déclencheurs est mis à l’échelle en tant que groupe sur les mêmes instances. De même, les déclencheurs de toutes les fonctions durables partagent des instances et se mettent à l’échelle ensemble. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle par fonction.

• Déclencheurs surveillés au maximum : Actuellement, le contrôleur de balance ne peut surveiller que jusqu’à 100 déclenchements pour prendre des décisions de mise à l’échelle. Lorsque votre application compte plus de 100 déclencheurs basés sur des événements, les décisions d’échelle se basent uniquement sur les 100 premiers déclencheurs qui s’exécutent. Pour en savoir plus, consultez Bonnes pratiques et modèles pour les applications scalables.

Limiter le scale-out

Vous pouvez décider de restreindre le nombre maximal d’instances qu’une application peut utiliser pour effectuer un scale-out. Cette limitation est la plus courante pour les cas où un composant en aval comme une base de données a un débit limité. Pour connaître les limites de mise à l’échelle maximales lors de l’exécution des plusieurs plans d’hébergement, consultez Limites de mise à l’échelle.

Par défaut, les applications qui s’exécutent dans le cadre d’un plan Consommation flexible ont une limite d’instances globales de 100. Actuellement, la valeur maximale la plus basse pour le nombre d’instances est 1 et la valeur maximale la plus élevée prise en charge est 1000. Lorsque vous utilisez la commande az functionapp create pour créer une application de fonction dans le cadre du plan Consommation flexible, utilisez le paramètre --maximum-instance-count pour définir ce nombre d’instances maximum pour votre application.

Le nombre maximal d’instances s’applique aux instances à la demande dans chaque groupe d’échelle par fonction (groupe de fonctions) plutôt qu’aux instances combinées de l’application. Les instances toujours prêtes ne sont pas limitées par le nombre maximal d’instances et ne comptent pas pour celui-ci.

Bien que vous puissiez modifier le nombre maximal d’instances des applications Flex Consumption jusqu’à 1 000, la limite de quota pour vos applications est atteinte avant d’atteindre ce nombre. Consultez Quotas de mémoire régionaux de l’abonnement pour en savoir plus.

Cet exemple montre comment créer une application avec un nombre maximal de 200 instances :

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

Cet exemple utilise la commande az functionapp scale config set pour faire passer le nombre maximal d’instances d’une application existante à 150 :

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

Dans un plan Consommation ou Elastic Premium, vous pouvez spécifier une limite maximale inférieure pour votre application en modifiant la valeur du paramètre de configuration de site functionAppScaleLimit. Le functionAppScaleLimit peut être défini sur 0 ou sur null pour une utilisation sans restriction, ou sur une valeur valide comprise entre 1 et le maximum de l’application.

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

Taux d’échelle

Dans le plan Flex Consumption, la plateforme gère également le taux auquel elle ajoute des instances (la courbe d’échelle), indépendamment du nombre maximal d’instances. Pour le fonctionnement de la courbe d’échelle, le comportement de limitation et les meilleures pratiques pour une mise à l’échelle à haut débit, voir Taux d’échelle.

Taux d’échelle

Dans les forfaits Consommation et Premium, le contrôleur de balance gère le taux auquel de nouvelles instances sont ajoutées. Pour les déclencheurs HTTP, de nouvelles instances sont allouées, au plus, une fois par seconde. Pour les déclencheurs non HTTP, de nouvelles instances sont allouées au maximum toutes les 30 secondes. La mise à l’échelle est plus rapide lors de l’exécution dans plan Premium.

Comportements de scale-in

La mise à l’échelle pilotée par les événements réduit automatiquement la capacité lorsque la demande de vos fonctions est réduite. Il effectue cette réduction en vidant les instances de leurs exécutions de fonction actuelles, puis supprime ces instances. Ce comportement est enregistré en mode maintenance. La période de grâce pour les fonctions en cours d’exécution peut aller jusqu’à 10 minutes pour les applications du plan Consommation et jusqu’à 60 minutes pour les applications des plans Consommation flexible et Premium. La mise à l’échelle pilotée par les événements et ce comportement ne s’appliquent pas aux applications de plan dédié.

Les considérations suivantes s’appliquent aux comportements de scale-in :

• Pour les applications s’exécutant sur Windows dans un plan Consommation, seules les applications créées après mai 2021 ont des comportements de mode drain activés par défaut.
• Pour activer l’arrêt normal pour les fonctions à l’aide du déclencheur Service Bus, utilisez la version 4.2.0 ou une version ultérieure de l’extension Service Bus.

Mise à l’échelle par fonction

Le plan Consommation flexible est unique dans la mesure où il implémente un comportement de mise à l’échelle par fonction. Dans le cadre de la mise à l’échelle par fonction, à l’exception des déclencheurs HTTP, des déclencheurs Blob (Event Grid) et des fonctions durables, tous les autres types de déclencheurs de fonction de votre application sont mis à l’échelle sur des instances indépendantes. Les déclencheurs HTTP de votre application sont tous mis à l’échelle ensemble en tant que groupe sur les mêmes instances, comme tous les déclencheurs Blob (Event Grid) et tous les déclencheurs Durable Functions, qui ont leurs propres instances partagées.

Considérez une application de fonction hébergée par un plan Flex Consumption qui a les fonctions suivantes :

Dans cet exemple :

• Les deux fonctions déclenchées par HTTP (function1 et function2) s’exécutent ensemble sur leurs propres instances et se mettent à l’échelle ensemble en fonction des paramètres de concurrence HTTP.
• Les deux fonctions Durables (function3 et function4) s’exécutent ensemble sur leurs propres instances et se mettent à l’échelle ensemble en fonction des limites de concurrence configurées.
• La fonction function5 déclenchée par Service Bus s’exécute de manière autonome et est mise à l’échelle indépendamment en fonction des règles de mise à l’échelle basées sur la cible pour les files d’attente et les rubriques Service Bus.
• La fonction function6 déclenchée par Service Bus s’exécute de manière autonome et est mise à l’échelle indépendamment en fonction des règles de mise à l’échelle basées sur la cible pour les files d’attente et les rubriques Service Bus.
• Le déclencheur Event Hubs (function7) s’exécute dans ses propres instances et est mis à l’échelle indépendamment en fonction des règles de mise à l’échelle basées sur la cible pour Event Hubs.

Bonnes pratiques et modèles pour les applications scalables

De nombreux aspects d’une application de fonctions influencent son évolutivité, notamment la configuration de l’hôte, l’empreinte à l’exécution et l’efficacité des ressources. Pour plus d’informations, consultez la section sur l’extensibilité dans l’article Considérations relatives aux performances. Vous devez également savoir ce qu’il se passe au niveau des connexions lors de la mise à l’échelle de votre application de fonction. Pour plus d’informations, consultez How to manage connections in Azure Functions (Comment gérer des connexions dans Azure Functions).

Si votre application compte plus de 100 fonctions utilisant des déclencheurs basés sur des événements, envisagez de diviser l’application en une ou plusieurs applications, chaque application ayant moins de 100 fonctions basées sur des événements.

Pour plus d’informations sur la mise à l’échelle dans Python et Node.js, consultez la section Mise à l’échelle et performances du guide du développeur Python Azure Functions et de la section Mise à l’échelle et concurrence du guide du développeur azure Functions Node.js.