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.

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 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

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.

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 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. 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, dans la préversion, 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 flexible. Cela 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 se mettre à l’échelle :

  • 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

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 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 :

  • Hôte : le délai d’expiration pour l’initialisation de l’application est de 30 secondes. Si votre application de fonction prend plus de 30 secondes pour démarrer, vous verrez des entrées System.TimeoutException liées à gRPC. Ce délai d’expiration sera configurable et une exception plus claire sera implémentée dans le cadre de cet élément de travail d’hôte.
  • Durable Functions : Stockage Azure est actuellement le seul fournisseur de stockage pris en charge pour la fonctionnalité Durable Functions lorsque celle-ci est hébergée dans le plan Consommation flexible. Consultez les recommandations lorsque la fonctionnalité Durable Functions est hébergée dans le plan Consommation flexible.
  • Intégration au réseau virtuel : vérifiez que le fournisseur de ressources Azure Microsoft.App 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 : tous les déclencheurs sont entièrement pris en charge, à l’exception des déclencheurs Kafka et Azure SQL. 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 : les emplacements de déploiement ne sont pas actuellement pris en charge.
  • 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.
  • Dépendances managées : les dépendances managées dans PowerShell ne sont pas prises en charge par Consommation flexible. Au lieu de cela, vous devez définir vos propres modules personnalisés.
  • Paramètres de diagnostic: Les paramètres de diagnostic ne sont pas pris en charge actuellement.
  • Certificats : le chargement de certificats avec le paramètre d’application WEBSITE_LOAD_CERTIFICATES n’est actuellement pas pris en charge.
  • Références de coffre de clés : les références de coffre de clés dans les paramètres d’application ne fonctionnent pas lorsque le coffre de clés est limité au niveau de l’accès réseau, même si l’application de fonction dispose d’une intégration de réseau virtuel. La solution de contournement actuelle consiste à référencer directement le coffre de clés dans le code et à lire les secrets requis.
  • Montage du partage de fichiers Azure Files : le montage d’un partage de fichiers Azure Files ne fonctionne pas lorsque l’application de fonction dispose d’une intégration de réseau virtuel.

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