Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
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 plans d’hébergement dédiés. 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, vous ajoutez et supprimez des instances de l’hôte Azure Functions en fonction du nombre d’événements entrants, comme le plan Flex Consumption et le plan Consommation. Vous pouvez déployer plusieurs applications de fonction dans le même plan Premium. Vous pouvez configurer la taille de l’instance de calcul, la taille du plan de base et la taille maximale du plan.
Facturation
Vous payez pour le plan Premium en fonction du nombre de secondes principales et de la mémoire allouée entre les instances. Ce modèle de facturation diffère du plan Consommation, qui vous facture en fonction de la consommation et des exécutions de ressources par seconde. Le plan Premium n’a aucun frais d’exécution. Ce modèle de facturation entraîne un coût mensuel minimal par plan actif, que la fonction soit active ou inactive. Toutes les applications de fonction d’un plan Premium partagent des instances allouées. Pour plus d’informations, consultez Tarification d’Azure Functions.
Remarque
Chaque plan Premium a toujours 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 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 ou choisir explicitement un plan d’hébergement Azure Functions Premium à l’aide de l’une des versions Elastic Premium . Vous hébergez l’application Functions que vous créez 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. Lorsque de nouveaux événements arrivent, le système doit créer une instance qui exécute votre application. La spécialisation d’une nouvelle instance prend un certain 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 "Always ready" constituent une catégorie d’instances préallouées qui ne sont pas affectées par le processus de mise à l’échelle, et les instances "prewarmed" servent de tampon lorsque vous effectuez une mise à l’échelle en raison des événements HTTP.
Lorsque les événements commencent à déclencher l’application, le système les achemine d’abord vers les instances toujours prêtes. Lorsque la fonction devient active suite à des événements HTTP, d’autres instances sont initialisées afin de servir de 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, l’application ajoute d’autres instances 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, considérez trois applications de fonction dans le même plan Premium. Lorsque deux de vos applications ont le nombre d’instances Toujours prêtes défini sur « un » et que la troisième application est définie sur « cinq », le nombre minimal d’instances pour votre plan entier est de « cinq ». Ce nombre reflète également le nombre minimal d’instances pour lesquelles votre plan est facturé. Le nombre maximal d’instances toujours prêtes prises 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’option de menuScale Out> App Service à gauche et en modifiant les options de scale-out de l’application. 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édéfinit par défaut est 1 et, pour la plupart des scénarios, conservez cette valeur comme 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éparation, vous pouvez envisager d’augmenter cette mémoire tampon d’instances prédéfinies. 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édéfinit. 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.
- Au fur et à mesure que la charge augmente et que votre application a besoin d’autres instances pour gérer le trafic HTTP, cette instance prédéfinée échange vers 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. Vous configurez la limite maximale de l’application en utilisant la limite de mise à l’é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. Vous pouvez également utiliser des restrictions IP sur l’application pour restreindre 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. Vous avez besoin d’un bloc IP avec au moins 100 adresses disponibles.
Pour plus d’informations, consultez Intégrer Azure Functions à un réseau virtuel.
Mise à l’échelle élastique rapide
La même logique de mise à l’échelle rapide que les plans Flex Consumption et Consumption ajoute automatiquement davantage d’instances de calcul pour votre application. 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 faire cesser l’exécution de la fonction avec une période de grâce de 10 minutes.
- 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 plus d’informations, consultez Planifier la migration.
La migration n'est pas prise en charge sur Linux.
Paramètres du plan Premium
Lorsque vous créez le plan, vous définissez deux paramètres de taille de plan : le nombre minimal d’instances (ou la taille du plan) et la limite de rafale maximale.
Si votre application a besoin de plus d’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 vous la définissez. Vous payez les instances uniquement lorsqu’elles sont en cours d’exécution et allouées à votre usage, sur une base à la seconde. La plateforme s’efforce d’assurer le scale-out de votre application jusqu’à la limite maximale définie.
Vous pouvez configurer la taille du plan dans le portail Azure en sélectionnant votre application de fonction déployée sur ce plan, en accédant aux options de menuScale Up> App Service à gauche et en choisissant une plus grande taille de plan. Pour augmenter la limite maximale de rafales, choisissez l’option de menu Scale Out et modifiez l’option Plan Scale out>Maximum burst .
La valeur minimale pour chaque plan Premium est d’au moins une instance. Le nombre minimal réel d’instances est déterminé en fonction des instances toujours prêtes demandées par les applications dans le 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 est de cinq. L’application A s’exécute sur les cinq instances et l’application B s’exécute sur deux.
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é du fait de l’indisponibilité d’autres instances supplémentaires. En définissant un minimum supérieur au minimum calculé automatiquement, vous réservez des instances préalablement au scale-out.
Vous pouvez configurer les instances minimales dans le portail Azure en sélectionnant votre application de fonction déployée sur ce plan, en accédant au menu Échelle> à gauche et en modifiant l’option Instances minimales de mise à l'échelle>.
Références SKU d’instance disponibles
Lorsque vous créez ou mettez à l’échelle votre plan, choisissez parmi trois tailles d’instance. Vous êtes facturé pour le nombre total de cœurs et de mémoire que vous approvisionnez, par seconde pour chaque instance allouée à vous. 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>.
Pour les plans avec plus de 4 Go de mémoire, définissez le paramètre 64 Bit de plateforme Bitness 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 |
|---|---|---|
| Australie Centre | 100 | 20 |
| Australie Centre 2 | 100 | Non disponible |
| Australie Est | 100 | 40 |
| Australie Sud-Est | 100 | 20 |
| Brésil Sud | 100 | 20 |
| Canada Centre | 100 | 100 |
| Inde Centre | 100 | 20 |
| USA Centre | 100 | 100 |
| Chine Est 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 |
| Japon Ouest | 100 | 20 |
| JIO Inde Ouest | 100 | 20 |
| Corée Centre | 100 | 20 |
| Corée Sud | 40 | 20 |
| Mexique Centre | 20 | 20 |
| USA Centre Nord | 100 | 20 |
| Europe Nord | 100 | 100 |
| Norvège Est | 100 | 20 |
| Afrique du Sud Nord | 100 | 20 |
| Afrique du Sud Ouest | 20 | 20 |
| USA Centre Sud | 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 |
| Royaume-Uni Sud | 100 | 100 |
| Royaume-Uni Ouest | 100 | 20 |
| Gouvernement des États-Unis - Arizona | 20 | 20 |
| Gouvernement des États-Unis - Texas | 20 | Non disponible |
| Gouvernement des États-Unis - Virginie | 80 | 20 |
| USA Centre-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.