Partager via

Recommandations pour le développement de travaux en arrière-plan

  • Article

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :07 Renforcez la résilience et la récupération de votre charge de travail en implémentant des mesures d’auto-préservation et d’auto-réparation. Générez des fonctionnalités dans la solution à l’aide de modèles de fiabilité basés sur l’infrastructure et de modèles de conception basés sur le logiciel pour gérer les défaillances des composants et les erreurs temporaires. Générez des fonctionnalités dans le système pour détecter les défaillances des composants de solution et lancer automatiquement une action corrective pendant que la charge de travail continue à fonctionner à pleine ou réduite.

Guides connexes : Erreurs temporaires | auto-conservation

Ce guide décrit les recommandations relatives au développement de travaux en arrière-plan. Les travaux en arrière-plan s’exécutent automatiquement sans avoir besoin d’interaction utilisateur. De nombreuses applications nécessitent des travaux en arrière-plan qui s’exécutent indépendamment de l’interface utilisateur.

Certains exemples de travaux en arrière-plan incluent des travaux par lots, des tâches de traitement intensives et des processus de longue durée, tels que les flux de travail. L’application démarre le travail et traite les demandes interactives des utilisateurs. Par exemple, si une application doit générer des miniatures d’images que les utilisateurs chargent, une tâche en arrière-plan peut être effectuée pour générer la miniature et l’enregistrer dans le stockage. L’utilisateur n’a pas besoin d’attendre la fin du processus. En guise d’autre exemple, un client place une commande, qui lance un flux de travail en arrière-plan qui traite la commande. Le client continue à parcourir l’application web pendant l’exécution du travail en arrière-plan. Une fois le travail en arrière-plan terminé, il met à jour les données de commande stockées et envoie un e-mail au client pour confirmer la commande.

Les travaux en arrière-plan permettent de réduire la charge sur l’interface utilisateur de l’application, ce qui améliore la disponibilité et réduit le temps de réponse interactif.

Stratégies de conception

Pour choisir la tâche à désigner comme tâche en arrière-plan, déterminez si la tâche s’exécute sans interaction utilisateur et si l’interface utilisateur doit attendre la fin de la tâche. Les tâches qui nécessitent que l’utilisateur ou l’interface utilisateur attendent qu’ils s’exécutent ne soient généralement pas des travaux en arrière-plan appropriés.

Évaluer le besoin de travaux en arrière-plan

Voici quelques exemples de travaux en arrière-plan :

  • Travaux nécessitant beaucoup de ressources processeur, comme les calculs mathématiques, les analyses de modèles structurels, etc.

  • Tâches gourmandes en E/S, telles que l’exécution d’une série de transactions de stockage ou l’indexation de fichiers.

  • Travaux de traitement par lots, comme les opérations de traitement planifiées ou les mises à jour de données exécutées la nuit.

  • Flux de travail longs, tels que le traitement des commandes ou le provisionnement de services et de systèmes.

  • Traitement des données sensibles qui transfère la tâche à un emplacement plus sécurisé pour le traitement. Par exemple, vous devez éviter de traiter des données sensibles dans une application web. Utilisez plutôt un modèle tel que le modèle opérateur de contrôle d’appels pour transférer les données à un processus en arrière-plan isolé qui peut accéder au stockage protégé.

Choisir les déclencheurs appropriés

Lancer des travaux en arrière-plan avec :

  • Déclencheurs pilotés par les événements : un événement, généralement une action utilisateur ou une étape dans un flux de travail, déclenche la tâche.

  • Déclencheurs pilotés par la planification : une planification basée sur un minuteur appelle la tâche. Le travail peut être planifié périodiquement ou pour une seule exécution.

Déclencheurs pilotés par les événements

Une action déclenche un appel piloté par les événements qui démarre la tâche en arrière-plan. Voici quelques exemples de déclencheurs pilotés par les événements :

  • L’interface utilisateur ou un travail différent place un message dans une file d’attente, comme décrit dans le style architectural Web-Queue-Worker. Le message contient des données sur une action effectuée précédemment, telle qu’un client qui a passé une commande. Le travail en arrière-plan surveille cette file d’attente et détecte l’arrivée d’un nouveau message. Il lit le message et utilise les données du message comme entrée pour le travail en arrière-plan. Ce modèle est appelé communication asynchrone basée sur les messages.

  • L’interface utilisateur ou un autre travail enregistre ou met à jour une valeur qui se trouve dans le stockage. Le travail en arrière-plan surveille le stockage et détecte les modifications. Il lit les données et les utilise comme entrée pour la tâche en arrière-plan.

  • L’interface utilisateur ou un autre travail effectue une requête à un point de terminaison, tel qu’un URI HTTPS ou une API exposée en tant que service web. Dans le cadre de la requête, l’interface utilisateur ou le travail transfère les données requises par la tâche en arrière-plan. Le point de terminaison ou le service web appelle la tâche en arrière-plan, qui utilise les données en tant qu’entrée.

D’autres exemples de tâches adaptées aux appels pilotés par les événements incluent le traitement des images, les flux de travail, l’envoi d’informations aux services distants, l’envoi de messages électroniques et l’approvisionnement de nouveaux utilisateurs dans des applications mutualisées.

Déclencheurs pilotés par les planifications

Un minuteur déclenche un appel piloté par la planification qui démarre la tâche en arrière-plan. Voici quelques exemples de déclencheurs pilotés par la planification :

  • Un minuteur qui s’exécute localement dans l’application ou dans le cadre du système d’exploitation de l’application appelle régulièrement une tâche en arrière-plan.

  • Minuteur qui s’exécute dans une autre application, comme Azure Logic Apps, envoie régulièrement une demande à une API ou un service web. Le service web ou l’API appelle la tâche en arrière-plan.

  • Un processus ou une application distinct démarre un minuteur qui appelle la tâche en arrière-plan après un délai ou à un moment spécifique.

D’autres exemples de tâches adaptées aux appels pilotés par la planification incluent des routines de traitement par lots (telles que la mise à jour des listes de produits connexes pour les clients en fonction de leur comportement récent), les tâches de traitement des données de routine (telles que la mise à jour d’index ou la génération de résultats cumulés), l’analyse des données pour les rapports quotidiens, le nettoyage de la rétention des données et les vérifications de cohérence des données.

Si vous utilisez une tâche pilotée par la planification qui doit s’exécuter en tant qu’instance unique, passez en revue les considérations suivantes :

  • Si l’instance de calcul qui exécute le planificateur, telle qu’une machine virtuelle qui utilise des tâches planifiées Windows, est mise à l’échelle, vous exécutez plusieurs instances du planificateur. Plusieurs instances du planificateur peuvent démarrer plusieurs instances de la tâche. Pour plus d’informations, consultez Qu’est-ce que signifie idempotent dans les systèmes logiciels ?

  • Si les tâches s’exécutent plus longtemps que la période entre les événements du planificateur, le planificateur peut démarrer une autre instance de la tâche pendant l’exécution de la tâche précédente.

Retourner des données à la charge de travail

Les travaux en arrière-plan s’exécutent de manière asynchrone dans un processus distinct, ou même dans un emplacement distinct, de l’interface utilisateur ou du processus qui a appelé le travail en arrière-plan. Dans l’idéal, les travaux en arrière-plan sont déclenchés et oublient les opérations. Leur progression du runtime n’a pas d’effet sur l’interface utilisateur ou le processus appelant, ce qui signifie que le processus appelant n’attend pas que les tâches se terminent. L’interface utilisateur et le processus appelant ne peuvent pas détecter quand la tâche se termine.

Si vous avez besoin d’une tâche en arrière-plan pour communiquer avec la tâche appelante pour indiquer la progression ou l’achèvement, vous devez implémenter un mécanisme. Voici quelques exemples :

  • Écrivez une valeur d’indicateur d’état dans le stockage accessible à l’interface utilisateur ou à la tâche de l’appelant, qui peut surveiller ou vérifier cette valeur. Les autres données retournées par la tâche en arrière-plan à l’appelant peuvent être placées dans le même stockage.

  • Établissez une file d’attente de réponse que l’interface utilisateur ou l’appelant surveille. La tâche en arrière-plan peut envoyer des messages à la file d’attente qui indiquent l’état. Les données renvoyées par la tâche en arrière-plan à l’appelant peuvent être placées dans les messages. Pour Azure Service Bus, utilisez les propriétés et CorrelationId les ReplyTo propriétés pour implémenter cette fonctionnalité.

  • Exposition d’une API ou d’un point de terminaison à partir de la tâche en arrière-plan, à laquelle l’interface utilisateur ou la tâche appelante peut accéder pour obtenir des informations sur l’état. La réponse peut inclure les données retournées par la tâche en arrière-plan à l’appelant.

  • Configurez la tâche en arrière-plan pour rappeler l’interface utilisateur ou l’appelant via une API pour indiquer l’état à des points prédéfinis ou à la fin. Vous pouvez utiliser des événements déclenchés localement ou un mécanisme de publication et d’abonnement. La demande ou la charge utile de l’événement peut inclure les données retournées par la tâche en arrière-plan à l’appelant.

Partitionner des travaux en arrière-plan

Si vous incluez des travaux en arrière-plan dans une instance de calcul existante, réfléchissez à la façon dont ces modifications affectent les attributs de qualité de l’instance de calcul et le travail en arrière-plan. Tenez compte de ces facteurs pour décider s’il faut colocaliser les tâches avec l’instance de calcul existante ou les séparer en une autre instance de calcul :

  • Disponibilité : les tâches en arrière-plan peuvent ne pas avoir besoin du même niveau de disponibilité que d’autres parties de l’application, en particulier l’interface utilisateur et les parties qui impliquent directement l’interaction utilisateur. Les tâches en arrière-plan peuvent avoir une tolérance plus élevée pour la latence, les échecs de connexion retentés et d’autres facteurs qui affectent la disponibilité, car les opérations peuvent être mises en file d’attente. Toutefois, il doit y avoir suffisamment de capacité pour empêcher les requêtes sauvegardées qui peuvent bloquer les files d’attente et affecter l’ensemble de l’application.

  • Scalabilité : les tâches en arrière-plan ont probablement des exigences de scalabilité différentes par rapport à l’interface utilisateur et aux parties interactives de l’application. Vous devrez peut-être mettre à l’échelle l’interface utilisateur pour répondre aux pics de demande. Les tâches en arrière-plan en attente peuvent s’exécuter pendant moins de temps occupés et avec moins d’instances de calcul.

  • Résilience : si une instance de calcul qui héberge uniquement des tâches en arrière-plan échoue, elle risque de ne pas affecter l’ensemble de l’application. Les demandes de ces tâches peuvent être mises en file d’attente ou reportées jusqu’à ce que la tâche soit disponible. Si l’instance de calcul ou les tâches peuvent redémarrer dans un intervalle approprié, cela peut ne pas affecter les utilisateurs de l’application.

  • Sécurité : les tâches en arrière-plan peuvent avoir des exigences de sécurité ou des restrictions différentes par rapport à l’interface utilisateur ou à d’autres parties de l’application. Utilisez une instance de calcul distincte pour spécifier un environnement de sécurité différent pour les tâches. Pour optimiser la sécurité et la séparation, vous pouvez également utiliser des modèles tels que Gatekeeper pour isoler les instances de calcul en arrière-plan de l’interface utilisateur.

  • Performances : choisissez le type d’instance de calcul pour les tâches en arrière-plan qui correspondent spécifiquement aux exigences de performances de la tâche. Vous pouvez utiliser une option de calcul moins coûteuse si les tâches ne nécessitent pas les mêmes fonctionnalités de traitement que l’interface utilisateur. Vous pouvez également utiliser une instance plus grande si les tâches nécessitent plus de capacité et de ressources.

  • Facilité de gestion : les tâches en arrière-plan peuvent avoir un rythme de développement et de déploiement différent par rapport au code d’application principal ou à l’interface utilisateur. Pour simplifier les mises à jour et le contrôle de version, déployez des tâches en arrière-plan sur une instance de calcul distincte.

  • Coût : si vous ajoutez des instances de calcul pour exécuter des tâches en arrière-plan, les coûts d’hébergement augmentent. Examinez attentivement le compromis entre plus de capacité et des coûts supplémentaires.

Pour plus d’informations, consultez le modèle d’élection des dirigeants et le modèle consommateurs concurrents.

Empêcher le conflit de ressources

Si vous avez plusieurs instances d’un travail en arrière-plan, elles peuvent concurrencer l’accès aux ressources et services, tels que les bases de données et le stockage. Cet accès simultané peut entraîner une contention de ressources, ce qui peut entraîner des conflits de disponibilité de service et nuire à l’intégrité des données qui se trouvent dans le stockage. Résolvez la contention des ressources à l’aide d’une approche de verrouillage pessimiste. Cette approche empêche les instances concurrentes d’une tâche d’accéder simultanément à un service ou à endommager les données.

Une autre approche pour résoudre les conflits consiste à définir des tâches en arrière-plan en tant que singleton, afin qu’une seule instance s’exécute. Toutefois, cette approche élimine les avantages en matière de fiabilité et de performances qu’offre une configuration à plusieurs instances. Cet inconvénient est particulièrement vrai si l’interface utilisateur fournit suffisamment de travail pour garder plusieurs tâches en arrière-plan occupées.

Assurez-vous que la tâche en arrière-plan peut redémarrer automatiquement et qu’elle dispose d’une capacité suffisante pour gérer les pics de demande. Allouez une instance de calcul avec suffisamment de ressources, implémentez un mécanisme de mise en file d’attente qui stocke les requêtes à exécuter lorsque la demande diminue ou utilisez une combinaison de ces techniques.

Orchestrer plusieurs tâches

Les tâches en arrière-plan peuvent être complexes et nécessitent l’exécution de plusieurs tâches. Dans ces scénarios, il est courant de diviser la tâche en étapes ou sous-tâches discrètes plus petites que plusieurs consommateurs peuvent exécuter. Les travaux multistep sont plus efficaces et plus flexibles, car les étapes individuelles sont souvent réutilisables dans plusieurs travaux. Il est également facile d’ajouter, de supprimer ou de modifier l’ordre des étapes.

Il peut s’agir d’un défi pour coordonner plusieurs tâches et étapes, mais il existe trois modèles courants pour guider votre solution :

  • Décomposez une tâche en plusieurs étapes réutilisables. Une application peut être nécessaire pour effectuer différentes tâches de complexité différentes sur les informations qu’elle traite. Une approche simple mais inflexible pour implémenter une telle application consiste à effectuer ce traitement en tant que module monolithique. Mais cette approche est susceptible de réduire les opportunités de refactorisation du code, de l’optimiser ou de la réutiliser si l’application nécessite des parties du même traitement ailleurs. Pour plus d’informations, consultez Modèle de canaux et de filtres.

  • Gérez l’orchestration des étapes d’une tâche. Une application peut effectuer des tâches qui comprennent de nombreuses étapes, dont certaines peuvent appeler des services distants ou accéder aux ressources distantes. Parfois, les étapes individuelles sont indépendantes les unes des autres, mais elles sont orchestrées par la logique d’application qui implémente la tâche. Pour plus d’informations, consultez Modèle de superviseur de l’agent du planificateur.

  • Gérez la récupération pour les étapes de tâche qui échouent. Si une ou plusieurs des étapes échouent, une application peut avoir besoin d’annuler le travail effectué par une série d’étapes, ce qui définit ensemble une opération cohérente. Pour plus d’informations, consultez Le modèle de transaction de compensation.

Rendre les travaux résilients

Créez des tâches en arrière-plan résilientes pour fournir des services fiables pour l’application. Lorsque vous planifiez et concevez des tâches en arrière-plan, tenez compte des points suivants :

  • Les tâches en arrière-plan doivent gérer correctement les redémarrages sans endommager les données ou introduire des incohérences dans l’application. Pour les tâches longues ou multistep, envisagez d’utiliser des points de contrôle. Utilisez des points de contrôle pour enregistrer l’état des travaux dans un stockage persistant ou en tant que messages dans une file d’attente. Par exemple, vous pouvez stocker des informations d’état dans un message qui se trouve dans une file d’attente et mettre à jour de façon incrémentielle ces informations d’état avec la progression de la tâche. La tâche peut être traitée à partir du dernier point de contrôle connu au lieu de redémarrer à partir du début.

    Pour les files d’attente Service Bus, utilisez des sessions de message à cet effet. Avec les sessions de messages, enregistrez et récupérez l’état de traitement de l’application à l’aide des méthodes SetState et GetState. Pour plus d’informations sur la conception de processus et de flux de travail multistep fiables, consultez le modèle superviseur de l’agent scheduler.

  • Quand vous utilisez des files d’attente pour communiquer avec les tâches en arrière-plan, ces files peuvent jouer le rôle de mémoire tampon pour stocker les demandes qui sont envoyées aux tâches à un moment où l’application connaît une surcharge. Les tâches peuvent rattraper l’interface utilisateur pendant des périodes moins occupées et les redémarrages ne bloquent pas l’interface utilisateur. Pour en savoir plus, consultez Modèle de nivellement de la charge basé sur une file d'attente. Si certaines tâches sont plus importantes que d’autres, envisagez d’implémenter le modèle File d’attente prioritaire pour vous assurer que ces tâches s’exécutent en premier.

Messages

Configurez les tâches en arrière-plan initiées par des messages ou qui traitent les messages pour gérer les incohérences, telles que les messages qui arrivent hors de commande, les messages qui provoquent à plusieurs reprises une erreur (messages incohérents) et les messages remis plusieurs fois. Tenez compte des recommandations suivantes :

  • Parfois, vous avez besoin de messages à traiter dans un ordre spécifique, comme les messages qui modifient les données en fonction de la valeur de données existante, par exemple en ajoutant une valeur à une valeur existante. Les messages n’arrivent pas toujours dans l’ordre dans lequel ils ont été envoyés. En outre, différentes instances d’une tâche en arrière-plan peuvent traiter les messages dans un ordre différent en raison de charges variables sur chaque instance.

    Pour les messages qui doivent être traités dans un ordre spécifique, incluez un numéro de séquence, une clé ou un autre indicateur que les tâches en arrière-plan peuvent utiliser pour traiter les messages dans l’ordre approprié. Pour Service Bus, utilisez des sessions de messages pour garantir l’ordre de livraison correct. Il est plus efficace de concevoir le processus afin que l’ordre des messages ne soit pas important. Pour plus d’informations, consultez séquencement et horodatages des messages.

  • En règle générale, une tâche en arrière-plan examine les messages de la file d’attente, qui les masque temporairement auprès d’autres consommateurs de messages. Une fois que la tâche a réussi à traiter le message, elle supprime le message. Si une tâche en arrière-plan échoue lorsqu’elle traite un message, ce message réapparaît dans la file d’attente après l’expiration du délai d’expiration de l’aperçu. Une autre instance de la tâche traite le message, ou le cycle de traitement suivant de l’instance d’origine traite le message.

    Si le message provoque constamment une erreur dans le consommateur, il bloque la tâche, la file d’attente et finalement l’application elle-même lorsque la file d’attente devient complète. Il est essentiel de détecter et de supprimer les messages incohérents de la file d’attente. Si vous utilisez Service Bus, déplacez automatiquement ou manuellement des messages incohérents vers une file d’attente de lettres mortes associée.

  • Les files d’attente sont des mécanismes de remise au moins une fois , mais ils peuvent remettre le même message plusieurs fois. Si une tâche en arrière-plan échoue une fois qu’elle traite un message, mais avant de la supprimer de la file d’attente, le message est à nouveau disponible pour traitement.

    Les tâches en arrière-plan doivent être idempotentes, ce qui signifie que lorsque la tâche traite le même message plusieurs fois, elle ne provoque pas d’erreur ou d’incohérence dans les données de l’application. Certaines opérations sont naturellement idempotentes, par exemple si une valeur stockée est définie sur une nouvelle valeur spécifique. Toutefois, certaines opérations provoquent des incohérences, par exemple si une valeur est ajoutée à une valeur stockée existante sans vérifier que la valeur stockée est toujours la même que lorsque le message a été envoyé à l’origine. Configurez les files d’attente Service Bus pour supprimer automatiquement les messages dupliqués. Pour plus d'informations, reportez-vous à la section Traitement des messages idempotents.

  • Certains systèmes de messagerie, tels que Stockage Azure files d’attente et les files d’attente Service Bus, prennent en charge une propriété de nombre de file d’attente qui indique le nombre de fois où un message de la file d’attente est lu. Ces données sont utiles pour gérer les messages répétés et les messages incohérents. Pour plus d’informations, consultez les modèles d’introduction de messagerie asynchrone et idempotency.

Rendre les travaux évolutifs

Les tâches en arrière-plan doivent offrir des performances suffisantes pour s’assurer qu’elles ne bloquent pas l’application ou ne retardent pas l’opération lorsque le système est en cours de chargement. En règle générale, les performances s’améliorent lorsque vous mettez à l’échelle les instances de calcul qui hébergent les tâches en arrière-plan. Lorsque vous planifiez et concevez des tâches en arrière-plan, tenez compte des points suivants liés à l’extensibilité et aux performances :

  • Azure Machines Virtuelles et la fonctionnalité Web Apps d’Azure App Service peuvent héberger des déploiements. Ils prennent en charge la mise à l’échelle automatique, à la fois le scale-out et la mise à l’échelle. La mise à l’échelle automatique est déterminée par la demande et la charge ou une planification prédéfinie. Utilisez la mise à l’échelle automatique pour vous assurer que l’application dispose de fonctionnalités de performances suffisantes tout en réduisant les coûts d’exécution.

  • Certaines tâches en arrière-plan ont une capacité de performances différente par rapport à d’autres parties d’une application, par exemple l’interface utilisateur ou les composants, tels que la couche d’accès aux données. Dans ce scénario, hébergez les tâches en arrière-plan ensemble dans un service de calcul distinct afin que l’interface utilisateur et les tâches en arrière-plan puissent être mises à l’échelle indépendamment pour gérer la charge. Si plusieurs tâches en arrière-plan ont des fonctionnalités de performances significativement différentes, divisez-les et mettez à l’échelle chaque type indépendamment. Cette technique peut augmenter les coûts d’exécution.

  • Pour éviter la perte de performances sous charge, vous devrez peut-être également mettre à l’échelle les files d’attente de stockage et d’autres ressources afin qu’un point unique de la chaîne de traitement ne provoque pas de goulot d’étranglement. Tenez compte d’autres limitations, telles que le débit maximal de stockage et d’autres services sur lesquels reposent l’application et les tâches en arrière-plan.

  • Concevoir des tâches en arrière-plan pour la mise à l’échelle. Par exemple, les tâches en arrière-plan doivent détecter dynamiquement le nombre de files d’attente de stockage utilisées pour surveiller les messages ou envoyer des messages à la file d’attente appropriée.

  • Par défaut, une tâche web est mise à l’échelle avec son instance Web Apps associée. Toutefois, si vous souhaitez qu’une tâche web s’exécute en tant qu’instance unique, vous pouvez créer un fichier Settings.job qui contient les données { "is_singleton": true }JSON. Cette méthode force Azure à exécuter une seule instance de la tâche web, même s’il existe plusieurs instances de l’application web associée. Cette technique est utile pour les travaux planifiés qui doivent s’exécuter en tant qu’instance unique.

  • Les travaux en arrière-plan peuvent créer des défis pour la synchronisation des données et la coordination des processus, en particulier si les tâches en arrière-plan dépendent les unes des autres ou d’autres sources de données. Par exemple, les travaux en arrière-plan peuvent gérer des problèmes de cohérence des données, des conditions de concurrence, des interblocages ou des délais d’expiration.

  • Les travaux en arrière-plan peuvent affecter l’expérience utilisateur si les résultats des tâches en arrière-plan sont présentés à l’utilisateur. Par exemple, les travaux en arrière-plan peuvent obliger l’utilisateur à attendre une notification, à actualiser la page ou à vérifier manuellement l’état de la tâche. Ces comportements peuvent augmenter la complexité de l’interaction de l’utilisateur et affecter négativement l’expérience utilisateur.

Compromis : les travaux en arrière-plan introduisent davantage de composants et de dépendances au système, ce qui peut augmenter la complexité et les coûts de maintenance de la solution. Par exemple, les travaux en arrière-plan peuvent nécessiter un service de file d’attente distinct, un service de travail, un service de surveillance et un mécanisme de nouvelle tentative.

Facilitation Azure

Les sections suivantes décrivent les services Azure que vous pouvez utiliser pour héberger, exécuter, configurer et gérer des travaux en arrière-plan.

Environnements hôtes

Plusieurs services de plateforme Azure peuvent héberger des tâches en arrière-plan :

  • Web Apps et WebJobs : utilisez la fonctionnalité WebJobs d’App Service pour exécuter des travaux personnalisés basés sur différents scripts ou programmes que vous pouvez exécuter dans une application web.

  • Azure Functions : utilisez des applications de fonction pour les travaux en arrière-plan qui ne s’exécutent pas longtemps. Vous pouvez également utiliser des applications de fonction si vous hébergez votre charge de travail sur un plan App Service sous-utilisé.

  • Machines Virtuelles : si vous disposez d’un service Windows ou que vous souhaitez utiliser le planificateur de tâches Windows, hébergez vos tâches en arrière-plan dans une machine virtuelle dédiée.

  • Azure Batch : Batch est un service de plateforme que vous pouvez utiliser pour planifier un travail nécessitant beaucoup de ressources de calcul pour s’exécuter sur une collection managée de machines virtuelles. Il peut automatiquement mettre à l’échelle les ressources de calcul.

  • Azure Kubernetes Service (AKS) : AKS fournit un environnement d’hébergement managé pour Kubernetes sur Azure.

  • Azure Container Apps : Avec Container Apps, vous pouvez créer des microservices serverless basés sur des conteneurs.

Les sections suivantes fournissent des considérations relatives à chacune de ces options pour vous aider à choisir la meilleure option pour vous.

Web Apps et WebJobs

Vous pouvez utiliser la fonctionnalité WebJobs pour exécuter des travaux personnalisés en tant que travaux en arrière-plan dans une application web. Une tâche web s’exécute en tant que processus continu dans le contexte de votre application web. Une tâche web peut également s’exécuter en réponse à un événement déclencheur à partir de Logic Apps ou de facteurs externes, tels que les modifications apportées aux objets blob de stockage ou aux files d’attente de messages. Les tâches web peuvent être démarrées et arrêtées à la demande, et s’arrêter correctement. Si une tâche web en cours d’exécution continue échoue, elle est redémarrée automatiquement. Vous pouvez configurer des actions de nouvelle tentative et d’erreur.

Quand vous configurez une tâche web :

  • Si vous souhaitez que le travail réponde à un déclencheur piloté par les événements, configurez-le pour qu’il s’exécute en continu. Le script ou le programme est stocké dans le dossier nommé site/wwwroot/app_data/jobs/continuous.

  • Si vous souhaitez que le travail réponde à un déclencheur piloté par la planification, configurez-le pour qu’il s’exécute selon une planification. Le script ou programme est stocké dans le dossier nommé site/wwwroot/app_data/jobs/triggered.

  • Si vous choisissez l’option Exécuter à la demande lorsque vous configurez un travail, elle exécute le même code que l’option Exécuter sur une planification lorsque vous démarrez le travail.

Une tâche web s’exécute dans le bac à sable de l’application web. Il a accès aux variables d’environnement et peut partager des informations, telles que des chaîne de connexion s, avec l’application web. Le WebJob a accès à l’identificateur unique de l’ordinateur qui exécute la tâche web. Le chaîne de connexion nommé AzureWebJobsStorage permet d’accéder aux files d’attente de stockage, aux objets blob et aux tables pour les données d’application. Il fournit également l’accès à Service Bus pour la messagerie et la communication. Le chaîne de connexion nommé AzureWebJobsDashboard permet d’accéder aux fichiers journaux des actions WebJob.

Les tâches web présentent les caractéristiques suivantes :

  • Sécurité : les informations d’identification de déploiement de l’application web fournissent une protection pour les tâches web.

  • Types de fichiers pris en charge : Définir des tâches web à l’aide de scripts de commande (.cmd), de fichiers de commandes (.bat), de scripts PowerShell (.ps1), de scripts Bash shell (.sh), de scripts PHP (.php), de scripts Python (.py), de code JavaScript (.js) et de programmes exécutables (.exe et .jar).

  • Déploiement : vous pouvez déployer des scripts et des exécutables à l’aide des Portail Azure, Visual Studio ou du Kit de développement logiciel (SDK) WebJobs, ou les copier directement aux emplacements suivants :

    • Pour le déploiement déclenché : site/wwwroot/app_data/jobs/triggered/<job name>

    • Pour le déploiement continu : site/wwwroot/app_data/jobs/continuous/<job name>

  • Fichiers journaux : Console.Out est traité ou marqué comme INFO. Console.Error est traité comme ERROR. Utilisez le portail pour accéder aux informations de surveillance et de diagnostic. Téléchargez les fichiers journaux directement à partir du site web. Les fichiers journaux sont enregistrés dans les emplacements suivants :

    • Pour le déploiement déclenché : Vfs/data/jobs/triggered/<job name>

    • Pour le déploiement continu : Vfs/data/jobs/continuous/<job name>

  • Configuration : Configurez webJobs à l’aide du portail, de l’API REST et de PowerShell. Utilisez un fichier de configuration nommé settings.job, qui se trouve dans le même répertoire racine que le script WebJob, pour fournir des informations de configuration pour une tâche web. Par exemple :

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Considérations relatives aux applications web et aux tâches web

  • Par défaut, WebJobs est mis à l’échelle par rapport à l’application web. Pour configurer WebJobs pour qu’il s’exécute sur une seule instance, définissez la is_singleton propriété truede configuration sur . Les tâches web à instance unique sont utiles pour les tâches que vous ne souhaitez pas mettre à l’échelle ou exécuter en tant que plusieurs instances simultanées, telles que la réindexation ou l’analyse des données.

  • Pour réduire l’effet des tâches web sur les performances de l’application web, créez une instance d’application web vide dans un nouveau plan App Service pour héberger des tâches web longues ou gourmandes en ressources.

Azure Functions

Azure Functions est similaire à WebJobs. Azure Functions est serverless et convient le mieux aux déclencheurs pilotés par les événements qui s’exécutent pendant une courte période. Vous pouvez également utiliser Azure Functions pour exécuter des travaux planifiés via des déclencheurs de minuteur si vous configurez une fonction à exécuter à des moments spécifiés.

Azure Functions n’est pas recommandé pour les tâches volumineuses et longues, car une fonction peut entraîner des délais d’attente inattendus. Toutefois, selon votre plan d’hébergement, envisagez d’utiliser des fonctions pour les déclencheurs pilotés par la planification.

Considérations relatives à Azure Functions

Si vous attendez que la tâche en arrière-plan s’exécute pendant une courte durée en réponse à un événement, envisagez d’exécuter la tâche dans le plan de consommation. Vous pouvez configurer le runtime sur une durée maximale. Une fonction qui s’exécute plus longtemps entraîne des coûts supplémentaires. Les travaux nécessitant beaucoup d’UC qui consomment plus de mémoire peuvent être plus coûteux. Si vous utilisez des déclencheurs supplémentaires pour les services dans le cadre de votre tâche, ils sont facturés séparément.

Le plan Premium convient si vous avez plusieurs tâches courtes, mais qu’elles s’exécutent en continu. Ce plan est plus onéreux, car il a besoin de plus de ressources mémoire et processeur. En guise d’avantage, vous pouvez utiliser d’autres fonctionnalités, telles que l’intégration de réseau virtuel.

Le plan dédié convient aux travaux en arrière-plan si votre charge de travail s’exécute déjà sur le plan dédié. Si vous avez des machines virtuelles sous-utilisées, vous pouvez exécuter le plan dédié sur la même machine virtuelle et partager les coûts de calcul.

Pour plus d’informations, consultez l’article suivant :

Machines Virtuelles

Vous pouvez implémenter des tâches en arrière-plan afin qu’elles ne soient pas déployées sur Web Apps. Par exemple, vous pouvez implémenter des tâches à l’aide de services Windows, d’utilitaires tiers ou de programmes exécutables. Vous pouvez également utiliser des programmes écrits pour un environnement d’exécution différent de l’environnement qui héberge l’application. Par exemple, vous pouvez utiliser un programme Unix ou Linux que vous souhaitez exécuter à partir d’une application Windows ou .NET. Choisissez parmi plusieurs systèmes d’exploitation pour une machine virtuelle Azure, puis exécutez votre service ou votre exécutable sur cette machine virtuelle.

Pour plus d’informations, consultez l’article suivant :

Pour lancer la tâche en arrière-plan dans une machine virtuelle distincte, vous pouvez :

  • Envoyez une demande à un point de terminaison exposé par la tâche pour exécuter la tâche à la demande directement à partir de votre application. La requête transfère les données requises par la tâche. Le point de terminaison appelle la tâche.

  • Utilisez un planificateur ou un minuteur à partir de votre système d’exploitation choisi pour configurer la tâche à exécuter selon une planification. Par exemple, sur Windows, vous pouvez utiliser le Planificateur de tâches Windows pour exécuter des scripts et des tâches. Si SQL Server est installé sur la machine virtuelle, utilisez SQL Server Agent pour exécuter des scripts et des tâches.

  • Utilisez Logic Apps pour lancer la tâche en ajoutant un message à une file d’attente que la tâche surveille ou en envoyant une demande à une API exposée par la tâche.

Pour plus d’informations sur la façon dont vous pouvez lancer des tâches en arrière-plan, consultez la section déclencheurs précédente.

considérations relatives aux Machines Virtuelles

Tenez compte des points suivants lorsque vous déployez des tâches en arrière-plan dans une machine virtuelle Azure :

  • Héberger des tâches en arrière-plan dans une machine virtuelle Azure distincte pour fournir une flexibilité et un contrôle précis sur l’initiation, le déploiement, la planification et l’allocation des ressources. Toutefois, les coûts d’exécution augmentent si vous déployez une machine virtuelle uniquement pour les tâches en arrière-plan.

  • Il n’existe aucune fonctionnalité permettant de surveiller les tâches dans le portail et aucune fonctionnalité de redémarrage automatisé pour les tâches ayant échoué. Toutefois, vous pouvez utiliser les applets de commande Azure Resource Manager pour surveiller l’état de la machine virtuelle et la gérer. Il n’existe aucune capacité de contrôle des processus et des threads dans les nœuds de calcul. En règle générale, si vous utilisez une machine virtuelle, vous devez implémenter un mécanisme qui collecte des données à partir de l’instrumentation dans la tâche, ainsi qu’à partir du système d’exploitation de la machine virtuelle. Vous pouvez utiliser le pack d’administration System Center pour Azure à cet effet.

  • Envisagez de créer des sondes de surveillance exposées via des points de terminaison HTTP. Vous pouvez configurer le code de ces sondes pour effectuer des vérifications d’intégrité et collecter des informations opérationnelles et des statistiques. Vous pouvez également utiliser les sondes pour rassembler les informations d’erreur et les renvoyer à une application de gestion.

Pour plus d’informations, consultez l’article suivant :

Batch

Considérez Batch si vous devez exécuter des charges de travail hpC (High-Performance Computing) volumineuses et parallèles sur des dizaines, des centaines ou des milliers de machines virtuelles.

Utilisez Batch pour préparer les machines virtuelles, affecter des tâches aux machines virtuelles, exécuter les tâches, surveiller la progression et effectuer automatiquement un scale-out des machines virtuelles en réponse à la charge de travail. Batch fournit également la planification des travaux et prend en charge les machines virtuelles Linux et Windows.

Considérations relatives aux lots

Batch convient aux charges de travail intrinsèquement parallèles. Vous pouvez utiliser Batch pour effectuer des calculs parallèles à l’aide d’une étape de réduction à la fin, ou exécuter des applications MPI (Message Passing Interface) pour les tâches parallèles qui nécessitent le passage de messages entre les nœuds.

Un travail Batch s’exécute sur un pool de nœuds ou de machines virtuelles. Vous ne pouvez allouer un pool que si nécessaire, puis le supprimer une fois le travail terminé. Cette approche optimise l’utilisation, car les nœuds ne sont pas inactifs, mais le travail doit attendre que vous allouiez des nœuds. Vous pouvez également créer un pool à l’avance. Cette approche réduit le temps nécessaire au démarrage d’un travail, mais peut entraîner l’inactivité des nœuds.

Pour plus d’informations, consultez l’article suivant :

Azure Kubernetes Service

Utilisez AKS pour gérer votre environnement Kubernetes hébergé afin de pouvoir facilement déployer et gérer des applications conteneurisées.

Les conteneurs sont utiles pour exécuter des travaux en arrière-plan. Voici certains des avantages obtenus :

  • Les conteneurs prennent en charge l’hébergement haute densité. Vous pouvez isoler une tâche en arrière-plan dans un conteneur, tout en plaçant plusieurs conteneurs dans chaque machine virtuelle.

  • Utilisez l’orchestrateur de conteneurs pour effectuer l’équilibrage de charge interne, configurer le réseau interne et effectuer d’autres tâches de configuration.

  • Vous pouvez démarrer et arrêter les conteneurs en fonction des besoins.

  • Avec Azure Container Registry, vous pouvez inscrire vos conteneurs à l’intérieur des limites Azure pour fournir des avantages de sécurité, de confidentialité et de proximité.

Considérations relatives à AKS

AKS nécessite une compréhension de l’utilisation d’un orchestrateur de conteneurs.

Pour plus d'informations, consultez les pages suivantes :

Applications de conteneur

Avec Container Apps, vous pouvez créer des microservices serverless basés sur des conteneurs. Container Apps :

  • Est optimisé pour l’exécution de conteneurs à usage général, en particulier les applications qui s’étendent sur de nombreux microservices déployés dans des conteneurs.

  • Est alimenté par des technologies Kubernetes et open source, telles que Dapr, Kubernetes Event-driven Autoscaling (KEDA) et Envoy.

  • Prend en charge les applications de type Kubernetes et les microservices avec des fonctionnalités comme la découverte du service et la répartition du trafic.

  • Active les architectures d’application pilotées par les événements en prenant en charge la mise à l’échelle basée sur le trafic et l’extraction à partir de sources d’événements telles que les files d’attente, notamment la mise à l’échelle à zéro.

  • Prend en charge les processus de longue durée et peut exécuter des tâches en arrière-plan.

Considérations relatives aux applications conteneur

Container Apps ne fournit pas d’accès direct aux API Kubernetes sous-jacentes. Si vous avez besoin d’accéder aux API et au plan de contrôle Kubernetes, utilisez AKS. Si vous souhaitez créer des applications de style Kubernetes et que vous n’avez pas besoin d’un accès direct aux API Kubernetes natives et à la gestion des clusters, utilisez Container Apps pour une expérience entièrement managée. Container Apps convient le mieux à la création de microservices de conteneur.

Pour plus d’informations, consultez l’article suivant :

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité