Options d’hébergement Azure Functions
Lorsque vous créez une Function App dans Azure, vous devez choisir un plan d’hébergement pour votre application. Azure Functions propose trois plans d'hébergement de base : plan Consommation, plan Premium et plan dédié (App Service). Ces plans d'hébergement sont facilités par l'infrastructure Azure App Service et sont généralement disponibles (GA) sur les machines virtuelles Linux et Windows.
Le plan d’hébergement Azure Functions que vous choisissez détermine les comportements suivants :
- La mise à l’échelle de votre Function App.
- Les ressources disponibles pour chaque instance de Function App.
- La prise en charge des fonctionnalités avancées, notamment la connectivité du réseau virtuel Azure.
Outre l’hébergement d’Azure Functions, vous pouvez également héberger des applications de fonction conteneurisées dans des conteneurs qui peuvent être déployées sur des clusters Kubernetes ou dans Azure Container Apps. Si vous choisissez d’héberger vos fonctions dans un cluster Kubernetes, utilisez un cluster Kubernetes avec Azure Arc. Pour en savoir plus sur le déploiement d’applications conteneur personnalisées, consultez Hébergement Azure Container Apps de Azure Functions.
Cet article fournit une comparaison détaillée entre les différents plans d’hébergement, y compris les options d’hébergement basées sur les conteneurs.
Notes
L'hébergement de conteneurs Azure Functions sur des clusters Kubernetes compatibles avec Azure Arc et sur Azure Container Apps est actuellement en préversion.
Vue d’ensemble des plans
Voici un résumé des avantages des trois principaux plans d'hébergement Azure Functions :
| Plan | Avantages |
|---|---|
| Plan de consommation | Mettez à l’échelle automatiquement et ne payez les ressources de calcul que lorsque vos fonctions sont en cours d’exécution. Dans le plan de consommation, les instances de l’hôte Functions sont ajoutées et supprimées de façon dynamique en fonction du nombre d’événements entrants. ✔ Plan d’hébergement par défaut. ✔ Paiement uniquement en cas d’exécution de vos fonctions. ✔ Mise à l’échelle automatique, même pendant les périodes de charge élevée. |
| Plan Premium | Mise à l’échelle automatique selon la demande à l’aide de Workers préparés, qui exécutent des applications sans délai après leur inactivité, exécution sur des instances plus puissantes et connexion à des réseaux virtuels. Tenez compte du plan Azure Functions Premium dans les situations suivantes : ✔Vos applications de fonction s’exécutent en continu ou presque. ✔ Vous disposez d’un grand nombre d’exécutions de petite taille et d’une facture d’exécution élevée, mais de peu de Go par seconde dans le plan Consommation. ✔Vous avez besoin de plus d’options de mémoire ou de processeur que celles qui sont proposées dans le plan de consommation. ✔Votre code exige une durée d’exécution supérieure à celle qui est autorisée dans le plan de consommation. ✔ Vous avez besoin de fonctionnalités qui ne sont pas disponibles dans le plan Consommation, notamment la connectivité de réseau virtuel. ✔ Vous souhaitez fournir une image Linux personnalisée sur laquelle exécuter vos fonctions. |
| Plan dédié | Exécutez vos fonctions au sein d’un plan App Service aux tarifs habituels du plan App Service. Idéal pour les scénarios de longue durée où l’extension Durable Functions ne peut pas être utilisée. Envisagez un plan App Service dans les situations suivantes : ✔ Vous disposez de machines virtuelles existantes sous-utilisées qui exécutent déjà d’autres instances App Service. ✔ La prédiction de la mise à l’échelle et des coûts est requise. |
Les tableaux de comparaison de cet article incluent également les options d’hébergement suivantes, qui fournissent la plus grande quantité de contrôle et d’isolation dans laquelle exécuter vos applications de fonction.
| Option d’hébergement | Détails |
|---|---|
| ASE | App Service Environment(ASE) est une fonctionnalité d’App Service qui fournit un environnement entièrement isolé et dédié pour l’exécution sécurisée des applications App Service à grande échelle. Les ASE sont appropriés pour les charges de travail d’application qui nécessitent : ✔ Une très grande échelle. ✔ Une isolation totale du calcul et un accès réseau sécurisé. ✔ Utilisation élevée de la mémoire. |
| Azure Container Apps | Azure Container Apps est un environnement entièrement géré qui vous permet d’exécuter des micro-services et des applications conteneurisées sur une plateforme sans serverless. Azure Container Apps vous permet d'exécuter vos fonctions avec la puissance du service Azure Kubernetes (AKS) sous-jacent, tout en éliminant la complexité liée à l'utilisation des API Kubernetes. |
| Kubernetes (Direct ou Azure Arc) |
Kubernetes offre un environnement totalement isolé et dédié qui s’exécute sur la plateforme Kubernetes. Kubernetes convient aux charges de travail d’application qui nécessitent : ✔ Des exigences matérielles personnalisées. ✔ Une isolation et un accès réseau sécurisé. ✔ Une possibilité d’exécution dans un environnement hybride ou multi-cloud. ✔ Une exécution en parallèle de services et d’applications Kubernetes existants. |
Les autres tableaux de cet article comparent les plans sur des fonctionnalités et des comportements différents. Pour une comparaison des coûts entre les plans d’hébergement dynamique (Consommation et Premium), consultez la page de tarification d’Azure Functions. Pour obtenir la tarification des différentes options de plan Dedicated, consultez la page de tarification d’App Service.
Système d'exploitation/runtime
Le tableau suivant indique le système d'exploitation et la prise en charge des langages pour les plans d’hébergement.
| Linux1,2 code-only |
Windows code-only | Linux1,2,3 Conteneur Docker |
|
|---|---|---|---|
| Plan de consommation | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Aucune prise en charge |
| Plan Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Plan dédié | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (direct) | n/a | n/a | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (préversion) | C# JavaScript Java Python TypeScript |
n/a | C# JavaScript Java PowerShell Core Python TypeScript |
1 Linux est le seul système d’exploitation pris en charge pour votre pile d’exécution Python.
2 La prise en charge de PowerShell sur Linux est actuellement disponible en préversion.
3 Linux est le seul système d’exploitation pris en charge pour les conteneurs Docker.
Durée du délai d’expiration du conteneur de fonctions
La durée du délai d’expiration pour les fonctions d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet host.json. Cette propriété s’applique spécifiquement aux exécutions de fonction. Une fois que le déclencheur démarre l’exécution d’une fonction, la fonction doit retourner/répondre dans la durée du délai d’expiration. Pour plus d’informations, consultez Améliorer les performances et la fiabilité d’Azure Functions.
Le tableau suivant indique les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :
| Plan | Default | Maximum1 |
|---|---|---|
| Plan de consommation | 5 | 10 |
| Plan Premium | 302 | Illimité3 |
| Plan dédié | 302 | Illimité3 |
1 Quel que soit le paramètre de délai d’expiration du conteneur de fonctions, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une demande. Cela est dû au délai d’inactivité par défaut d’Azure Load Balancer. Pour des temps de traitement plus longs, pensez à utiliser un modèle asynchrone Durable Functions ou différez le travail actuel et renvoyez une réponse immédiate.
2 Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.
3 Garanti pour une durée maximale de 60 minutes. La mise à jour corrective du système d’exploitation et du runtime, la mise à jour corrective des vulnérabilités et la mise à l’échelle des comportements peuvent toujours annuler les exécutions de fonctions. Veillez bien à écrire des fonctions robustes.
Scale
Le tableau suivant compare les comportements de mise à l’échelle des différents plans d’hébergement.
Le nombre maximal d’instances est donné sur une base d’application par fonction (Consommation) ou par plan (Premium/Dédié), sauf indication contraire.
| Plan | Scale-out | Nombre maximal d’instances |
|---|---|---|
| Plan Consommation | Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure Azure Functions met automatiquement à l’échelle les ressources de processeur et de mémoire en ajoutant des instances de l’hôte Functions selon le nombre d’événements déclencheurs entrants. | Windows: 200 Linux: 1001 |
| Plan Premium | Basé sur les événements. Effectuer un scale-out automatique, même pendant les périodes de charge élevée L’infrastructure Azure Functions met automatiquement à l’échelle les ressources processeur et mémoire en ajoutant des instances de l’hôte Functions selon le nombre d’événements en fonction desquels ses fonctions sont déclenchées. | Windows: 100 Linux: 20 à 1002 |
| Plan dédié3 | Manuel/Mise à l’échelle automatique | 10-30 |
| ASE3 | Manuel/Mise à l’échelle automatique | 100 |
| Kubernetes | Mise à l’échelle automatique basée sur les événements pour les clusters Kubernetes qui utilisent KEDA. | Varie selon le cluster |
1 Pendant le scale-out, il existe actuellement une limite de 500 instances par abonnement et par heure pour les applications Linux sur un plan Consommation.
2 Dans certaines régions, les applications Linux sur un plan Premium peuvent être mises à l’échelle sur 100 instances. Pour plus d’informations, consultez l’article sur le plan Premium.
3 Pour connaître les limites spécifiques des différentes options du plan App Service, consultez les limites du plan App Service.
Comportement du démarrage à froid
| Plan | Détails |
|---|---|
| Plan de consommation | Les applications peuvent être mises à l’échelle jusqu’à zéro en cas d’inactivité, ce qui signifie que certaines requêtes peuvent présenter une latence supplémentaire au démarrage. Le plan de consommation offre des optimisations pour réduire le temps de démarrage à froid, notamment en extrayant à partir de fonctions d’espace réservé préparées qui exécutent déjà les processus de langage et d’hôte de fonction. |
| Plan Premium | Les instances perpétuellement chaudes permettent d’éviter les démarrages à froid. |
| Plan dédié | En cas d’exécution dans un plan dédié, l’hôte Functions peut s’exécuter en continu, ce qui signifie que le démarrage à froid n’est pas vraiment un problème. |
| ASE | En cas d’exécution dans un plan dédié, l’hôte Functions peut s’exécuter en continu, ce qui signifie que le démarrage à froid n’est pas vraiment un problème. |
| Kubernetes | Selon la configuration de KEDA, les applications peuvent être configurées de manière à éviter un démarrage à froid. Si elles sont configurées pour être mises à l’échelle à zéro, les nouveaux événements font l’objet d’un démarrage à froid. |
Limites du service
| Ressource | Plan Consommation | Plan Premium | Plan dédié | ASE | Kubernetes |
|---|---|---|---|---|---|
| Durée du délai d’expiration (min) par défaut | 5 | 30 | 301 | 30 | 30 |
| Durée du délai d’expiration maximum (min) | 10 | illimité7 | illimité2 | illimité | illimité |
| Nbre max. de connexions sortantes (par instance) | 600 actives (1 200 au total) | illimité | illimité | illimité | illimité |
| Taille de requête max. (Mo)3 | 100 | 100 | 100 | 100 | Dépend du cluster |
| Longueur de chaîne de requête max.3 | 4096 | 4096 | 4096 | 4096 | Dépend du cluster |
| Longueur d’URL de requête max.3 | 8 192 | 8 192 | 8 192 | 8 192 | Dépend du cluster |
| ACU par instance | 100 | 210-840 | 100-840 | 210-2508 | Tarification d’AKS |
| Mémoire max. (en Go par instance) | 1.5 | 3,5-14 | 1,75-14 | 3.5 - 14 | Tous les nœuds sont pris en charge |
| Nombre d’instances maximal (Windows/Linux) | 200/100 | 100/20 | varie en fonction de la référence SKU9 | 1009 | Dépend du cluster |
| Applications de fonction par plan11 | 100 | 100 | illimité4 | illimité | illimité |
| Plans App Service | 100 par région | 100 par groupe de ressources | 100 par groupe de ressources | - | - |
| Emplacements de déploiement par application10 | 2 | 3 | 1-209 | 20 | n/a |
| Stockage5 | 5 Go | 250 Go | 50-1 000 Go | 1 To | n/a |
| Domaines personnalisés par application | 5006 | 500 | 500 | 500 | n/a |
| domaines personnalisés Prise en charge SSL | connexion SNI SSL illimitée incluse | connexions 1 IP SSL et SNI SSL illimitées incluses | connexions 1 IP SSL et SNI SSL illimitées incluses | connexions 1 IP SSL et SNI SSL illimitées incluses | n/a |
1 Par défaut, le délai d’attente du runtime de Functions 1.x dans un plan App Service est illimité.
2 Nécessite que le plan App Service soit défini sur Always On. Facturation aux tarifs standard.
3 Ces limites sont définies dans l’hôte.
4 Le nombre réel d’applications de fonction qui peuvent être hébergées dépend de l’activité des applications, de la taille des instances de machine et de l’utilisation de ressources correspondante.
5 La limite de stockage est la taille totale du contenu dans le stockage temporaire de toutes les applications du même plan App Service. Le plan Consommation utilise Azure Files pour le stockage temporaire.
6 Lorsque votre application de fonction est hébergée dans un Plan Consommation, seule l’option CNAME est prise en charge. Pour les applications de fonction présentes dans un plan Premium ou un plan App Service, vous pouvez mapper un domaine personnalisé en utilisant l’un ou l’autre des enregistrements : CNAME ou A.
7 Garanti pour une durée maximale de 60 minutes.
8Les workers sont des rôles qui hébergent des applications clientes. Ils sont disponibles dans trois tailles fixes : Un processeur virtuel/3,5 Go de RAM ; Deux processeurs virtuels/7 Go de RAM ; Quatre processeurs virtuels/14 Go de RAM.
9 Pour plus d’informations, consultez Limites App Service.
10, y compris l’emplacement de production.
11 Il existe actuellement une limite de 5 000 applications de fonction dans un abonnement donné.
Limitations pour la création d’applications de fonction dans un groupe de ressources existant
Dans certains cas, quand vous essayez de créer un plan d’hébergement pour votre application de fonction dans un groupe de ressources existant, vous pouvez recevoir une des erreurs suivantes :
- Le niveau tarifaire n’est pas autorisé dans ce groupe de ressources
- Les Workers <nom_référence_SKU> ne sont pas disponibles dans le groupe de ressources <nom_groupe_ressources>
Ceci peut se produire quand les conditions suivantes sont rencontrées :
- Vous créez une application de fonction dans un groupe de ressources existant qui contient une autre application de fonction ou une autre application web. Par exemple, les applications de consommation Linux ne sont pas prises en charge dans le même groupe de ressources que les plans Linux Dédié ou Linux Premium.
- Votre nouvelle application de fonction est créée dans la même région que l’application précédente.
- L’application précédente présente une incompatibilité avec votre nouvelle application. Ceci peut se produire entre des références SKU ou des systèmes d’exploitation, ou en raison d’autres fonctionnalités au niveau de la plateforme, comme la prise en charge des zones de disponibilité.
La raison pour laquelle cela se produit est due à la façon dont les plans d’application de fonction et d’application web sont mappés à des pools de ressources différents lors de la création. Les différentes références SKU nécessitent un ensemble différent de fonctionnalités d’infrastructure. Quand vous créez une application dans un groupe de ressources, ce groupe de ressources est mappé et affecté à un pool de ressources spécifique. Si vous essayez de créer un autre plan dans ce groupe de ressources et que le pool mappé n’a pas de ressources requises, cette erreur se produit.
Quand cette erreur se produit, créez à la place votre application de fonction et votre plan d’hébergement dans un nouveau groupe de ressources.
Fonctionnalités réseau
| Fonctionnalité | Plan Consommation | Plan Premium | Plan dédié | ASE |
|---|---|---|---|---|
| Restrictions d’adresse IP entrantes | ✅Oui | ✅Oui | ✅Oui | ✅Oui |
| Points de terminaison privés entrants | ❌Non | ✅Oui | ✅Oui | ✅Oui |
| Intégration du réseau virtuel | ❌Non | ✅Oui (Zones géographiques) | ✅Oui (Zones géographiques et Passerelle) | ✅Oui |
| Déclencheurs de réseau virtuel (non HTTP) | ❌Non | ✅Oui | ✅Oui | ✅Oui |
| Connexions hybrides (Windows uniquement) | ❌Non | ✅Oui | ✅Oui | ✅Oui |
| Restrictions d’adresse IP sortantes | ❌Non | ✅Oui | ✅Oui | ✅Oui |
Facturation
| Plan | Détails |
|---|---|
| Plan de consommation | Ne payez que la durée d’exécution de vos fonctions. La facturation est basée sur le nombre d’exécutions, la durée d’exécution et la mémoire utilisée. |
| Plan Premium | Le plan Premium se base sur le nombre de cœurs-seconde et la mémoire utilisée sur les instances nécessaires et préparées. Au moins une instance par plan doit être chaude en permanence. Ce plan offre la tarification la plus prévisible. |
| Plan dédié | Le coût des Function App dans un plan App Service est le même que pour d’autres ressources App Service, par exemple les applications web. |
| App Service Environment (ASE) | Un tarif fixe mensuel couvre l’infrastructure d’un ASE et ne change pas avec la taille de l’environnement ASE. Chaque processeur virtuel de plan App Service présente aussi un coût. Toutes les applications hébergées dans un environnement App Service sont dans la référence (SKU) de prix Isolée. |
| Kubernetes | Vous ne payez que le coût de votre cluster Kubernetes et aucune facturation supplémentaire pour Functions. Votre application de fonction s’exécute comme une charge de travail d’application sur votre cluster, tout comme une application normale. |