Estimation des coûts basés sur la consommation
Cet article vous montre comment estimer les coûts des plans d'hébergement Flex Consumption et Consumption.
Azure Functions propose actuellement ces différentes options d'hébergement pour vos applications de fonction, chaque option ayant son propre modèle de tarification de plan d'hébergement :
| Planifier | Description |
|---|---|
| Plan Consommation Flex | Vous payez le temps d’exécution sur les instances sur lesquelles vos fonctions s’exécutent, ainsi que toutes les instances toujours prêtes. Les instances sont ajoutées et supprimées dynamiquement en fonction du nombre d’événements entrants. Il s’agit du plan de mise à l’échelle dynamique recommandé, qui prend également en charge l’intégration de réseau virtuel. |
| Premium | Fournit les mêmes fonctionnalités et le même mécanisme de mise à l’échelle que le plan Consommation, mais avec des performances améliorées et l’intégration de réseau virtuel. Le coût se base sur le niveau tarifaire choisi. Pour plus d’informations, consultez Plan Premium Azure Functions. |
| Dédié (App Service) (niveau de base ou supérieur) |
Si vous avez besoin d’exécuter sur des machines virtuelles dédiées ou en isolation, d’utiliser des images personnalisées ou si vous voulez utiliser votre capacité de plan App Service en excès. Utilise la facturation du plan App Service standard. Le coût se base sur le niveau tarifaire choisi. |
| Applications de conteneur | Créez et déployez des applications de fonction conteneurisées dans un environnement entièrement géré hébergé par Azure Container Apps, qui vous permet d’rExécuter vos fonctions avec d’autres microservices, API, sites Web et workflows en tant que programmes hébergés par des conteneurs. |
| Consommation | Vous êtes facturé uniquement pour la durée d’exécution de votre application de fonction. Ce plan comprend un forfait gratuit par abonnement. |
Important
Le plan Consommation flexible est actuellement en préversion.
Vous devez toujours choisir l’option qui prend le mieux en charge les exigences de fonctionnalités, de performances et de coût pour vos exécutions de fonctions. Pour en savoir plus, voir Mise à l’échelle et hébergement d’Azure Functions.
Cet article se concentre sur les plans Flex Consumption et Consumption car dans ces plans, la facturation dépend des périodes actives d'exécutions à l'intérieur de chaque instance.
Durable Functions peut également s’exécuter dans ces deux plans. Pour en savoir plus sur les considérations financières lors de l’utilisation de Durable Functions, consultez Facturation Durable Functions.
Coûts basées sur la consommation
La façon dont les coûts basés sur la consommation sont calculés, y compris les subventions gratuites, dépend du plan spécifique. Pour obtenir les informations de coût et d’octroi les plus actuelles, consultez la page de tarification d’Azure Functions.
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. |
Ce diagramme représente la façon dont les coûts à la demande sont déterminés dans ce plan :
En plus du temps d’exécution, lors de l’utilisation d’une ou plusieurs instances toujours prêtes, vous êtes également facturé à un taux de référence inférieur pour le nombre d’instances toujours prêtes que vous conservez. Le temps d’exécution pour les instances toujours prêtes peut être moins cher que le temps d’exécution sur les instances avec l’exécution à la demande.
Important
Dans cet article, les prix sont fournis uniquement pour vous aider à comprendre les exemples de calculs. Vérifiez toujours la page de tarification d’Azure Functions lors de l’estimation des coûts que vous pourriez entraîner lors de l’exécution de vos fonctions dans le plan Flex Consumtion.
Pour les exemples de cette section, prenez en compte les tarifs d'aperçu réduits indiqués dans ce tableau pour le paiement à l'utilisation dans l'Est des États-Unis.
| Mode | Compteur | Subventions mensuelles gratuites | Taux de consommation |
|---|---|---|---|
| À la demande | Durée d’exécution uniquement (Go-s) | 100,000 |
$0.000016 par Go-s |
| À la demande | Exécutions (compte) | 250,000 |
$0.20 par million d’exécutions |
| Toujours prêtes | Temps de référence (inactif) (Go-s) | - | $0.000004 par Go-s |
| Toujours prêtes | Durée d’exécution uniquement (Go-s) | - | $0.000009 par Go-s |
| Toujours prêtes | Exécutions (compte) | - | $0.20 par million d’exécutions |
Considérez une application de fonction composée uniquement de déclencheurs HTTP avec et de ces faits de base :
- Les déclencheurs HTTP gèrent 40 requêtes constantes par seconde.
- Les déclencheurs HTTP gèrent 10 requêtes simultanées.
- Le paramètre de taille de la mémoire de l’instance est
2048 MB. - Il n’existe pas d’instances toujours prêtes configurées, ce qui signifie que l’application peut être mise à l’échelle à zéro.
Dans une situation telle que celle-ci, la tarification dépend davantage du type de travail effectué pendant l’exécution du code. Examinons deux scénarios de charge de travail :
Charge de travail liée au processeur : dans une charge de travail liée au processeur, il n’existe aucun avantage pour traiter plusieurs requêtes en parallèle dans la même instance. Cela signifie que vous pouvez mieux distribuer chaque requête à sa propre instance afin que les requêtes se terminent aussi rapidement que possible sans contention. Dans ce scénario, vous devez définir une concurrence de déclencheur HTTP faible de
1. Avec 10 requêtes simultanées, l’application s’adapte à un état stable d’environ 10 instances, et chaque instance est en permanence en cours de traitement d’une requête à la fois.Étant donné que la taille de chaque instance est d’environ 2 Go, la consommation d’une instance active unique est
2 GB * 3600 s = 7200 GB-s, qui à la demande supposée taux d’exécution (sans octroi gratuit appliqué) est$0.1152 USDpar heure par instance. Étant donné que l’application liée au processeur est mise à l’échelle à 10 instances, le taux horaire total pour le temps d’exécution est$1.152 USD.De même, les frais d’exécution à la demande (sans octroi gratuit) de 40 requêtes par seconde sont égaux à
40 * 3600 = 144,0000,144 million d’exécutions par heure. Le coût horaire total (sans octroi) des exécutions est alors0.144 * $0.20, qui est$0.0288par heure.Dans ce scénario, le coût horaire total d’exécution à la demande sur 10 instances est
$1.152 + $0.0288 = $1.1808 USD.Charge de travail liée aux E/S : dans une charge de travail liée aux E/S, la plupart du temps de l’application est passé en attente sur une demande entrante, ce qui peut être limité par le débit réseau ou d’autres facteurs en amont. En raison des entrées limitées, le code peut traiter plusieurs opérations simultanément sans impact négatif. Dans ce scénario, supposons que vous pouvez traiter toutes les 10 requêtes simultanées sur la même instance.
Étant donné que les frais de consommation sont basés uniquement sur la mémoire de chaque instance active, le calcul des frais de consommation est simplement
2 GB * 3600 s = 7200 GB-s, ce qui, à la demande supposée, taux d’exécution (sans aucune allocation gratuite appliquée) est$0.1152 USDpar heure pour l’instance unique.Comme dans le scénario lié au processeur, les frais d’exécution à la demande (sans octroi gratuit) de 40 requêtes par seconde sont égales à
40 * 3600 = 144,0000,144 millions d’exécutions par heure. Cela rend le coût horaire total (sans octroi) des exécutions0.144 * $0.20, qui est$0.0288par heure.Dans ce scénario, le coût horaire total d’exécution à la demande sur une seule instance est
$0.1152 + $0.0288 = $0.144 USD.
Autres coûts connexes
Quand vous estimez le coût global de l’exécution de vos fonctions dans un plan, quel qu’il soit, n’oubliez pas que le runtime Functions utilise plusieurs autres services Azure, facturés chacun séparément. Lorsque vous estimez le tarif des applications de fonction, tous les déclencheurs et toutes les liaisons que vous avez intégrés à d’autres services Azure vous obligent à créer et payer ces services supplémentaires.
Pour les fonctions qui s’exécutent dans un plan Consommation, le coût total est le coût d’exécution de vos fonctions, auquel s’ajoute le coût de la bande passante et d’autres services.
Lorsque vous estimez les coûts globaux de votre application de fonction et des services associés, utilisez la calculatrice de prix Azure.
| Coût connexe | Description |
|---|---|
| Compte de stockage | Chaque application de fonction vous oblige à avoir un compte de stockage Azure universel associé, facturé séparément. Ce compte est utilisé en interne par le runtime Functions, mais vous pouvez également l’utiliser pour les déclencheurs et les liaisons de stockage. Si vous n’avez pas de compte de stockage, un compte est créé pour vous lors de la création de l’application de fonction. Pour plus d’informations, consultez Exigences pour le compte de stockage. |
| Application Insights | Functions s’appuie sur Application Insights pour fournir une expérience de supervision hautes performances à vos applications de fonction. Même si ce n’est pas obligatoire, il est préférable d’activer l’intégration à Application Insights. Un forfait gratuit de données de télémétrie est inclus chaque mois. Pour en savoir plus, consultez la page des tarifs Azure Monitor. |
| Bande passante réseau | Vous pouvez être sujet à des coûts pour le transfert de données en fonction de la direction et du scénario du déplacement des données. Pour plus d’informations, consultez les détails de la tarification de la bande passante. |
Comportements affectant la durée d’exécution
Les comportements suivants de vos fonctions peuvent affecter sur la durée d’exécution :
Déclencheurs et liaisons : Le temps nécessaire pour lire l’entrée à partir de vos liaisons de fonction et y écrire la sortie est compté dans la durée d’exécution. Par exemple, quand votre fonction utilise une liaison de sortie pour écrire un message dans une file d’attente de stockage Azure, votre durée d’exécution inclut le temps nécessaire à l’écriture du message dans la file d’attente, lequel est inclus dans le calcul du coût de la fonction.
Exécution asynchrone : La durée pendant laquelle votre fonction attend les résultats d’une requête asynchrone (
awaiten C#) est comptée dans la durée d’exécution. Le calcul des Go-secondes se base sur l’heure de début et de fin de la fonction, ainsi que sur l’utilisation de la mémoire pendant cette période. Ce qui se produit au cours de cette période en termes d’activité du processeur n’est pas pris en compte dans le calcul. Vous pouvez éventuellement réduire les coûts pendant les opérations asynchrones à l’aide de Durable Functions. Vous n’êtes pas facturé pour le temps d’attente passé dans les fonctions d’orchestrateur.
Affichage des données relatives aux coûts
Dans votre facture, vous pouvez voir les données relatives aux coûts Nombre total d’exécutions - Fonctions et Durée d’exécution - Fonctions, ainsi que les coûts réels facturés. En revanche, ces données de facture sont un agrégat mensuel correspondant à une période de facturation passée.
Métriques au niveau de l’application de fonction
Pour mieux comprendre l’impact sur les coûts de vos fonctions, vous pouvez utiliser Azure Monitor pour voir les métriques relatives aux coûts en cours de génération par vos applications de fonction.
Utilisez Azure Monitor Metrics Explorer pour voir dans un format graphique les données relatives aux coûts de vos applications de fonction relevant du plan Consommation.
Sur le portail Azure, accédez à votre application de fonction.
Dans le panneau de gauche, faites défiler vers le bas jusqu’à Supervision et choisissez Mesures.
À partir de Métrique, choisissez Nombre d’exécutions de la fonction et Somme pour Agrégation. Ainsi, la somme du nombre d’exécutions pendant la période choisie est ajoutée au graphique.
Sélectionnez Ajouter une métrique et répétez les étapes 2 à 4 pour ajouter Unités d’exécution de la fonction au graphique.
Le graphique obtenu contient les totaux des deux métriques d’exécution dans l’intervalle de temps choisi, en l’occurrence deux heures.
Étant donné que le nombre d’unités d’exécution est bien supérieur au nombre d’exécutions, le graphique montre uniquement les unités d’exécution.
Ce graphique présente un total de 1,11 milliard Function Execution Units consommé sur une période de deux heures, exprimé en Mo-millisecondes. Pour convertir ce total en Go-secondes, divisez-le par 1 024 000. Dans cet exemple, l’application de fonction a consommé 1110000000 / 1024000 = 1083.98 Go-secondes. Vous pouvez utiliser cette valeur et la multiplier par le prix en vigueur de la durée d’exécution figurant sur la page des tarifs Functions, ce qui vous permet d’obtenir le coût de ces deux heures, en supposant que vous avez déjà utilisé tous les forfaits gratuits de durée d’exécution.
Métriques au niveau de la fonction
Les unités d’exécution de la fonction sont une combinaison de la durée d’exécution et de votre utilisation de la mémoire, ce qui en fait une mesure difficile pour comprendre l’utilisation de la mémoire. La métrique des données de mémoire n’est actuellement pas disponible par le biais d’Azure Monitor. En revanche, si vous voulez optimiser l’utilisation de la mémoire de votre application, vous pouvez utiliser les données du compteur de performances collectées par Application Insights.
Si vous ne l’avez pas déjà fait, activez Application Insights dans votre application de fonction. Une fois cette intégration activée, vous pouvez interroger ces données de télémétrie dans le portail.
Vous pouvez utiliser Azure Monitor Metrics Explorer dans le portail Azure ou les API REST pour obtenir ces données Monitor Metrics.
Déterminer l’utilisation de la mémoire
Sous Supervision, sélectionnez Logs (Analytics), puis copiez la requête de télémétrie suivante et collez-la dans la fenêtre de requête, puis sélectionnez Exécuter. Cette requête retourne l’utilisation totale de la mémoire pour chaque durée échantillonnée.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
Les résultats sont semblables à l’exemple qui suit :
| Horodatage [UTC] | name | value |
|---|---|---|
| 12/09/2019, 01:05:14.947 | Octets privés | 209 932 288 |
| 12/09/2019, 01:06:14.994 | Octets privés | 212 189 184 |
| 12/09/2019, 01:06:30.010 | Octets privés | 231 714 816 |
| 12/09/2019, 01:07:15.040 | Octets privés | 210 591 744 |
| 12/09/2019, 01:12:16.285 | Octets privés | 216 285 184 |
| 12/09/2019, 01:12:31.376 | Octets privés | 235 806 720 |
Déterminer la durée
Azure Monitor effectue le suivi des métriques au niveau de la ressource, qui, pour Functions, correspond à l’application de fonction. L’intégration à Application Insights émet des métriques par fonction. Voici un exemple de requête analytique pour obtenir la durée moyenne d’une fonction :
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| name | averageDurationMilliseconds |
|---|---|
| QueueTrigger AvgDurationMs | 16,087 |
| QueueTrigger MaxDurationMs | 90,249 |
| QueueTrigger MinDurationMs | 8,522 |