Partager via

Hébergement du plan Consommation flexible Azure Functions

  • Article

Consommation Flex est un plan d’hébergement Azure Functions basé sur Linux qui s’appuie sur le modèle de facturation serverless de Consommation paiement à l’utilisation. Le plan fournit davantage de flexibilité et de personnalisation en introduisant la mise en réseau privée, la sélection de la taille de la mémoire de l’instance et les fonctionnalités de scale-out rapides/volumineuses toujours basées sur un modèle serverless.

Important

Le plan Consommation flexible est actuellement en préversion. Pour une liste des limitations actuelles liées à l’utilisation de ce plan d’hébergement, consultez Considérations. Pour plus d’informations sur la facturation pendant la préversion, consultez Facturation.

Vous pouvez consulter des exemples de bout en bout qui présentent le plan Consommation Flex dans le référentiel d’exemples de plans Consommation Flex.

Avantages

Le plan Consommation Flex s’appuie sur les points forts du plan Consommation, qui incluent la mise à l’échelle dynamique et la facturation basée sur l’exécution. Avec le plan Consommation Flex, vous bénéficiez également ces fonctionnalités supplémentaires :

Ce tableau vous aide à comparer directement les fonctionnalités de Consommation Flex avec le plan d’hébergement Consommation :

Fonctionnalité Consommation Plan Consommation
Mettre à l’échelle vers zéro ✅ Oui ✅ Oui
Comportement de mise à l’échelle Basé sur les événements Basé sur les événements (rapide)
Réseaux virtuels ❌ Non pris en charge ✅ Pris en charge
Calcul dédié (atténuer les démarrages à froid) ❌ Aucun ✅Instances toujours prêtes (facultatif)
Billing Durée d’exécution uniquement Durée d’exécution + instances toujours prêtes
Instances de scale-out (max) 200 1 000

Pour une comparaison complète entre le plan Consommation flexible et le plan de Consommation, ainsi que tous les autres types de plans et d’hébergements, consultez Options d’échelle et d’hébergement des fonctions.

Intégration du réseau virtuel

Le plan Consommation Flex développe les avantages traditionnels du plan Consommation en ajoutant la prise en charge pour l’intégration de réseau virtuel. Lorsque vos applications s’exécutent dans un plan Consommation Flex, elles peuvent se connecter à d’autres services Azure sécurisés à l’intérieur d’un réseau virtuel. Par ailleurs, elle vous permet de tirer parti de la facturation et de la mise à l’échelle serverless, ainsi que des avantages de la mise à l’échelle et du débit du plan Consommation Flex. Pour plus d’informations, consultez Activer l’intégration de réseau virtuel.

Mémoire de l'instance

Lorsque vous créez votre application de fonction dans un plan Consommation Flex, vous pouvez sélectionner la taille de mémoire des instances sur lesquelles votre application s’exécute. Consultez Facturation pour savoir comment les tailles de mémoire d’instance affectent les coûts de votre application de fonction.

Actuellement, le plan Consommation Flex offre des options de taille de mémoire d’instance de 2 048 Mo et 4 096 Mo.

Lorsque vous décidez de la taille de mémoire de l’instance à utiliser avec vos applications, voici quelques éléments à prendre en compte :

  • La taille de mémoire de l’instance de 2 048 Mo est la valeur par défaut et il convient de l’utiliser pour la plupart des scénarios. Utilisez la taille de mémoire d’instance de 4 096 Mo pour les scénarios où votre application nécessite une plus grande concurrence ou une puissance de traitement supérieure. Pour plus d’informations, consultez Configurer la mémoire d’instance.
  • Vous pouvez changer la taille de mémoire de l’instance à tout moment. Pour plus d’informations, consultez Configurer la mémoire d’instance.
  • Les ressources d’instance sont partagées entre votre code de fonction et l’hôte Functions.
  • Plus la taille de mémoire de l’instance est grande, plus chaque instance peut gérer jusqu’à des exécutions simultanées ou des charges de travail processeur ou mémoire plus intensives. Les décisions de mise à l'échelle spécifiques dépendent de la charge de travail.
  • La concurrence par défaut des déclencheurs HTTP dépend de la taille de mémoire de l’instance. Pour plus d’informations, consultez Concurrence de déclencheurs HTTP.
  • Les processeurs disponibles et la bande passante réseau sont fournis proportionnellement à une taille d’instance spécifique.

Instances toujours prêtes

Le plan Consommation Flex inclut une fonctionnalité toujours prête qui vous permet de choisir des instances toujours en cours d’exécution et affectées à chacun de vos groupes ou fonctions identiques par fonction. Il s’agit d’une excellente option pour les scénarios où vous devez disposer d’un nombre minimal d’instances toujours prêtes à gérer les requêtes, par exemple pour réduire la latence de démarrage à froid de votre application. La valeur par défaut est 0 (zéro).

Par exemple, si vous définissez toujours la valeur 2 pour votre groupe de fonctions HTTP, la plateforme conserve deux instances toujours en cours d’exécution et attribuées à votre application pour vos fonctions HTTP dans l’application. Ces instances traitent vos exécutions de fonction, mais en fonction des paramètres d’accès concurrentiel, la plateforme met à l’échelle au-delà de ces deux instances avec des instances à la demande.

Pour savoir comment configurer des instances toujours prêtes, consultez Définir le nombre d’instances toujours prêtes.

Mise à l’échelle par fonction

La concurrence est un facteur clé qui détermine la mise à l’échelle des applications de fonction du plan Consommation Flex. Pour améliorer les performances de mise à l’échelle des applications avec différents types de déclencheurs, le plan Consommation Flex offre un moyen plus déterministe de mettre à l’échelle votre application par fonction.

Ce comportement de mise à l’échelle par fonction fait partie de la plateforme d’hébergement. Vous n’avez donc pas besoin de configurer votre application ou de modifier le code. Pour plus d’informations, consultez Mise à l’échelle par fonction dans l’article sur la Mise à l’échelle basée sur les événements.

Dans chaque mise à l’échelle de fonction, HTTP, Blob (Event Grid) et les déclencheurs Durables sont des cas spéciaux. Toutes les fonctions déclenchées par HTTP dans l’application sont regroupées et mises à l’échelle dans les mêmes instances, et toutes les fonctions déclenchées Durables (déclencheurs d’orchestration, d’activité ou d’entité) sont regroupées et mises à l’échelle dans les mêmes instances. Toutes les autres fonctions de l’application sont mises à l’échelle individuellement.

Concurrence

La concurrence fait référence au nombre d’exécutions parallèles d’une fonction sur une instance de votre application. Vous pouvez définir un nombre maximal d’exécutions simultanées que chaque instance doit gérer à tout moment. Pour plus d’informations, consultez Concurrence de déclencheurs HTTP.

La concurrence a un effet direct sur la façon dont votre application est mise à l’échelle, car à des niveaux de concurrence inférieurs, vous avez besoin d’instances supplémentaires pour gérer la demande basée sur les événements pour une fonction. Bien que vous puissiez contrôler et affiner la concurrence, nous fournissons des valeurs par défaut qui fonctionnent pour la plupart des cas. Pour savoir comment définir des limites de concurrence pour les fonctions de déclencheur HTTP, consultez Définir des limites de concurrence HTTP.

Déploiement

Les déploiements dans le plan Consommation flexible suivent un chemin unique. Une fois le code de votre projet généré et compressé dans un package d’application, il est déployé sur un conteneur de stockage d’objets blob. Au démarrage, votre application récupère le package et s’exécute à partir de celui-ci. Par défaut, le même compte de stockage utilisé pour stocker les métadonnées d’hôte interne (AzureWebJobsStorage) est également utilisé comme conteneur de déploiement. Toutefois, vous pouvez utiliser un autre compte de stockage ou choisir votre méthode d’authentification préférée en configurant les paramètres de déploiement de votre application. Pour simplifier le chemin de déploiement, il n’est plus nécessaire que les paramètres d’application influencent le comportement de déploiement.

Billing

Il existe deux modes permettant de déterminer vos coûts lors de l’exécution de vos applications dans le plan Consommation Flex. Chaque mode est déterminé par instance.

Mode de facturation Description
À la demande Lors de l’exécution en mode à la demande, vous êtes facturé uniquement pour la durée pendant laquelle votre code de fonction s’exécute sur vos instances disponibles. En mode demande, aucun nombre minimal d’instances n’est requis. Vous êtes facturé pour :

• La quantité totale de mémoire approvisionnée alors que chaque instance à la demande exécute activement des fonctions en cours d’exécution (en Go-secondes), moins un octroi gratuit de Go-s par mois.
• Le nombre total d’exécutions, moins un octroi gratuit (nombre) d’exécutions par mois.
Toujours prêtes Vous pouvez configurer une ou plusieurs instances, affectées à des types de déclencheurs spécifiques (HTTP/Durable/Blob) et à des fonctions individuelles, qui sont toujours disponibles pour être en mesure de gérer les requêtes. Lorsque des instances toujours prêtes sont activées, vous êtes facturé pour :

• La quantité totale de mémoire approvisionnée sur toutes vos instances toujours prêtes, appelée ligne de base (en Go-secondes).
• La quantité totale de mémoire approvisionnée pendant la période où chaque instance toujours prête exécute activement des fonctions (en Go-secondes).
• Le nombre total d'exécutions.

Dans la facturation toujours prête, il n’y a pas d’octrois gratuits.

La période d’exécution facturable minimale pour les deux modes d’exécution est de 1 000 ms. Au-delà, la période d’activité facturable est arrondie à la plus proche de 100 ms. Vous trouverez des informations détaillées sur les compteurs de facturation du plan Consommation Flex dans la Référence de surveillance.

Pour plus d’informations sur la façon dont les coûts sont calculés lorsque vous exécutez dans un plan Consommation Flex, y compris des exemples, consultez coûts basés sur la consommation.

Pour obtenir les informations les plus à jour sur la tarification de l’exécution, les coûts de base toujours prêts et les octrois gratuits pour les exécutions à la demande, consultez la page de tarification Azure Functions.

Versions de piles de langage prises en charge

Ce tableau présente les versions de la pile de langage actuellement prises en charge pour les applications Consommation Flex :

Pile de langages Version obligatoire
C# (modèle de processus isolé)1 .NET 82
Java Java 11, Java 17
Node.JS Node 20
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11

1Le mode C# in-process n’est pas pris en charge. Vous devez plutôt migrer votre projet de code .NET pour qu’il s’exécute dans le modèle de worker isolé.
2Nécessite une version 1.20.0 ou ultérieure de microsoft.Azure.Functions.Worker et une version 1.16.2 ou ultérieure de Microsoft.Azure.Functions.Worker.Sdk.

Quotas de mémoire régionaux de l’abonnement

Actuellement, chaque région d’un abonnement donné a une limite de mémoire de 512 000 Mo pour toutes les instances d’applications s’exécutant sur des plans Consommation Flex dans cette région. Cela signifie que dans un abonnement et une région donnés, vous pouvez avoir l’une des combinaisons suivantes de tailles et de nombres d’instances maximales, qui atteignent toutes la limite actuelle de 512 000 Mo :

Taille de mémoire de l'instance (Mo) Nombres d’instances maximales (par région)
2048 MB 250
4096 MB 125

Vous pouvez avoir toute autre combinaison de tailles de mémoire d’instance et de nombres dans une région donnée, tant qu’elles restent sous la limite de 512 000 Mo. Si vos applications nécessitent un quota plus important, vous pouvez créer un ticket de support pour demander une augmentation de quota.

Propriétés et paramètres déconseillés

Dans la Consommation Flex, de nombreux paramètres d’application standard et propriétés de configuration de site utilisés dans Bicep, les modèles ARM et le plan de contrôle global sont déconseillés ou ont été déplacés et ne doivent pas être utilisés lors de l’automatisation de la création de ressources d’application de fonction. Pour plus d’informations, consultez Dépréciations du plan Consommation Flex.

À propos de l’installation

Gardez à l’esprit ces autres considérations lors de l’utilisation du plan Consommation Flex pendant la préversion actuelle :

  • Déclencheurs: tous les déclencheurs sont entièrement pris en charge, à l’exception des déclencheurs Kafka, Azure SQL et SignalR. Le déclencheur de stockage Blob prend uniquement en charge la source Event Grid. Les applications de fonction non C# doivent utiliser la version [4.0.0, 5.0.0) du pack d’extensions ou une version ultérieure.
  • Régions : toutes les régions ne sont pas prises en charge actuellement. Pour en savoir plus, consultez Afficher les régions actuellement prises en charge.
  • Déploiements : Ces fonctionnalités liées au déploiement ne sont pas prises en charge actuellement :
    • Emplacements de déploiement
    • Déploiement continu avec Azure DevOps Tasks (AzureFunctionApp@2)
    • Déploiement continu avec GitHub Actions (functions-action@v1)
  • Mise à l’échelle: la plus faible échelle maximale en préversion est 40. La valeur la plus élevée actuellement prise en charge est 1000.
  • Autorisation : EasyAuth n’est pas pris en charge actuellement. Actuellement, les appelants non authentifiés ne sont pas bloqués lorsque EasyAuth est activé dans une application de plan Flex Consumption.

Options d’hébergement Azure FunctionsCréer et gérer des applications de fonction dans le plan Consumption Flex