Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Le plan Élastique Premium Azure Functions est une option d’hébergement à échelle dynamique pour les applications de fonction. Pour obtenir d’autres options de plan d’hébergement, consultez les options d’hébergement d’Azure Functions.
Important
Azure Functions peut s’exécuter sur la plateforme Azure App Service. Dans la plateforme App Service, les plans qui hébergent les applications de fonction du plan Premium sont appelés des plans Élastique Premium, avec des noms de référence SKU tels que EP1. Si vous choisissez d’exécuter votre application de fonction sur un plan Premium, veillez à créer un plan avec un nom de référence SKU qui commence par « E », par exemple EP1. Les noms des références SKU du plan App Service qui commencent par « P », par exemple P1V2 (plan Premium V2 Small), sont en fait des P1V2. Comme ils sont Dédiés et non Élastique Premium, les plans avec des noms de références SKU commençant par « P » ne sont pas mis à l’échelle de façon dynamique et peuvent augmenter vos coûts.
L’hébergement de plan Premium offre les avantages suivants pour vos fonctions :
- Instances Toujours prêtes et préchauffées pour éviter les démarrages à froid
- Connectivité de réseau virtuel
- Prise en charge des durées d’exécution plus longues
- Choix des tailles d’instance Premium
- Tarification plus prévisible, par rapport au plan Consommation
- Allocation d’applications à haute densité pour les plans avec plusieurs applications de fonction
- Prise en charge des déploiements de conteneurs Linux
Lorsque vous utilisez le plan Premium, les instances de l’hôte Azure Functions sont ajoutées et supprimées en fonction du nombre d’événements entrants, comme le plan Flex Consumption et le plan Consommation. Plusieurs applications de fonction peuvent être déployées sur le même plan Premium, et celui-ci vous permet de configurer la taille d’instance de calcul, la taille du plan de base et taille maximale de plan.
Facturation
La facturation du plan Premium se base sur le nombre de cœurs-seconde et la mémoire utilisée sur toutes les instances. Cette facturation diffère du plan Consommation, qui est facturé en fonction de la consommation de ressources et des exécutions par seconde. Il n’y a pas de frais d’exécution avec le plan Premium. Cette facturation entraîne un coût mensuel minimal par plan actif, que la fonction soit active ou inactive. Gardez à l’esprit que toutes les applications de fonction d’un plan Premium partagent les instances allouées. Pour en savoir plus, consultez la tarification d’Azure Functions.
Notes
Chaque plan Premium dispose en permanence d’au moins une instance active (facturée).
Créer un plan Premium
Lorsque vous créez une application de fonction dans le portail Azure, le plan de consommation est sélectionné par défaut. Pour créer une application de fonction qui s’exécute dans un plan Premium, vous devez créer explicitement un plan d’hébergement Premium Azure Functions à l’aide de l’une des références SKU Premium élastiques. L’application de fonction que vous créez est ensuite hébergée dans ce plan. Le portail Azure permet de créer facilement à la fois le plan Premium et l’application de fonction. Vous pouvez exécuter plusieurs applications de fonction dans le même plan Premium, mais elles s’exécutent toutes les deux sur le même système d’exploitation (Windows ou Linux).
Les articles suivants vous montrent comment créer par programmation une application de fonction avec un plan Premium :
Éliminer les démarrages à froid
Lorsque des événements ou des exécutions ne se produisent pas dans le plan Consommation, il se peut que votre application effectue une mise à l'échelle jusqu’à zéro instance. Quand de nouveaux événements se produisent, une nouvelle instance doit être spécialisée avec votre application s’exécutant sur celle-ci. La spécialisation de nouvelles instances prend du temps, en fonction de l’application. Cette latence supplémentaire sur le premier appel est souvent appelée démarrage à froid.
Le plan Premium fournit deux fonctionnalités qui fonctionnent ensemble pour éliminer efficacement les démarrages à froid dans vos fonctions : instances toujours prêtes et instances préchauffées. Les instances toujours prêtes sont une catégorie d’instances pré-allouées non affectées par la mise à l’échelle et les instances préchauffées constituent une mémoire tampon à mesure que vous effectuez une mise à l’échelle en raison d’événements HTTP.
Quand des événements commencent à déclencher l’application, ceux-ci sont d’abord routés vers les instances toujours prêtes. Lorsque la fonction devient active en raison d’événements HTTP, d’autres instances sont réchauffées en tant que mémoire tampon. Ces instances mises en mémoire tampon s’appellent des instances préchauffées. Cette mémoire tampon réduit le démarrage à froid des nouvelles instances nécessaires pendant la mise à l’échelle.
Instances toujours prêtes
Dans le plan Premium, vous pouvez faire en sorte que votre application soit toujours prête sur un nombre spécifié d’instances. Votre application s’exécute en continu sur ces instances, quelle que soit la charge. Si la charge dépasse ce que vos instances toujours prêtes peuvent gérer, des instances supplémentaires sont ajoutées si nécessaire, jusqu’à votre maximum spécifié.
Ce paramètre au niveau de l’application contrôle également les instances minimales de votre plan. Par exemple, envisagez d’avoir trois applications de fonction dans le même plan Premium. Lorsque deux de vos applications ont un nombre d'instances toujours prêt défini sur un, et que la troisième application a un nombre d'instances toujours prêt défini sur cinq, le nombre minimal pour l'ensemble de votre plan est de cinq. Cela reflète également le nombre minimal d’instances pour lesquelles votre plan est facturé. Le nombre maximal d’instances toujours prêtes pour la prise en charge par application est de 20.
Vous pouvez configurer le nombre d’instances toujours prêtes dans le portail Azure en sélectionnant votre application de fonction, en accédant à l’onglet Plan App Service et en sélectionnant les options Scale Out . Dans la fenêtre de modification de l’application de fonction, les instances toujours prêtes sont propres à cette application.
Instances préchauffées
Le paramètre de nombre d’instances préchauffées fournit des instances chauffées en tant que mémoire tampon pendant les événements d’activation et de mise à l’échelle HTTP. Les instances préchauffées continuent d’être mises en mémoire tampon tant que la limite maximale de scale-out n’est pas atteinte. Le nombre d’instances préchauffées par défaut est de 1, et dans la plupart des scénarios, cette valeur reste à 1.
Envisagez un scénario moins courant, tel qu’une application s’exécutant dans un conteneur personnalisé. Étant donné que les conteneurs personnalisés ont un temps de préchauffage, vous pouvez envisager d’augmenter cette mémoire tampon d’instances préchauffées. Une instance préchauffée ne devient active qu’une fois toutes les instances actives en cours d’utilisation.
Vous pouvez également définir un déclencheur de préchauffage qui s'exécute pendant le processus de préchauffage. Vous pouvez utiliser un déclencheur de préchauffage pour précharger des dépendances personnalisées pendant le processus de préchauffage afin que vos fonctions soient prêtes à commencer le traitement des requêtes immédiatement. Pour en savoir plus, consultez Déclencheur de préchauffage Azure Functions.
Prenons cet exemple qui montre comment les instances toujours prêtes et les instances prédéfinées fonctionnent ensemble. Une application de fonction Premium compte deux instances toujours prêtes configurées et une instance préchauffée par défaut.
- Quand l’application est inactive et qu’aucun événement n’est déclenché, l’application est provisionnée et s’exécute sur deux instances. À ce stade, vous êtes facturé pour les deux instances toujours prêtes, mais n’êtes pas facturé pour une instance préchauffée car aucune instance préchauffée n’est encore allouée.
- À mesure que votre application commence à recevoir le trafic HTTP, les requêtes sont équilibrées sur les deux instances toujours prêtes. Dès que ces deux instances démarrent le traitement des événements, une instance est ajoutée pour remplir la mémoire tampon préchauffée. L’application s’exécute maintenant avec trois instances provisionnées : les deux instances toujours prêtes et la troisième instance en tant que mémoire tampon préchauffée et inactive. Vous êtes facturé pour les trois instances.
- À mesure que la charge augmente et que votre application a besoin d’autres instances pour gérer le trafic HTTP, cette instance préchauffée est échangée par une instance active. La charge HTTP est désormais routée vers les trois instances, et une quatrième instance est provisionnée instantanément pour remplir la mémoire tampon préchauffée.
- Cette séquence de mise à l’échelle et de préchauffage se poursuit jusqu’à ce que le nombre maximal d’instances de l’application soit atteint ou que la charge diminue, ce qui entraîne la mise à l’échelle de la plateforme après une période. Aucune instance n’est préchauffée ou activée au-delà de la valeur maximale.
Vous ne pouvez pas modifier le paramètre de nombre d’instances préchauffées dans le portail. Vous devez plutôt utiliser Azure CLI ou Azure PowerShell.
Instances d’applications de fonction maximales
En plus du nombre maximal de rafales du plan, vous pouvez configurer un maximum par application. La valeur maximale d’une application peut être configurée en utilisant la limite d’échelle de l’application. La limite maximale du scale-out de l’application ne peut pas dépasser le nombre maximal d’instances en rafale du plan.
Connectivité de réseau privé
Les applications de fonction déployées sur un plan Premium peuvent tirer parti de l’intégration de réseau virtuel pour les applications web. Une fois configurée, votre application peut communiquer avec des ressources de votre réseau virtuel ou sécurisées via des points de terminaison de service. Des restrictions d’adresse IP sont également disponibles sur l’application pour limiter le trafic entrant.
Lors de l’attribution d’un sous-réseau à votre Function App dans un plan Premium, vous avez besoin d’un sous-réseau avec suffisamment d’adresses IP pour chaque instance potentielle. Nous imposons un bloc d’au moins 100 adresses IP disponibles.
Pour plus d’informations, consultez Intégrer Azure Functions à un réseau virtuel.
Mise à l’échelle élastique rapide
Des instances de calcul supplémentaires sont automatiquement ajoutées pour votre application en utilisant la même logique de mise à l’échelle rapide que le Plan Consommation. Les applications du même plan App Service sont mises à l’échelle indépendamment les unes des autres en fonction des besoins d’une application individuelle. Toutefois, les applications Functions dans le même plan App Service partagent des ressources de machine virtuelle pour aider à réduire les coûts, lorsque cela est possible. Le nombre d’applications associées à une machine virtuelle dépend de l’encombrement de chaque application et de la taille de la machine virtuelle.
Pour en savoir plus sur le fonctionnement de la mise à l’échelle, consultez Mise à l’échelle basée sur les événements dans Azure Functions.
Durée d’exécution plus longue
Les fonctions Azure Functions dans un Plan Consommation sont limitées à 10 minutes par exécution. Dans le plan Premium, la durée d’exécution par défaut est de 30 minutes pour éviter toute perte de contrôle. Cependant, vous pouvez modifier la configuration de host.json pour faire en sorte que la durée soit illimitée pour les applications du plan Premium, avec les limitations suivantes :
- Les mises à niveau de plateforme peuvent déclencher un arrêt managé et arrêter l’exécution de la fonction avec une période de grâce de 10 minutes.
- Il existe un minuteur inactif qui arrête le Worker après 60 minutes sans nouvelles exécutions.
- Le comportement de scale-in peut entraîner l’arrêt du Worker après 60 minutes.
- Les échanges d’emplacements peuvent mettre fin aux exécutions sur les emplacements source et cible pendant l’échange.
Migration
Si vous possédez une application de fonction existante, vous pouvez utiliser des commandes d’Azure CLI pour migrer une application entre un plan Consommation et un plan Premium sur Windows. Les commandes spécifiques dépendent de la direction de la migration. Pour en savoir plus, consultez Planifier la migration.
La migration n'est pas prise en charge sur Linux.
Paramètres du plan Premium
Pendant la création du plan, deux paramètres de taille de plan sont proposés : le nombre minimal d’instances (ou taille du plan) et la limite maximale en rafale.
Si votre application nécessite des instances au-delà des instances toujours prêtes, elle peut continuer à effectuer un scale-out jusqu’à ce que le nombre d’instances atteigne la limite de rafale maximale du plan, ou la limite maximale de scale-out de l’application si elle est configurée. Vous serez facturé pour des instances uniquement quand elles sont en cours d’exécution et vous sont allouées à la seconde. La plateforme s’efforce d’assurer la mise à l’échelle de votre application jusqu’à la limite maximale définie.
Vous pouvez configurer la taille du plan et le nombre maximal d’instances dans le portail Azure en sélectionnant les options Effectuer un scale-out sous Paramètres ou une application de fonction déployée sur ce plan.
La valeur minimale pour chaque plan Premium est d’au moins une instance. Le nombre minimal effectif d’instances est déterminé pour vous en fonction du nombre d’instances toujours prêtes demandées par les applications du plan. Par exemple, si l’application A demande cinq instances toujours prêtes et que l’application B en demande deux dans le même plan, la taille minimale du plan calculée est fixée à cinq. L’application A s’exécute sur les cinq, et l’application B ne s’exécute que sur 2.
Important
Vous êtes facturé pour chaque instance allouée dans le nombre minimal d’instances, que les fonctions s’exécutent ou non.
Dans la plupart des cas, ce minimum calculé automatiquement est suffisant. Cependant, si nécessaire, nous ferons de notre mieux pour assurer une mise à l’échelle au-delà du nombre minimal. Même si cela est peu probable, il est possible qu’à un moment donné, le scale-out soit retardé si d’autres instances sont indisponibles. En définissant un minimum supérieur au minimum calculé automatiquement, vous réservez des instances préalablement au scale-out.
Vous pouvez configurer le nombre minimal d’instances dans le portail Azure en sélectionnant les options Effectuer un scale-out sous Paramètres d’une application de fonction déployée sur ce plan.
Références SKU d’instance disponibles
Pendant la création ou la mise à l’échelle de votre plan, vous pouvez choisir entre trois tailles d’instance. Vous serez facturé pour le nombre total de cœurs et de mémoire approvisionnés, pour chaque seconde où chaque instance vous est allouée. Votre application peut automatiquement effectuer un scale-out sur plusieurs instances en fonction des besoins.
| Référence (SKU) | Cœurs | Mémoire | Stockage |
|---|---|---|---|
| Épisode 1 | 1 | 3,5 Go | 250 Go |
| EP2 | 2 | 7 Go | 250 Go |
| EP3 | 4 | 14 Go | 250 Go |
Considérations liées à l’utilisation de la mémoire
L’exécution sur une machine avec davantage de mémoire ne signifie pas toujours que votre application de fonction utilise toute la mémoire disponible.
Par exemple, une application de fonction JavaScript est contrainte par la limite de mémoire par défaut dans Node.js. Pour augmenter cette limite de mémoire fixe, ajoutez le paramètre d’application languageWorkers:node:arguments avec la valeur --max-old-space-size=<max memory in MB>.
Et pour les plans avec plus de 4 Go de mémoire, vérifiez que le paramètre de plateforme Bitness est défini 64 Bit sur sous Paramètres généraux.
Scale-out maximal par région
Le tableau suivant répertorie actuellement les valeurs maximales de scale-out prises en charge pour un plan unique dans chaque région et configuration du système d’exploitation :
| Région | Fenêtres | Linux |
|---|---|---|
| Centre de l’Australie | 100 | 20 |
| Centre de l’Australie 2 | 100 | Non disponible |
| Australie Est | 100 | 40 |
| Sud-Australie Est | 100 | 20 |
| Brésil Sud | 100 | 20 |
| Centre du Canada | 100 | 100 |
| Inde centrale | 100 | 20 |
| USA Centre | 100 | 100 |
| Chine orientale 2 | 20 | 20 |
| Chine Nord 2 | 20 | 20 |
| Chine Nord 3 | 20 | 20 |
| Asie Est | 100 | 20 |
| USA Est | 100 | 100 |
| USA Est 2 | 80 | 100 |
| France Centre | 100 | soixante |
| Allemagne Centre-Ouest | 100 | 20 |
| Israël Central | 100 | 20 |
| Italie Nord | 100 | 20 |
| Japon Est | 100 | 20 |
| OuJapon Est | 100 | 20 |
| JIO Inde Ouest | 100 | 20 |
| Centre de la Corée | 100 | 20 |
| Corée du Sud | 40 | 20 |
| Mexique Centre | 20 | 20 |
| Centre-Nord des États-Unis | 100 | 20 |
| Europe Nord | 100 | 100 |
| Norvège Est | 100 | 20 |
| Afrique du Sud Nord | 100 | 20 |
| Afrique du Sud Ouest | 20 | 20 |
| États-Unis - partie centrale méridionale | 100 | 100 |
| Inde Sud | 100 | Non disponible |
| Asie Sud-Est | 100 | 20 |
| Espagne Centre | 20 | 20 |
| Suisse Nord | 100 | 20 |
| Suisse Ouest | 100 | 20 |
| Émirats arabes unis Nord | 100 | 100 |
| Sud du Royaume-Uni | 100 | 100 |
| Ouest du Royaume-Uni | 100 | 20 |
| Gouvernement des États-Unis - Arizona | 20 | 20 |
| Gouvernement des États-Unis - Texas | 20 | Non disponible |
| Gouvernement des États-Unis - Virginie | 80 | 20 |
| Centre-USA Ouest | 100 | 20 |
| Europe Ouest | 100 | 100 |
| Inde Ouest | 100 | 20 |
| USA Ouest | 100 | 100 |
| USA Ouest 2 | 100 | 20 |
| USA Ouest 3 | 100 | 20 |
Pour plus d’informations, consultez Disponibilité des produits par région.