Mise à l’échelle basée sur les événements dans Azure Functions
Dans les plans Consommation et Premium, Azure Functions met à l’échelle les ressources de processeur et de mémoire en ajoutant des instances supplémentaires de l’hôte Functions. Le nombre d’instances est déterminé par le nombre d’événements qui déclenchent une fonction.
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 constitue l’intégralité de la Function App, ce qui signifie que toutes les fonctions dans une Function App partagent des ressources au sein d’une instance et sont mises à l’échelle simultanément. Les applications de fonction qui partagent le même plan Consommation sont mises à l’échelle indépendamment. Dans le plan Premium, la taille de votre plan détermine la mémoire et l’UC disponibles pour toutes les applications de ce plan, sur cette instance.
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
Une fois que votre application de fonction a été inactive pendant quelques minutes, la plateforme peut effectuer un scale-down à zéro du 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 ont un impact sur vos fonctions, envisagez l’exécution dans un plan Premium ou dans un plan dédié 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. Une seule instance, par contre, peut traiter plusieurs messages ou requêtes à la fois, ainsi il n’y a pas de limite définie sur le nombre d’exécutions simultanées. 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 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 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.
Limiter le scale-out
Vous souhaiterez peut-être limiter le nombre maximal d’instances utilisées 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é. Par défaut, les fonctions du plan Consommation effectuent un scale-out jusqu’à 200 instances, et les fonctions du plan Premium jusqu’à 100 instances. Vous pouvez spécifier une valeur maximale inférieure pour une application spécifique en modifiant la valeur 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. Cela se fait en drainant les instances de leurs exécutions de fonction actuelles, puis en supprimant ces instances. Ce comportement est enregistré en mode maintenance. La période de grâce pour les 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 de plan 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 de fonction du plan Consommation s’exécutant sur Windows, 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.
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).
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.
Modèle de facturation
La facturation des différents plans est décrite en détail dans la page Tarification d’Azure Functions. L’utilisation est agrégée au niveau de l’application de fonction et compte uniquement la durée d’exécution du code de fonction. Les unités de facturation sont les suivantes :
- Consommation des ressources en gigaoctet/seconde (Go/s) . Calcul effectué d’après une combinaison de la taille de la mémoire et de la durée d’exécution pour toutes les fonctions d’une application de fonction.
- Exécutions. Comptées chaque fois qu’une fonction est exécutée en réponse à un déclencheur d’événements.
Vous trouverez des requêtes et des informations utiles pour vous aider à comprendre votre facture de consommation dans la FAQ sur la facturation.
Étapes suivantes
Pour en savoir plus, consultez les articles suivants :