Bonnes pratiques et outils de diagnostic Durable Functions

Article
05/08/2024

Cet article détaille quelques bonnes pratiques lors de l’utilisation de Durable Functions. Il décrit également différents outils pour aider à diagnostiquer les problèmes pendant le développement, les tests et l’utilisation en production.

Bonnes pratiques

Utiliser la dernière version de l’extension Durable Functions et du kit de développement logiciel (SDK)

Une application de fonction utilise deux composants pour exécuter Durable Functions. L’un est le kit SDK Durable Functions qui vous permet d’écrire des fonctions d’orchestrateur, d’activité et d’entité à l’aide de votre langage de programmation cible. L’autre est l’extension Durable, qui est le composant runtime qui exécute réellement le code. À l’exception des applications in-process .NET, le kit de développement logiciel (SDK) et l’extension sont versionnés indépendamment.

Le fait de rester à jour avec la dernière extension et le kit de développement logiciel (SDK) garantissent que votre application bénéficie des dernières améliorations des performances, des fonctionnalités et des correctifs de bogues les plus récents. La mise à niveau vers les dernières versions garantit également que Microsoft peut collecter les dernières données de télémétrie de diagnostic pour accélérer le processus d’investigation lorsque vous ouvrez un cas de support avec Azure.

Pour obtenir des instructions sur l’obtention de la dernière version de l’extension, consultez Mettre à niveau une version d’extension durable.
Pour vous assurer que vous utilisez la dernière version du kit de développement logiciel (SDK), vérifiez le gestionnaire de package du langage que vous utilisez.

Respecter les contraintes de code Durable Functions

Le comportement de réexécution du code d’orchestrateur crée des contraintes sur le type de code qui peut être écrit dans une fonction d’orchestrateur. Un exemple de contrainte est que votre fonction d’orchestrateur doit utiliser des API déterministes afin que chaque fois qu’elle est relue, elle produise le même résultat.

Notes

L’Analyseur Roslyn Durable Functions est un analyseur de code dynamique qui guide les utilisateurs C# pour les aider à respecter les contraintes de code spécifiques à Durable Functions. Consultez Analyseur Roslyn Durable Functions pour obtenir des instructions sur la façon de l’activer sur Visual Studio et Visual Studio Code.

Familiarisez-vous avec les paramètres de performances Azure Functions de votre langage de programmation

À l’aide des paramètres par défaut, le runtime de langage que vous sélectionnez peut imposer des restrictions concurrentielles strictes à vos fonctions. Par exemple : n’autoriser qu’une fonction à s’exécuter à la fois sur une machine virtuelle donnée. Ces restrictions peuvent généralement être assouplies réglant les paramètres de concurrence et de performances de votre langage. Si vous souhaitez optimiser les performances de votre application Durable Functions, vous devez vous familiariser avec ces paramètres.

Vous trouverez ci-dessous une liste non exhaustive de quelques langages qui tirent souvent parti du réglage de leurs paramètres de performances et concurrentiels, ainsi que les instructions.

Garantir des noms de hubs de tâches uniques par application

Plusieurs applications Durable Function peuvent partager le même compte de stockage. Par défaut, le nom de l’application est utilisé comme nom du hub de tâches, ce qui garantit que le partage accidentel de hubs de tâches ne se produira pas. Si vous devez configurer explicitement les noms du hub de tâches pour vos applications dans host.json, vous devez vous assurer que les noms sont uniques. Dans le cas contraire, les applications seront en concurrence pour les messages, ce qui pourrait entraîner un comportement inhabituel, y compris des orchestrations qui se retrouveraient inopinément « bloquées » dans l’état En attente ou En cours d’exécution.

La seule exception est si vous déployez des copies de la même application dans plusieurs régions ; dans ce cas, vous pouvez utiliser le même hub de tâches pour les copies.

Suivez les instructions lors du déploiement de modifications de code sur des orchestrateurs en cours d’exécution

Au cours du cycle de vie d’une application, des fonctions seront nécessairement ajoutées, retirées ou modifiées. Parmi les exemples de modifications cassantes courantes, on peut citer la modification des signatures d’activité ou de fonction d’entité et la modification de la logique d’orchestrateur. Ces modifications sont un problème lorsqu’elles affectent des orchestrations qui sont toujours en cours d’exécution. En cas de déploiement incorrect, les modifications du code peuvent entraîner l’échec des orchestrations avec une erreur non déterministe, le blocage indéfini, la dégradation des performances, etc. Reportez-vous aux stratégies d’atténuation recommandées lors de l’apport de modifications de code susceptibles d’avoir un impact sur l’exécution des orchestrations.

Faites en sorte que les entrées et sorties de fonction soient aussi petites que possible

Vous pouvez rencontrer des problèmes de mémoire si vous fournissez des entrées et des sorties volumineuses vers et depuis des API Durable Functions.

Les entrées et sorties des API Durable Functions sont sérialisées dans l’historique de l’orchestration. Cela signifie que les entrées et sorties volumineuses peuvent, au fil du temps, contribuer considérablement à un historique d’orchestrateur sans limite, ce qui risque de provoquer des exceptions de mémoire pendant la relecture.

Pour atténuer l’impact des entrées et sorties volumineuses sur les API, vous pouvez choisir de déléguer certains travaux à des sous-orchestrateurs. Cela permet d’équilibrer la charge de la mémoire de l’historique d’un seul orchestrateur sur plusieurs orchestrateurs, ce qui permet de garder l’empreinte mémoire des historiques individuels faible.

Cela dit, la meilleure pratique pour traiter des données volumineuses est de les conserver dans un stockage externe et de matérialiser uniquement ces données à l’intérieur des activités, si nécessaire. Lorsque vous utilisez cette approche, au lieu de communiquer les données elles-mêmes en tant qu’entrées et/ou sorties de Durable Functions API, vous pouvez transmettre un identificateur léger qui vous permet de récupérer ces données à partir d’un stockage externe si nécessaire dans vos activités.

Gardez les données d'entité petites

Tout comme pour les entrées et sorties des API Durable Functions, si l’état explicite d’une entité est trop volumineux, vous pouvez rencontrer des problèmes de mémoire. En particulier, un état d'entité doit être sérialisé et désérialisé du stockage à toute demande, de sorte que les grands états ajoutent une latence de sérialisation à chaque appel. Par conséquent, si une entité a besoin de suivre des données volumineuses, il est recommandé de décharger les données vers un stockage externe et de suivre un identifiant léger dans l'entité qui vous permet de matérialiser les données du stockage en cas de besoin.

Réglez vos paramètres concurrentiels Durable Functions

Un seul instance de travail peut exécuter simultanément plusieurs éléments de travail pour augmenter l’efficacité. Toutefois, le traitement simultané d’un trop grand nombre d’éléments de travail risque d’épuiser les ressources telles que la capacité du processeur, les connexions réseau, etc. Dans de nombreux cas, cela ne doit pas être un problème, car la mise à l’échelle et la limitation des éléments de travail sont gérés automatiquement pour vous. Cela dit, si vous rencontrez des problèmes de performances (par exemple, les orchestrateurs prennent trop de temps, sont bloqués en attente, etc.) ou si vous effectuez des tests de performances, vous pouvez configurer des limites concurrentielles dans le fichier host.json.

Notes

Cela ne remplace pas le réglage des paramètres de performances et de concurrence de votre runtime de langage dans Azure Functions. Les paramètres de concurrence Durable Functions déterminent uniquement la quantité de travail qui peut être affectée à une machine virtuelle donnée à la fois, mais ils ne déterminent pas le degré de parallélisme dans le traitement qui fonctionne à l’intérieur de la machine virtuelle. Ce dernier nécessite un réglage précis des paramètres de performances du runtime de langage.

Utiliser des noms uniques pour vos événements externes

Comme pour les fonctions d’activité, les événements externes ont une garantie de remise au moins une fois. Cela signifie que, dans certaines rares conditions (qui peuvent se produire pendant les redémarrages, la mise à l’échelle, les incidents, etc.), votre application peut recevoir des doublons du même événement externe. Par conséquent, nous recommandons que les événements externes contiennent un ID qui leur permet d’être dédupliqués manuellement dans les orchestrateurs.

Remarque

Le fournisseur de stockage MSSQL consomme des événements externes et met à jour l’état de l’orchestrateur de façon transactionnelle. Dans ce back-end, il ne doit donc pas y avoir de risque de présence de doublons d’événements, contrairement au fournisseur de stockage Stockage Azure par défaut. Cela dit, il est toujours recommandé que les événements externes aient des noms uniques afin que le code soit portable d’un back-end à un autre.

Investissez dans les tests de résistance

Comme pour tout ce qui concerne les performances, les paramètres de concurrence idéaux et l'architecture de votre application dépendent en fin de compte de la charge de travail de votre application. Par conséquent, il est recommandé aux utilisateurs d'investir dans un harnais de test de performances qui simule leur charge de travail attendue et de l'utiliser pour exécuter des expériences de performances et de fiabilité pour leur application.

Éviter les données sensibles dans les entrées, les sorties et les exceptions

Les entrées et sorties (y compris les exceptions) vers et à partir des API Durable Functions persistent durablement dans le fournisseur de stockage de votre choix. Si ces entrées, sorties ou exceptions incluent des données sensibles telles que des secrets, des chaînes de connexion ou des informations d’identification personnelle, toute personne disposant d’un accès en lecture aux ressources de votre fournisseur de stockage peut y accéder. Pour traiter les données sensibles de manière sécurisée, il est recommandé aux utilisateurs d’extraire ces informations dans les fonctions d'activité à partir d’Azure Key Vault ou de variables d’environnement, et de ne jamais communiquer ces données directement aux orchestrateurs ou aux entités. Ces précautions devraient prévenir toute fuite de données sensibles vers vos ressources de stockage.

Remarque

Ces conseils s’appliquent aussi à l’API d’orchestrateur CallHttp, qui préserve également ses charges utiles de requête et de réponse dans le stockage. Si vos points de terminaison HTTP cibles nécessitent une authentification pouvant être sensible, il est recommandé que les utilisateurs implémentent l’appel HTTP eux-mêmes au sein d’une activité, ou qu’ils utilisent la prise en charge des identités managées intégrées proposée par CallHttp, qui ne conserve pas les informations d’identification dans le stockage.

Conseil

De même, évitez de journaliser les données contenant des secrets, car toute personne disposant d’un accès en lecture à vos journaux d’activité (par exemple dans Application Insights) serait en mesure d’obtenir ces secrets.

Outils de diagnostic

Plusieurs outils sont disponibles pour vous aider à diagnostiquer les problèmes.

Durable Functions et les journaux d’infrastructure des tâches durables

Extension Durable Functions

L’extension Durable émet des événements de suivi vous permettant de tracer l’exécution de bout en bout d’une orchestration. Ces événements de suivi sont accessibles et interrogés à l’aide de l’outil Application Insights Analytics dans le portail Azure. Le niveau de détail des données de suivi transmises peut être configuré dans la section logger (Functions 1.x) ou logging (Functions 2.0) du fichier host.json. Consultez les détails de configuration.

Infrastructure des tâches durable

À partir de la version 2.3.0 de l’extension Durable, les journaux émis par l’infrastructure Durable Task Framework (DTFx) sous-jacentes sont également disponibles pour la collecte. Consultez les détails sur l’activation de ces journaux.

Portail Azure

Diagnostiquer et résoudre les problèmes

Azure Function App Diagnostics est une ressource utile sur Portail Azure pour surveiller et diagnostiquer les problèmes potentiels dans votre application. Il fournit également des suggestions pour aider à résoudre les problèmes en fonction du diagnostic. Consultez Diagnostics d’application de fonction Azure.

Traces d’orchestration Durable Functions

Le Portail Azure fournit des détails sur les traces d’orchestration pour vous aider à comprendre les statuts de chaque instance d’orchestration et à suivre l’exécution de bout en bout. Lorsque vous examinez la liste des fonctions à l’intérieur de votre application Azure Functions, vous voyez une colonne Superviser qui contient des liens vers les traces. Vous devez activer Applications Insights pour que votre application obtienne ces informations.

Extension Durable Functions Monitor

Il s’agit d’une extension Visual Studio Code qui fournit une interface utilisateur pour la surveillance, la gestion et le débogage de vos instances d’orchestration.

Analyseur Roslyn

Support

Pour les questions et le support, vous pouvez signaler un problème dans l’un des dépôts GitHub ci-dessous. Lorsque vous signalez un bogue dans Azure, inclure des informations telles que les ID des instance affectés, les intervalles de temps UTC montrant le problème, le nom de l’application (si possible) et la région de déploiement accélèrent considérablement les enquêtes.

Partager via

Bonnes pratiques et outils de diagnostic Durable Functions