Comparer les 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 vous fournit ces options d’hébergement pour votre code de fonction :
| Option d’hébergement | Service | Disponibilité | Support pour les conteneurs |
|---|---|---|---|
| Plan Consommation | Azure Functions | Disponibilité générale (GA) | Aucun(e) |
| Plan Flex Consumption | Azure Functions | GA | Aucun(e) |
| Plan Premium | Azure Functions | GA | Linux |
| Plan dédié | Azure Functions | GA | Linux |
| Container Apps | Azure Container Apps | GA | Linux |
L’infrastructure Azure App Service facilite l’hébergement d’Azure Functions sur des machines virtuelles Linux et Windows. L’option d’hébergement 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.
- Prise en charge des conteneurs Linux.
Le plan que vous choisissez a également un impact sur les coûts d’exécution de votre code de fonction.
Vue d’ensemble des plans
Voici un résumé des avantages des différentes options d’hébergement :
Plan Consommation
Le plan Consommation est le plan d’hébergement par défaut. Payez des ressources de calcul uniquement lorsque vos fonctions s’exécutent (paiement à l’utilisation) avec une mise à l’échelle automatique. 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 Flex Consumption
Bénéficiez d’une scalabilité élevée avec les choix de calcul, la mise en réseau virtuelle et la facturation de paiement à l’utilisation. Dans le plan Flex Consumption, les instances de l’hôte Functions sont ajoutées et supprimées dynamiquement en fonction de la concurrence configurée par instance et du nombre d’événements entrants.
Vous pouvez réduire les démarrages à froid en spécifiant le nombre d’instances préprovisionnées (toujours prêtes). Se met automatiquement à l’échelle en fonction de la demande.
Plan Premium
Effectue automatiquement une mise à l’échelle en fonction de la demande à l’aide de rôles de travail préparés, qui exécutent des applications sans délai après l’inactivité, s’exécutent sur des instances plus puissantes et se connectent aux réseaux virtuels.
Envisagez le plan Premium d’Azure Functions dans les situations suivantes :
- Vos applications de fonction s’exécutent en continu ou presque.
- Vous souhaitez contrôler davantage vos instances et déployer plusieurs applications de fonction sur le même plan avec une mise à l’échelle pilotée par les événements.
- Vous avez un nombre élevé de petites exécutions et une facture d’exécution élevée, mais un rapport Go par seconde faible dans le plan Consommation.
- Vous avez besoin de plus d’options de mémoire ou de processeur que celles proposées dans les plans Consommation.
- Votre code exige une durée d’exécution supérieure à celle qui est autorisée dans le plan Consommation.
- Vous avez besoin d’une connectivité de réseau virtuel.
- Vous souhaitez fournir une image Linux personnalisée dans 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ù Durable Functions ne peut pas être utilisé.
Envisagez un plan App Service dans les situations suivantes :
- Vous devez disposer d’une facturation entièrement prévisible ou mettre à l’échelle manuellement des instances.
- Vous souhaitez exécuter plusieurs applications web et applications de fonction sur le même plan.
- Vous avez besoin d’accéder à des tailles de calcul plus importantes.
- Isolation de calcul complète et accès réseau sécurisé fournis par une instance App Service Environment (ASE).
- Utilisation de la mémoire importante et mise à l’échelle élevée (ASE).
Container Apps
Créez et déployez des applications de fonction conteneurisées dans un environnement entièrement managé hébergé par Azure Container Apps.
Utilisez le modèle de programmation Azure Functions pour créer des applications de fonction natives cloud, serverless, natives et basées sur des événements Exécutez vos fonctions en même temps que d’autres microservices, API, sites web et workflows en tant que programmes hébergés par conteneur.
Envisagez d’héberger vos fonctions sur Container Apps dans les situations suivantes :
- Vous souhaitez empaqueter des bibliothèques personnalisées avec votre code de fonction pour prendre en charge des applications métier.
- Vous devez migrer l’exécution du code à partir d’applications locales ou héritées vers des microservices natifs cloud s’exécutant dans des conteneurs.
- Vous souhaitez éviter la surcharge et la complexité de la gestion des clusters Kubernetes et du calcul dédié.
- Vous avez besoin de la puissance de traitement haut de gamme fournie par les ressources de calcul processeur dédiées pour vos fonctions.
Durée du délai d’expiration de l’application de fonction
La functionTimeout propriété du fichier projet host.json spécifie la durée d’attente des fonctions dans une application de fonction. Cette propriété s’applique spécifiquement aux exécutions de fonction. Une fois que le déclencheur a démarré l’exécution d’une fonction, la fonction doit retourner/répondre dans les limites du délai d’expiration.
Le tableau suivant présente les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :
| Plan | Par défaut | Maximum1 |
|---|---|---|
| Plan Consommation Flex | 30 | Illimité2 |
| Plan Premium | 304 | Illimité2 |
| Plan dédié | 304 | Illimité3 |
| Container Apps | 30 | Illimité5 |
| Plan Consommation | 5 | 10 |
- Quel que soit le paramètre de délai d’expiration de l’application de fonction, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une requête. Cela est dû au délai d’inactivité par défaut d’Azure Load Balancer. Pour des temps de traitement plus longs, envisagez d’utiliser le modèle asynchrone Durable Functions ou de différer le travail réel et de retourner une réponse immédiate.
- Aucun délai maximal d’expiration d’exécution n’est appliqué. Toutefois, la période de grâce donnée à une exécution de fonction est de 60 minutes pendant le scale in pour les plans Flex Consumption et Premium, et une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
- Nécessite que le plan App Service soit défini sur Always On. Une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
- Le délai d’expiration par défaut pour la version 1.x du runtime hôte Functions est illimité.
- Lorsque le nombre minimal de réplicas est défini sur zéro, le délai d’attente par défaut dépend des déclencheurs spécifiques utilisés dans l’application.