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

  • Article

S’applique à cette recommandation de liste de vérification de fiabilité 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-conservation et d’auto-réparation. Créez 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 des logiciels pour gérer les défaillances de composants et les erreurs temporaires. Créez des fonctionnalités dans le système pour détecter les défaillances des composants de la solution et lancer automatiquement une action corrective pendant que la charge de travail continue de fonctionner à l’intégralité ou à la réduction des fonctionnalités.

Guides connexes :Erreurs temporaires | Auto-conservation

Ce guide décrit les recommandations pour le développement de travaux en arrière-plan. Les travaux en arrière-plan s’exécutent automatiquement sans qu’il soit nécessaire d’interagir avec l’utilisateur. De nombreuses applications nécessitent des travaux en arrière-plan qui s’exécutent indépendamment de l’interface utilisateur.

Parmi les exemples de travaux en arrière-plan, citons les travaux par lots, les tâches de traitement intensives et les processus de longue durée, tels que les workflows. 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, un travail en arrière-plan peut être effectué pour générer la miniature et l’enregistrer dans le stockage. L’utilisateur n’a pas besoin d’attendre que le processus se termine. Par exemple, un client passe 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 en arrière-plan, déterminez si la tâche s’exécute sans intervention de l’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 pendant leur exécution ne sont généralement pas des travaux en arrière-plan appropriés.

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

  • Travaux gourmands en E/S, tels 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.

  • Workflows de longue durée, tels que l’exécution des commandes ou l’approvisionnement de services et de systèmes.

  • Traitement des données sensibles qui transfère la tâche vers 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é.

Déclencheurs

Lancez des travaux en arrière-plan avec :

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

Une action déclenche un appel piloté par des é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 autre travail 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 précédemment effectuée, 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 un message.

  • 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 le travail en arrière-plan.

  • L’interface utilisateur ou une autre tâche effectue une demande à un point de terminaison, tel qu’un URI HTTPS ou une API exposée en tant que service web. Dans le cadre de la demande, 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 à l’appel piloté par les événements incluent le traitement d’images, les workflows, l’envoi d’informations aux services distants, l’envoi de messages électroniques et l’approvisionnement de nouveaux utilisateurs dans des applications multilocataires.

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.

  • Un minuteur qui s’exécute dans une autre application, telle qu’Azure Logic Apps, envoie régulièrement une requête à 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 à une heure spécifique.

D’autres exemples de tâches adaptées à l’appel piloté par la planification incluent les routines de traitement par lots (telles que la mise à jour des listes de produits associées 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 des 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 comme un seul instance, passez en revue les considérations suivantes :

  • Si le instance de calcul qui exécute le planificateur, par exemple une machine virtuelle qui utilise des tâches planifiées Windows, est mis à 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 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.

Renvoi de résultats

Les travaux en arrière-plan s’exécutent de manière asynchrone dans un processus distinct, ou même à 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 des opérations de feu et d’oubli . Leur progression d’exécution n’a pas d’effet sur l’interface utilisateur ou le processus d’appel, 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 la fin de la tâche.

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

  • Écrivez une valeur d’indicateur status dans le stockage accessible à l’interface utilisateur ou à la tâche appelante, qui peut surveiller ou case activée cette valeur. Les autres données que la tâche en arrière-plan retourne à l’appelant peuvent être placées dans le même stockage.

  • Établissez une file d’attente de réponses 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 le status. Les données que la tâche en arrière-plan retourne à l’appelant peuvent être placées dans les messages. Pour Azure Service Bus, utilisez les ReplyTo propriétés et CorrelationId 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 que la tâche en arrière-plan retourne à l’appelant.

  • Configurez la tâche en arrière-plan pour qu’elle rappelle l’interface utilisateur ou l’appelant via une API pour indiquer le status à des points prédéfinis ou à l’achèvement. 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 d’événement peut inclure les données que la tâche en arrière-plan retourne à l’appelant.

Travaux en arrière-plan de partition

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

  • Disponibilité : les tâches en arrière-plan peuvent ne pas nécessiter le 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 une capacité suffisante pour empêcher les demandes 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 des périodes moins occupées et avec moins d’instances de calcul.

  • Résilience : si une instance de calcul qui héberge uniquement les tâches en arrière-plan échoue, cela peut ne pas affecter de manière irrécupérable l’ensemble de l’application. Les demandes pour ces tâches peuvent être mises en file d’attente ou reportées jusqu’à ce que la tâche soit disponible. Si le 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 ou des restrictions de sécurité différentes de celles de l’interface utilisateur ou d’autres parties de l’application. Utilisez un instance de calcul distinct 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 de 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 plus grande instance 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 de celui du code d’application main ou de l’interface utilisateur. Pour simplifier les mises à jour et le contrôle de version, déployez des tâches en arrière-plan sur un instance de calcul distinct.

  • 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 une capacité accrue et des coûts supplémentaires.

Pour plus d’informations, consultez Modèle d’élection de leader et Modèle de consommateurs concurrents.

Conflits

Si vous avez plusieurs instances d’un travail en arrière-plan, elles peuvent être en concurrence pour l’accès aux ressources et aux 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 d’endommager des données.

Une autre approche pour résoudre les conflits consiste à définir des tâches en arrière-plan comme un 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 instance. Cet inconvénient est particulièrement vrai si l’interface utilisateur fournit suffisamment de travail pour occuper plusieurs tâches en arrière-plan.

Vérifiez 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 un instance de calcul avec des ressources suffisantes, implémentez un mécanisme de mise en file d’attente qui stocke les demandes à exécuter lorsque la demande diminue, ou utilisez une combinaison de ces techniques.

Coordination

Les tâches en arrière-plan peuvent être complexes et nécessiter l’exécution de plusieurs tâches. Dans ces scénarios, il est courant de diviser la tâche en étapes discrètes ou en tâches subordonnées plus petites que plusieurs consommateurs peuvent exécuter. Les travaux à plusieurs étapes 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 être difficile de 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 diverses tâches de complexité différente sur les informations qu’elle traite. Une approche simple mais inflexible de l’implémentation d’une telle application consiste à effectuer ce traitement en tant que module monolithique. Toutefois, cette approche est susceptible de réduire les possibilités de refactorisation du code, de l’optimiser ou de le 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érer 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 à des 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 à terme. Pour plus d’informations, consultez Modèle de transaction de compensation.

Remarques relatives à la résilience

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 une incohérence dans l’application. Pour les tâches longues ou à plusieurs étapes, envisagez d’utiliser des points de contrôle. Utilisez des points de contrôle pour enregistrer l’état des travaux dans le stockage persistant ou en tant que messages dans une file d’attente. Par exemple, vous pouvez stocker les informations d’état dans un message qui se trouve dans une file d’attente et mettre à jour ces informations d’état de manière incrémentielle 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 messages à cet effet. Avec les sessions de message, 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 workflows et de processus multiétapes fiables, consultez Modèle de 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 les 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 de 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 qui sont initiées par des messages ou qui traitent les messages pour gérer les incohérences, telles que les messages qui arrivent dans le désordre, les messages qui provoquent à plusieurs reprises une erreur (messages incohérents) et les messages remis plusieurs fois. Tenez compte des recommandations suivantes :

  • Parfois, vous devez traiter les messages dans un ordre spécifique, comme les messages qui modifient des 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 le bon ordre. Pour Service Bus, utilisez des sessions de messages pour garantir l’ordre de remise 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 des messages et horodatages.

  • En règle générale, une tâche en arrière-plan examine les messages dans la file d’attente, ce qui les masque temporairement aux autres consommateurs de messages. Une fois que la tâche a correctement effectué le traitement du message, elle le supprime. 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 prochain cycle de traitement du instance d’origine traite le message.

    Si le message provoque systématiquement 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 pleine. 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 les 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 elles peuvent remettre le même message plusieurs fois. Si une tâche en arrière-plan échoue après qu’elle a traité un message, mais avant qu’elle ne le supprime 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, cela 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 entraînent 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 lors de l’envoi initial du message. Configurez les files d’attente Service Bus pour supprimer automatiquement les messages dupliqués. Pour plus d’informations, consultez Traitement des messages idempotents.

  • Certains systèmes de messagerie, tels que les files d’attente stockage Azure et les files d’attente Service Bus, prennent en charge une propriété de nombre de files 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 Modèles d’introduction et d’idempotence de messagerie asynchrone.

Remarques relatives à la mise à l’échelle et aux performances

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 sous charge. 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 à la scalabilité et aux performances :

  • Azure Machines Virtuelles et la fonctionnalité Web Apps de 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 par 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 des performances différentes 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 dans un service de calcul distinct afin que les tâches d’interface utilisateur et 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 considérablement 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 la 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 du stockage et d’autres services sur lesquels l’application et les tâches en arrière-plan s’appuient.

  • 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 ses Web Apps instance associées. Toutefois, si vous souhaitez qu’une tâche web s’exécute comme un seul instance, vous pouvez créer un fichier Settings.job qui contient les données { "is_singleton": true }JSON . Cette méthode force Azure à n’exécuter qu’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 ne doivent s’exécuter qu’en tant que seul instance.

  • 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 nécessiter que l’utilisateur attende une notification, actualise la page ou case activée manuellement le status de la tâche. Ces comportements peuvent augmenter la complexité de l’interaction 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, un service worker, un service de surveillance et un mécanisme de nouvelle tentative distincts.

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

Il existe plusieurs services de plateforme Azure qui peuvent héberger des tâches en arrière-plan :

  • Web Apps et WebJobs : utilisez la fonctionnalité WebJobs de 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 pendant une longue période. Vous pouvez également utiliser des applications de fonction si vous hébergez votre charge de travail sur un plan de App Service sous-utilisé.

  • Machines Virtuelles : si vous disposez d’un service Windows ou si 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 l’exécution d’un travail nécessitant beaucoup de calcul 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 pour chacune de ces options afin de vous aider à choisir l’option qui vous convient le mieux.

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 provenant de Logic Apps ou à des 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, puis s’arrêter correctement. Si une tâche web en cours d’exécution continue échoue, elle est automatiquement redémarrée. Vous pouvez configurer les 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 selon 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 il peut partager des informations, telles que des chaînes de connexion, avec l’application web. La tâche web a accès à l’identificateur unique de la machine qui exécute la tâche web. Le chaîne de connexion nommé AzureWebJobsStorage donne accès 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 de tâche web.

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

  • Sécurité : les informations d’identification de déploiement de l’application web assurent la protection des tâches web.

  • Types de fichiers pris en charge : Définissez les tâches web à l’aide de scripts de commande (.cmd), de fichiers batch (.bat), de scripts PowerShell (.ps1), de scripts shell Bash (.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 de l’Portail Azure, Visual Studio ou le Kit de développement logiciel (SDK) WebJobs, ou vous pouvez 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 supervision et de diagnostics. Téléchargez les fichiers journaux directement à partir du site web. Les fichiers journaux sont enregistrés aux emplacements suivants :

    • Pour le déploiement déclenché : Vfs/data/jobs/triggered/nom du< travail>

    • 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 Web Apps et aux tâches web

  • Par défaut, WebJobs est mis à l’échelle par rapport à l’application web. Pour configurer l’exécution de WebJobs sur un seul instance, définissez la propriété de is_singleton configuration sur true. Les tâches web instance uniques sont utiles pour les tâches que vous ne souhaitez pas mettre à l’échelle ou exécuter en tant qu’instances multiples 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 application web vide instance 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 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 du minuteur si vous configurez une fonction pour qu’elle s’exécute à des heures spécifiées.

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

Azure Functions considérations

Si vous vous attendez à ce 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 gourmands en processeur 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 plusieurs tâches sont 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. Comme 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 les pages suivantes :

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 et exécutez votre service ou votre exécutable sur cette machine virtuelle.

Pour plus d'informations, consultez les pages suivantes :

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

  • Envoyez une demande à un point de terminaison que la tâche expose 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 du système d’exploitation choisi pour configurer la tâche pour qu’elle s’exécute 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 vous avez SQL Server 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 requête à 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.

Machines Virtuelles considérations

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

  • Hébergez 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 possibilité 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 la status de la machine virtuelle et la gérer. Il n’existe aucune fonctionnalité permettant de contrôler les processus et les 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 que du système d’exploitation dans la machine virtuelle. Vous pouvez utiliser le pack d’administration System Center pour Azure à cet effet.

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

Pour plus d'informations, consultez les pages suivantes :

Batch

Envisagez Batch si vous avez besoin d’exécuter des charges de travail de calcul haute performance (HPC) en parallèle 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 avec 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 pouvez allouer un pool uniquement en cas de besoin, 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 des nœuds qui restent inactifs.

Pour plus d'informations, consultez les pages suivantes :

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 des conteneurs en fonction des besoins.

  • Avec Azure Container Registry, vous pouvez inscrire vos conteneurs à l’intérieur des limites Azure pour offrir des avantages en matière 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 couvrent de nombreux microservices déployés dans des conteneurs.

  • Est alimenté par Kubernetes et des technologies open source, comme 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, y compris la mise à l’échelle vers 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 à Container Apps

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 est le mieux adapté à la création de microservices de conteneur.

Pour plus d'informations, consultez les pages suivantes :

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité