Estimation des coûts d’un plan Consommation

Il existe actuellement trois types de plans d’hébergement pour une application qui s’exécute dans Azure Functions, chaque plan ayant son propre modèle de tarifs :

Plan Description
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.
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 un accès au 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.

Vous avez choisi le plan qui répond le mieux à vos besoins de performance et à votre budget. Pour en savoir plus, voir Mise à l’échelle et hébergement d’Azure Functions.

Cet article a trait uniquement au plan Consommation, car celui-ci entraîne des coûts variables. Cet article remplace l’article Consumption plan cost billing FAQ.

Durable Functions peut également s’exécuter dans un plan Consommation. Pour en savoir plus sur les considérations financières lors de l’utilisation de Durable Functions, consultez Facturation Durable Functions.

Coûts d’un plan de consommation

Le coût de l’exécution d’une fonction unique se mesure en Go-secondes. Le coût d’exécution est calculé en combinant l’utilisation de sa mémoire et sa durée d’exécution. Une fonction qui s’exécute plus longtemps coûte plus cher, tout comme une fonction qui consomme plus de mémoire.

Imaginez le cas où la quantité de mémoire utilisée par la fonction reste constante. Dans ce cas, le calcul du coût est une simple multiplication. Par exemple, supposons que votre fonction a consommé 0,5 Go pendant 3 secondes. Ainsi, le coût d’exécution s’élève à 0.5GB * 3s = 1.5 GB-seconds.

Étant donné que l’utilisation de la mémoire change au fil du temps, le calcul correspond au fond à l’intégrale de l’utilisation de la mémoire au fil du temps. Le système effectue ce calcul en échantillonnant l’utilisation de la mémoire du processus (avec les processus enfants) à intervalles réguliers. Comme mentionné dans la page des tarifs, l’utilisation de la mémoire est arrondie au compartiment de 128 Mo le plus proche. Quand votre processus utilise 160 Mo, vous êtes facturé pour 256 Mo. Le calcul prend en compte la concurrence, à savoir l’exécution de plusieurs fonctions simultanées dans le même processus.

Notes

Alors que l’utilisation du processeur n’est pas directement prise en compte dans le coût d’exécution, elle peut exercer un impact sur le coût quand elle affecte la durée d’exécution de la fonction.

Pour une fonction déclenchée par HTTP, quand une erreur se produit avant le début de l’exécution du code de votre fonction, vous n’êtes pas facturé pour une exécution. Cela signifie que les réponses 401 de la plateforme en raison de la validation de la clé API ou de la fonctionnalité d’authentification/d’autorisation d’App Service ne sont pas comptabilisées par rapport au coût d’exécution. De même, les réponses de code d’état 5xx ne sont pas comptabilisées lorsqu’elles se produisent dans la plateforme avant une fonction qui traite la requête. Une réponse 5xx générée par la plateforme après le début de l’exécution du code de votre fonction est toujours comptabilisée comme une exécution, même si l’erreur n’est pas déclenchée par le code de votre fonction.

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. Lors du calcul des tarifs 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 des services supplémentaires.

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 exercer un impact 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 (await en 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.

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.

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

  2. Dans le panneau de gauche, faites défiler vers le bas jusqu’à Supervision et choisissez Mesures.

  3. À 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.

    Define a functions app metric to add to the chart

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

Graph of function execution counts and execution units

É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

Étapes suivantes