Mise à l’échelle basée sur les événements dans Azure Functions
Dans les plans Consommation, Consommation flexible et Premium, Azure Functions met à l’échelle les ressources en ajoutant d’autres instances en fonction du nombre d’événements qui déclenchent une fonction.
Important
Le plan Consommation flexible est actuellement en préversion.
La façon dont votre application de fonction se met à l’échelle dépend du plan d’hébergement :
Plan Consommation : chaque instance de l’hôte Functions dans le plan Consommation est typiquement limitée à 1,5 Go de mémoire et un seul processeur. Une instance de l’hôte prend en charge l’ensemble de l’application de fonction. Par conséquent, toutes les fonctions d’une ressource de partage d’application de fonction dans une instance sont mises à l’échelle en même temps. Quand les applications de fonction partagent le même plan Consommation, elles sont cependant mises à l’échelle indépendamment.
Plan Consommation flexible : le plan utilise une stratégie de mise à l’échelle déterministe par fonction, où chaque fonction est mise à l’échelle indépendamment, à l’exception des fonctions déclenchées par HTTP, Blob et Durable Functions qui se mettent à l’échelle dans leurs propres groupes. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle par fonction. Ces instances sont ensuite mises à l’échelle en fonction de l’accès concurrentiel de vos requêtes.
Plan Premium : la taille spécifique du plan Premium détermine la mémoire et l’UC disponibles pour toutes les applications de ce plan sur 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.
Les fichiers de code de fonction sont stockés dans des partages Azure Files du compte de stockage principal de la fonction. Lorsque vous supprimez le compte de stockage principal de l’application de fonction, les fichiers de code de fonction sont supprimés et ne peuvent pas être récupérés.
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. Quand les instances de l’application de fonction font l’objet d’une augmentation de taille, d’autres ressources sont allouées pour exécuter plusieurs instances de l’hôte Azure Functions. À l’inverse, quand la demande de calcul est réduite, le contrôleur de mise à l’échelle supprime des instances de l’hôte de fonction. Le nombre d’instances est finalement réduit si aucune fonction n’est exécutée dans une application de fonction.
Démarrage à froid
Si votre application de fonction devient inactive pendant quelques minutes, la plateforme peut mettre à l'échelle jusqu’à zéro le nombre d’instances sur lesquelles votre application s’exécute. La prochaine requête présente la latence supplémentaire de la mise à l’échelle de zéro à un. Cette latence est appelée démarrage à froid. Le nombre de dépendances requises par votre application de fonction peut avoir un impact sur le temps 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, nous vous recommandons d’utiliser un plan autre le plan Consommation. Les autres plans offrent ces stratégies pour atténuer ou éliminer les démarrages à froid :
Plan Premium : prend en charge les instances préchauffées et toujours prêtes, avec un minimum d’une instance.
Plan Consommation flexible : prend en charge un nombre facultatif d’instances toujours prêtes, qui peuvent être définies sur une base de mise à l’échelle par instance.
Plan dédié : le plan lui-même n’est pas mis à l’échelle dynamiquement, mais vous pouvez exécuter votre application en continu avec le paramètre Always On activé.
Présentation des comportements de mise à l’échelle
La mise à l’échelle peut varier en fonction de plusieurs facteurs et la mise à l’échelle des applications s’effectue selon les déclencheurs et le langage sélectionnés. Il est nécessaire de connaître certaines subtilités relatives aux comportements de mise à l’échelle :
- Nombre maximal d’instances : Une application de fonction peut faire l’objet d’un scale-out 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.
- Taux de nouvelles instances : 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 plus, une fois toutes les 30 secondes. La mise à l’échelle est plus rapide lors de l’exécution dans un plan Premium.
- Mise à l’échelle basée sur la cible : la mise à l’échelle basée sur la cible fournit un modèle de mise à l’échelle rapide et intuitif pour les clients. Elle est actuellement 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 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 : avec certaines exceptions notables, les fonctions exécutées dans l’échelle du plan Consommation flexible sur des instances indépendantes. Les exceptions incluent des déclencheurs HTTP et des déclencheurs de stockage d’objets 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, tous les déclencheurs Durable Functions partagent également des instances et sont mis à l’échelle ensemble. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Mise à l’échelle par fonction.
- Nombre maximal de déclencheurs monitorés : actuellement, le contrôleur de mise à l’échelle peut uniquement monitorer jusqu’à 100 déclencheurs pour prendre de mesures de mise à l’échelle. Lorsque votre application a plus de 100 déclencheurs basés sur des événements, les mesures de mise à l’échelle sont prises en fonction uniquement des 100 premiers déclencheurs qui s’exécutent. Pour découvrir plus d’informations, consultez Bonnes pratiques et modèles pour les applications scalables.
Limiter le scale-out
Vous déciderez peut-être de limiter le nombre maximal d’instances utilisables par une application pour effectuer un scale-out. C’est le cas le plus fréquent lorsqu’un composant en aval comme une base de données a un débit limité. Pour connaître les limites d’échelle maximales lors de l’exécution des différents plans d’hébergement, veuillez consulter la rubrique Limites de mise à l’échelle.
Plan Consommation flexible
Par défaut, les applications s’exécutant dans un plan Consommation flexible ont une limite d’instances globales 100. Actuellement, la valeur maximale de nombre d’instances la plus faible est 40, et la valeur maximale de nombre d’instances prise en charge la plus élevée est 1000. Lorsque vous utilisez la commande az functionapp create pour créer une application de fonction dans le plan Consommation flexible, utilisez le paramètre --maximum-instance-count pour définir ce nombre d’instances maximal pour votre application.
Notez que bien que vous puissiez changer le nombre maximal d’instances des applications Consommation flexible pour le passer à 1 000, vos applications atteindront la limite de quota avant de parvenir à ce nombre. Passez en revue Quotas de mémoire régionaux de l’abonnement pour découvrir plus de détails.
Cet exemple crée une application avec un nombre maximal d’instances de 200 :
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <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 modifier le nombre maximal d’instances d’une application existante en 150 :
az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150
Plans Consommation/Premium
Dans un plan Consommation ou Premium élastique, 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>
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. Pour cela, le système vide 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 des fonctions en cours d’exécution peut s’étendre jusqu’à 10 minutes pour les applications du plan Consommation et jusqu’à 60 minutes pour les applications du plan Premium et Consommation Flex. 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 sous Windows dans un plan Consommation, seules les applications créées après mai 2021 ont des comportements de mode maintenance 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
Applicable uniquement au plan Consommation flexible (préversion).
Le plan Consommation flexible est unique dans la mesure où il implémente un comportement de mise à l’échelle par fonction. Lors de la mise à l'échelle par fonction, à l’exception des déclencheurs HTTP, des déclencheurs Blob (Event Grid) et de Durable Functions, 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.
Prenons l’exemple d’une application de fonction hébergeant un plan Consommation flexible qui a les fonctions suivantes :
| fonction1 | fonction2 | fonction3 | fonction4 | fonction5 | fonction6 | fonction7 |
|---|---|---|---|---|---|---|
| Déclencheur HTTP | Déclencheur HTTP | Déclencheur d’orchestration (durable) | Déclencheur d’activité (durable) | Déclencheur Service Bus | Déclencheur Service Bus | Déclencheur Event Hubs |
Dans cet exemple :
- Les deux fonctions déclenchées par HTTP (
function1etfunction2) 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 (
function3etfunction4) s’exécutent ensemble sur leurs propres instances et se mettent à l’échelle ensemble sur la base des limitations de concurrence configurées. - La fonction déclenchée par Service Bus
function5s’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 rubriques Service Bus. - La fonction déclenchée par Service Bus
function6s’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 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
Nombreux sont les aspects d’une application de fonction qui impactent sa mise à l’échelle, notamment la configuration de l’hôte, l’empreinte du runtime 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 a plus de 100 fonctions qui utilisent des déclencheurs basés sur des événements, envisagez de la fractionner en une ou plusieurs applications dans lesquelles chaque application a moins de 100 fonctions basées sur des événements.
Pour plus d’informations sur la mise à l’échelle en Python et Node.js, consultez le Guide des développeurs Python sur Azure Functions - Mise à l’échelle et concurrence et le Guide des développeurs Node.js sur Azure Functions - Mise à l’échelle et concurrence.
Étapes suivantes
Pour en savoir plus, consultez les articles suivants :