Partager via

Hébergement du plan Consommation flexible Azure Functions

Consommation flexible est un plan d’hébergement Azure Functions basé sur Linux qui s’appuie sur le modèle de facturation serverless de consommation avec paiement à l’utilisation. Il vous offre 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 des fonctionnalités d'extension rapide et à grande échelle, toujours basées sur un modèle serverless.

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

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)
Facturation Durée d’exécution uniquement Durée d’exécution + instances toujours prêtes
Instances de scale-out (max) 200 1 000

Pour obtenir une comparaison complète du plan Flex Consumption par rapport au plan Consommation et à tous les autres types de plan et d’hébergement, consultez les options d’hébergement et d’échelle de fonction.

Intégration du réseau virtuel

Flex Consumption s’étend sur les avantages traditionnels du plan Consommation en ajoutant la prise en charge de 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, Flex Consumption offre ces options de taille de mémoire d’instance : 512 Mo, 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. Les tailles de mémoire d’instance de 512 Mo et de 4 096 Mo sont disponibles pour les scénarios qui conviennent le mieux aux exigences de concurrence ou de traitement de votre application. Pour plus d’informations, consultez Configurer la mémoire de l’instance.
  • Vous pouvez changer la taille de mémoire de l’instance à tout moment. Pour plus d’informations, consultez Configurer la mémoire de l’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 la concurrence du déclencheur HTTP.
  • Les processeurs disponibles et la bande passante réseau sont fournis proportionnellement à une taille d’instance spécifique.

Mise à l’échelle par fonction

La concurrence est un facteur clé qui détermine la mise à l’échelle des applications de fonction Flex Consumption. 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 la mise à l’échelle par fonction dans l’article sur la mise à l’échelle pilotée par les événements.

Dans la mise à l’échelle par fonction, les décisions sont prises pour certains déclencheurs de fonction selon les agrégations de groupe. Ce tableau montre le jeu défini de groupes de mise à l’échelle de fonction :

Groupes de mise à l’échelle Déclencheurs dans le groupe Valeur des paramètres
Déclencheurs HTTP Déclencheur HTTP
Déclencheur SignalR		 http
Déclencheurs de Stockage Blob
(basés sur Event Grid)		 Déclencheur de stockage Blob blob
Fonctions durables Déclencheur d’orchestration
Déclencheur d’activité
Déclencheur d’entité		 durable

Toutes les autres fonctions de l’application sont mises à l’échelle individuellement dans leur propre ensemble d’instances, qui sont référencées selon la convention function:<NAMED_FUNCTION>.

Instances toujours prêtes

Consommation flexible inclut une fonctionnalité toujours prêtes qui vous permet de choisir des instances toujours en cours d’exécution et qui sont affectées à chacun de vos groupes de mise à l’échelle ou fonctions par fonction. Toujours prêt est une excellente option pour les scénarios où vous avez besoin d’un nombre minimal d’instances toujours prêtes pour gérer les demandes. 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.

Pas moins de deux instances toujours prêtes peuvent être configurées par fonction ou groupe de fonctions pendant que la redondance de zone est activée.

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

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. 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. Pour savoir comment définir des limites d’accès concurrentiel pour les fonctions de déclencheur non HTTP, consultez La mise à l’échelle de base cible.

Déploiement

Les déploiements dans le plan Consommation flexible suivent un seul chemin et les paramètres d’application n’ont plus besoin d’influencer le comportement du déploiement. 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 blob. Au démarrage, votre application obtient le package et exécute votre code de fonction à partir de ce package. 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.

Facturation

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 Descriptif
À la demande Lors de l’exécution en mode à la demande , vous êtes facturé uniquement pendant 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 :

• Quantité totale de mémoire provisionnée alors que chaque instance à la demande exécute activement des fonctions (en Go-secondes), moins une allocation gratuite de Go-s par mois.
• Le nombre total d’exécutions, moins un octroi gratuit (nombre) d’exécutions par mois.
Toujours prêt 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 gérer les requêtes. Lorsque des instances toujours prêtes sont activées, vous êtes facturé pour :

• Quantité totale de mémoire provisionnée sur toutes vos instances toujours prêtes, appelée base de référence (en Go-secondes).
• Quantité totale de mémoire provisionnée pendant le temps où chaque instance toujours prête est en cours d’exécution active (en Go-secondes).
• Le nombre total d'exécutions.

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

Pour obtenir les informations les plus récentes sur la tarification de l’exécution, les coûts de référence de « toujours prêtes » et les octrois gratuits pour les exécutions à la demande, consultez la page de tarification d’Azure Functions.

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 détails sur les compteurs de facturation du plan Flex Consumption 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 un plan Flex Consumption, y compris des exemples, consultez les coûts basés sur la consommation.

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# (mode processus isolé)1 .NET 82, .NET 93
Java Java 11, Java 17, Java 21
Node.JS Node.js 20, Node.js 22
PowerShell PowerShell 7.4
Python Python 3.10, Python 3.11, Python 3.12
  1. Le mode in-process C# 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 worker isolé.
  2. Nécessite une version 1.20.0 ou une version ultérieure de Microsoft.Azure.Functions.Worker et une version 1.16.2 ultérieure de Microsoft.Azure.Functions.Worker.Sdk.
  3. Nécessite la version 2.0.0 ou une version plus récente de Microsoft.Azure.Functions.Worker et 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 MB pour toutes les instances d’applications s’exécutant sur des plans Consommation Flex. Ce quota signifie que, dans un abonnement et une région donnés, vous pouvez avoir n’importe quelle combinaison de tailles de mémoire et de nombres d’instances, tant qu’elles restent en dessous de la limite du quota. Par exemple, chacun des exemples suivants signifie que le quota a été atteint et que les applications cessent de se mettre à l’échelle :

  • Vous avez une application de 512 Mo mise à l’échelle vers 250 instances et une deuxième application de 512 Mo mise à l’échelle vers 750 instances.
  • Vous avez une application de 512 Mo mise à l’échelle vers 1 000 instances.
  • Vous avez une application de 2 048 Mo mise à l’échelle à 100 instances et une deuxième application de 2 048 Mo mise à l’échelle à 150 instances
  • Vous avez une application de 2 048 Mo qui a été mise à l’échelle à 250 instances
  • Vous avez une application de 4 096 Mo qui a été mise à l’échelle à 125 instances
  • Vous avez une application de 4 096 Mo mise à l’échelle à 100 instances et une application de 2 048 Mo mise à l’échelle vers 50 instances

Les applications Consommation flexible mises à l’échelle à zéro, ou les instances marquées pour être mises à l’échelle et supprimées, ne sont pas comptabilisées dans le quota. Ce quota peut être augmenté pour permettre à vos applications Consommation flexible de continuer à se mettre à l’échelle, en fonction de vos besoins. Si vos applications nécessitent un quota plus important, créez un ticket de support.

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

Dans le plan Consommation flexible, de nombreux paramètres d’application et propriétés de configuration de site standard sont dépréciés ou ont été déplacés et ne doivent pas être utilisés pour l’automatisation de la création de ressources d’application de fonction. Pour plus d’informations, consultez Dépréciations du plan Consommation flexible.

À propos de l’installation

Gardez à l’esprit ces autres considérations lors de l’utilisation du plan Consommation Flex :

  • Applications par plan : une seule application est autorisée par plan Flex Consumption.
  • Hôte : Il existe un délai d’attente de 30 secondes pour l’initialisation des applications. Lorsque votre application de fonction prend plus de 30 secondes pour démarrer, vous pouvez voir les entrées System.TimeoutException liées à gRPC journalisées. Actuellement, vous ne pouvez pas configurer ce délai d’expiration. Pour plus d’informations, consultez cet élément de travail hôte.
  • Durable Functions : Le stockage Azure est actuellement le seul fournisseur de stockage pris en charge pour Durable Functions lorsqu’il est hébergé dans le plan Flex Consumption. Consultez les recommandations lors de l’hébergement de Fonctions durables dans le plan Flex Consumption.
  • Intégration de réseau virtuel Vérifiez que le Microsoft.App fournisseur de ressources Azure est activé pour votre abonnement en suivant ces instructions. La délégation de sous-réseau nécessaire pour les applications Flex Consumption est Microsoft.App/environments.
  • Déclencheurs : bien que tous les déclencheurs soient entièrement pris en charge dans un plan Flex Consumption, 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 bundle d’extensions ou une version ultérieure.
  • Régions : toutes les régions ne sont actuellement pas prises en charge. Pour en savoir plus, consultez Afficher les régions actuellement prises en charge.
  • Déploiements : les emplacements de déploiement ne sont actuellement pas pris en charge.
  • Proxies : les fonctions Proxy ne sont pas prises en charge. Envisagez d’intégrer vos applications de fonction à Gestion des API Azure.
  • Mise à l’échelle : l’échelle maximale la plus basse est actuellement 40. La valeur la plus élevée actuellement prise en charge est 1000.
  • Dépendances managées : les dépendances managées dans PowerShell ne sont pas prises en charge par Flex Consumption. Vous devez au lieu de cela charger des modules avec du contenu de l’application.
  • Paramètres de diagnostic : les paramètres de diagnostic ne sont actuellement pas pris en charge.
  • Certificats : le chargement de certificats avec le paramètre d’application WEBSITE_LOAD_CERTIFICATES, les certificats managés, les certificats app service et d’autres fonctionnalités basées sur des certificats de plateforme ne sont actuellement pas pris en charge.
  • Références Key Vault et App Configuration : vous ne pouvez pas utiliser actuellement les références Azure Key Vault ou Azure App Configuration dans les paramètres d’application de votre plan Flex Consumption lorsque ces services sont limités à l’accès réseau. Cette limitation s’applique même lorsque l’application de fonction a activé l’intégration du réseau virtuel. Si vous devez utiliser des instances Key Vault ou App Configuration restreintes, vous devez utiliser des kits SDK clients pour récupérer manuellement des valeurs à partir de références dans ces services. Les extensions de liaison de fonctions ne peuvent pas non plus accéder à ces références, ce qui signifie que vous devez également utiliser des sdk client Azure pour accéder aux données de service distant à partir de votre code de fonction.
  • Fuseaux horaires : les paramètres d’application WEBSITE_TIME_ZONE et TZ ne sont actuellement pas pris en charge lors de l’exécution sur le plan Consommation flexible.

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