Partager via

Estimation des coûts basés sur la consommation

Cet article explique comment estimer les coûts du plan pour le plan Flex Consumption et le plan de consommation hérité.

Choisissez l’option d’hébergement qui prend le mieux en charge la fonctionnalité, les performances et les exigences de coût pour vos exécutions de fonction. Pour plus d’informations, consultez Mise à l’échelle et hébergement d’Azure Functions.

Cet article se concentre sur les deux plans de consommation, car la facturation dans ces plans dépend de périodes actives d’exécutions à l’intérieur de chaque instance.

Fournit une mise à l’échelle horizontale rapide, avec des options de calcul flexibles, l’intégration de réseau virtuel et une prise en charge complète des connexions à l’aide de l’authentification Microsoft Entra ID. Dans ce plan, les instances effectuent un scale-out dynamique en fonction de la concurrence configurée par instance, des événements entrants et des charges de travail par fonction pour optimiser l’efficacité. Flex Consumption est le plan recommandé pour l’hébergement serverless. Pour plus d’informations, consultez l’hébergement du plan de consommation Flex d’Azure Functions.

Durable Functions peut également s’exécuter dans ces deux plans. Pour plus d’informations sur les considérations relatives aux coûts 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 Descriptif
À 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 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.

Pour obtenir les informations les plus récentes sur la tarification de l’exécution, les coûts de référence de « toujours prêtes » et les octrois gratuits pour les exécutions à la demande, consultez la page de tarification d’Azure Functions.

Ce diagramme montre comment les coûts à la demande sont déterminés dans ce plan :

Graphique des coûts du plan Flex Consumption à la demande en fonction de la charge (nombre d’instances) et du temps.

En plus du temps d’exécution, lorsque vous utilisez une ou plusieurs instances toujours prêtes, vous payez 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

Cet article utilise la tarification à la demande pour vous aider à comprendre les exemples de calculs. Vérifiez toujours les coûts actuels sur 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 Consumption.

Considérez une application de fonction qui a uniquement des déclencheurs HTTP avec 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.
  • La taille de mémoire de l’instance est de 2 048 Mo.
  • Vous ne configurez pas d'instances toujours prêtes, ce qui signifie que l’application peut être mise à l’échelle jusqu'à zéro.

Dans une situation comme 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. Cette limitation signifie que vous pouvez mieux distribuer chaque requête à sa propre instance afin que les requêtes se terminent aussi rapidement que possible sans conflit. Dans ce scénario, définissez 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 unique active en permanence est 2 GB * 3600 s = 7200 GB-s. En supposant un taux d’exécution à la demande de 0,000026 Go (sans subvention gratuite appliquée), le coût devient $0.1872 USD par heure par instance. Étant donné que l’application liée au processeur est mise à l'échelle pour atteindre 10 instances, le taux horaire total d’exécution est $1.872 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,000 ou 0.144 million exécutions par heure. En supposant un tarif à la demande de $0.40 par million d’exécutions, le coût horaire total (sans octroi) des exécutions est de 0.144 * $0.40, ce qui correspond à $0.0576 par heure.

    Dans ce scénario, le coût horaire total d’exécution à la demande sur 10 instances est $1.872 + $0.0576s = $1.9296 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.1872 USD par 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,000 0,144 millions d’exécutions par heure. Dans ce cas, le coût horaire total (octroi gratuit) des exécutions est de 0.144 * $0.40, soit $0.0576 par heure.

    Dans ce scénario, le coût horaire total d’exécution à la demande d’une seule instance est $0.1872 + $0.0576 = $0.245 USD.

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 et la sortie d’écriture dans vos liaisons de fonction compte comme temps 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 : l’heure à laquelle votre fonction attend les résultats d’une requête asynchrone (await en C#) compte comme temps 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 passe au fil du temps en termes d’activité processeur n’est pas pris en compte dans le calcul. Vous pouvez éventuellement réduire les coûts pendant les opérations asynchrones en utilisant Durable Functions. Vous n’êtes pas facturé pour le temps d’attente passé dans les fonctions d’orchestrateur.

Affichage et estimation des coûts à partir des métriques

Dans votre facture, vous pouvez afficher les données relatives aux coûts ainsi que les coûts facturés réels. En revanche, ces données de facture sont un agrégat mensuel correspondant à une période de facturation passée.

Cette section vous montre comment utiliser des métriques, à la fois au niveau de l’application et des exécutions de fonction, pour estimer les coûts d’exécution de vos applications de fonction.

Métriques au niveau de l’application de fonction

Les métriques au niveau de l’application disponibles pour votre application dépendent du type de plan de consommation que vous utilisez.

Ces métriques Azure Monitor sont liées à la facturation du plan Flex Consumption :

Unité de mesure Descriptif Calcul du compteur
Nombre d’exécutions de fonction à la demande Nombre total d’exécutions de fonction dans les instances à la demande. OnDemandFunctionExecutionCount est lié au compteur Exécutions totales à la demande.
Nombre d’exécutions de fonction Always Ready Nombre total d’exécutions de fonction dans des instances toujours prêtes. AlwaysReadyFunctionExecutionCount est lié au compteur du Nombre total d’exécutions toujours prêtes.
Unités d’exécution de fonction à la demande Nombre total de mo-millisecondes provenant d’instances à la demande lors de l’exécution active de fonctions. OnDemandFunctionExecutionUnits / 1,024,000 est le compteur temps d’exécution à la demande, en Go-secondes.
Unités d’exécution de fonction Always Ready Nombre total de mo-millisecondes provenant d’instances toujours prêtes lors de l’exécution active des fonctions. AlwaysReadyFunctionExecutionUnits / 1,024,000 est le compteur de Temps d'exécution Toujours Disponible, en Go-secondes.
Unités toujours prêtes Total en Mo-millisecondes des instances toujours prêtes affectées à l’application, que les fonctions soient activement exécutées ou non. AlwaysReadyUnits / 1,024,000 est le compteur Ligne de base des instances toujours prêtes, en Go-secondes.

Pour plus d’informations, consultez la référence des données de surveillance Azure Functions.

Pour mieux comprendre les coûts de vos fonctions, utilisez Azure Monitor pour afficher les métriques liées aux coûts générées par vos applications de fonction. Vous pouvez afficher les métriques Monitor à l’aide de l’un des outils suivants :

Utilisez l’Explorateur de métriques Azure Monitor pour afficher les données relatives aux coûts pour vos applications de fonction de plan Flex Consumption dans un format graphique.

  1. Dans le portail Azure, accédez à votre application de fonction.

  2. Dans le volet gauche, faites défiler jusqu’à Surveillance et sélectionnez Métriques.

  3. Dans Métrique, sélectionnez Nombre d’exécutions de fonction à la demande et Somme pour l’agrégation. Cette sélection ajoute la somme des nombres d’exécutions pendant la période choisie au graphique.

  4. Sélectionnez Ajouter une métrique et ajoutez des unités d’exécution de fonction à la demande, le compteur d'exécution de fonction toujours prête, les unités d'exécution de fonction toujours prêtes, et les unités toujours prêtes au graphique.

Le graphique obtenu contient les totaux pour toutes les métriques d’exécution Flex Consumption dans l’intervalle de temps choisi, qui dans cet exemple est un intervalle de temps personnalisé.

Graphique des nombres d’exécutions de fonction à la demande et des unités d’exécution de fonction à la demande.

Étant donné que le nombre d’unités d’exécution de fonction à la demande est supérieur au nombre d’exécutions de fonction à la demande et qu’il n’y avait pas toujours d’instances prêtes sur l’application, le graphique affiche simplement les unités d’exécution de fonction à la demande.

Ce graphique montre un total de 3,54 milliards On Demand Function Execution Units consommés dans une période de 16 minutes, mesurée en millisecondes mo. Pour convertir en go-secondes, divisez-les de 1 024 000. Dans cet exemple, l’application de fonction a consommé 3,540,000,000 / 1,024,000 = 3,457.03 Go-secondes. Vous pouvez prendre cette valeur et la multiplier par le prix actuel du temps d’exécution à la demande sur la page de tarification Functions, ce qui vous donne le coût de ces 16 minutes, en supposant que vous avez déjà utilisé n’importe quelle allocation gratuite de temps d’exécution. Vous pouvez appliquer ce même calcul avec la métrique Unités d’exécution de fonctions toujours prêtes et le coût du compteur de facturation Temps d’exécution toujours prêt, ainsi qu’avec la métrique Unités toujours prêtes et le coût du compteur de facturation Base de référence toujours prête, afin de déterminer les coûts en Go-secondes des instances toujours prêtes.

Pour calculer le coût total des exécutions à la demande, prenez la somme du nombre d’exécutions de fonction à la demande pour la même période, convertissez en millions, puis multipliez par le prix total des exécutions à la demande dans la page de tarification Functions. Par exemple, 2 100 exécutions dans l’exemple ci-dessus sont converties en 0.0021 millions d’exécutions. Vous pouvez utiliser ce même calcul avec la métrique Always Ready Function Execution Count et le compteur de facturation Always Ready Total Executions pour déterminer le coût des exécutions gérées par une instance toujours prête.

Métriques au niveau de la fonction

L’utilisation de la mémoire est importante lors de l’estimation des coûts de vos exécutions de fonction. Toutefois, la façon dont l’utilisation de la mémoire a un impact sur vos coûts dépend du type de plan spécifique :

Dans le plan Flex Consumption, vous payez le temps que l’instance s’exécute en fonction de la taille de votre instance choisie, qui a une limite de mémoire définie. Pour plus d'informations, consultez Facturation.

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] nom 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
nom duréeMoyenneMilliseconds
QueueTrigger AvgDurationMs 16,087
QueueTrigger MaxDurationMs 90,249
QueueTrigger MinDurationMs 8,522

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 Descriptif
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.

Étapes suivantes

En savoir plus sur la supervision des applications de fonction

  • Last updated on