Facturation Durable Functions
Durable Functions suit le même modèle de facturation qu’Azure Functions. Pour plus d’informations, consultez Tarification d’Azure Functions.
Lors de l’exécution de fonctions d’orchestrateur dans le plan de consommation Azure Functions, vous devez avoir conscience de certains comportements de facturation. Les sections suivantes décrivent ces comportements et leur incidence plus en détail.
Facturation de la relecture de fonctions orchestrator
Les fonctions d’orchestrateur peuvent être relues plusieurs fois pendant toute la durée de vie d’une orchestration. Chaque relecture est considérée par le runtime Azure Functions comme un appel de fonction distinct. C’est pourquoi, dans le plan de Consommation Azure Functions, vous êtes facturé pour chaque relecture d’une fonction d’orchestrateur. Les autres types de plans ne facturent pas la relecture des fonctions d’orchestrateur.
Attente et interruption dans les fonctions orchestrator
Lorsqu’une fonction orchestrator attend la fin d’une tâche asynchrone, le runtime considère que cet appel de fonction particulier doit être terminé. La facturation de la fonction d’orchestrateur s’arrête à ce stade. Elle ne reprend qu’à la relecture de la fonction d’orchestrateur suivante. Vous n’êtes pas facturé pour le temps d’attente ou d’interruption dans une fonction orchestrator.
Notes
Les fonctions qui appellent d’autres fonctions sont considérées par certains comme un anti-modèle serverless. Cela est dû à un problème appelé double facturation. Quand une fonction appelle une autre fonction directement, elles s’exécutent toutes les deux en même temps. La fonction appelée exécute du code activement pendant que la fonction appelante attend une réponse. Dans ce cas, vous devez payer pour le temps passé par la fonction appelante à attendre que la fonction appelée s’exécute.
Il n’existe pas de double facturation dans les fonctions d’orchestrateur. La facturation de la fonction d’orchestrateur s’arrête pendant qu’elle attend le résultat d’une fonction d’activité ou d’une fonction de sous-orchestration.
Interrogation HTTP durable
Les fonctions d’orchestrateur peuvent effectuer des appels HTTP longs à des points de terminaison externes, comme décrit dans l’article Fonctionnalités HTTP. Les API « call HTTP » peuvent interroger en interne un point de terminaison HTTP en suivant le modèle asynchrone 202.
Il n’existe actuellement pas de facturation directe pour les opérations d’interrogation HTTP internes. Toutefois, l’interrogation interne peut entraîner la relecture périodique de la fonction d’orchestrateur. Ces relectures de fonction internes font l’objet d’une facturation de frais standard.
Transactions de stockage Azure
Durable Functions utilise par défaut le Stockage Azure pour maintenir l’état persistant, traiter les messages et gérer les partitions par le biais de baux d’objets blob. Comme vous détenez ce compte de stockage, tous les coûts de transaction sont facturés à votre abonnement Azure. Pour plus d’informations sur les artefacts du Stockage Azure utilisés par Durable Functions, consultez l’article Hubs de tâches.
Plusieurs facteurs contribuent aux coûts du Stockage Azure réels engendrés par votre application Durable Functions :
- Une application de fonction est associée à un seul hub de tâches, qui partage un ensemble de ressources de Stockage Azure. Ces ressources sont utilisées par toutes les fonctions durables dans une application de fonction. Le nombre réel de fonctions dans l’application de fonction n’a aucune incidence sur les coûts des transactions du Stockage Azure.
- Chaque instance d’application de fonction interroge en interne plusieurs files d’attente dans le compte de stockage à l’aide d’un algorithme d’interrogation avec interruption exponentielle. Une instance d’application inactive interroge les files d’attente moins souvent qu’une application active, ce qui réduit les coûts de transaction. Pour plus d’informations sur Durable Functions comportement d’interrogation de file d’attente lors de l’utilisation du fournisseur de stockage Azure, consultez la section interrogation de file d’attente de la documentation du fournisseur de stockage Azure.
- En cas d’exécution dans les plans Consommation Azure Functions ou Premium, le contrôleur de mise à l’échelle Azure Functions interroge régulièrement toutes les files d’attente de hub de tâches en arrière-plan. En cas d’échelle faible à modérée d’une application de fonction, une seule instance de contrôleur d’échelle interroge ces files d’attente. Si l’application de fonction est étendue à un grand nombre d’instances, d’autres instances de contrôleur d’échelle peuvent être ajoutées. Ces instances de contrôleur d’échelle supplémentaires peuvent augmenter les coûts totaux de transaction de file d’attente.
- Chaque instance d’application de fonction est en concurrence pour un ensemble de baux d’objets blob. Ces instances effectuent régulièrement des appels au service BLOB Azure pour renouveler les baux détenus ou tenter d’acquérir de nouveaux baux. Le nombre de partitions configurées du hub de tâches détermine le nombre de baux d’objets blob. Un scale-out vers un plus grand nombre d’instances d’application de fonction augmente probablement les coûts de transaction du Stockage Azure associés à ces opérations de bail.
Vous trouverez de plus amples informations sur les tarifs du Stockage Azure dans la documentation sur la tarification Stockage Azure.