Votre application auto-hébergée a-t-elle besoin de workers en arrière-plan ? Un cadre de décision pratique

Les workers en arrière-plan protègent l’expérience interactive

Une requête web correspond au travail effectué pendant qu’une personne attend : ouvrir un tableau de bord, soumettre un formulaire, enregistrer une fiche ou consulter une page. La requête doit renvoyer rapidement un résultat utile. Un worker en arrière-plan est un processus distinct qui prend en charge du travail pouvant se poursuivre après l’envoi de cette réponse.

Cette distinction est importante lorsqu’une action déclenche un travail dont la durée est imprévisible ou longue. L’envoi d’un lot de messages, l’analyse d’un fichier importé, la génération d’un rapport ou le traitement de médias peuvent consommer du temps et des ressources bien au-delà de l’interaction utilisateur qui les a déclenchés. La documentation des files d’attente de Laravel cite l’analyse et le stockage d’un CSV comme exemple d’un travail pouvant prendre trop de temps dans une requête web normale et devant plutôt être traité en arrière-plan (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues).

Ne considérez pas les workers comme le signe automatique d’un déploiement mature. Ils ajoutent des composants, des dépendances opérationnelles et des modes de défaillance. La bonne question n’est pas « cette application a-t-elle une file d’attente ? », mais « le travail requis par cette application peut-il s’exécuter de manière sûre dans le chemin de la requête, ou nécessite-t-il une exécution et une supervision indépendantes ? ».

• Gardez le processus web concentré sur le trafic interactif.
• Déplacez le travail en arrière-plan lorsqu’un utilisateur n’a pas besoin du résultat final avant de poursuivre.
• Utilisez la documentation propre à l’application comme référence pour déterminer si des workers, un planificateur ou un backend de file d’attente sont requis.
• Ne supposez pas que toutes les applications auto-hébergées prennent en charge la même architecture de workers.

Quelles charges de travail relèvent couramment de l’arrière-plan ?

La documentation des frameworks identifie régulièrement la livraison d’e-mails, le traitement de données et la maintenance récurrente comme des cas d’usage des tâches en arrière-plan. Rails, par exemple, présente ces catégories parmi les usages d’Active Job (Rails, « Active Job Basics » : https://guides.rubyonrails.org/active_job_basics.html). Dans les déploiements auto-hébergés concrets, le même modèle apparaît dans de nombreux flux de travail métier, éditoriaux, analytiques et d’automatisation.

Le facteur décisif n’est pas le nom de la fonctionnalité. C’est la capacité à accepter le travail maintenant et à le terminer plus tard sans faire attendre l’utilisateur, à condition que l’application fournisse à l’utilisateur un statut, une notification ou un résultat approprié lorsqu’il est terminé.

Les sauvegardes peuvent relever de ce modèle lorsqu’elles sont déclenchées et gérées par l’application elle-même. Cela ne signifie pas que toutes les sauvegardes reposent sur un worker ou un planificateur applicatif : une plateforme peut aussi gérer ses propres sauvegardes indépendamment de l’application.

• Importations et exportations : analyse de données, validation d’enregistrements, transformation de fichiers et production de résultats téléchargeables.
• Notifications : livraison d’e-mails, génération de récapitulatifs et autres communications non immédiates.
• Tâches planifiées : nettoyage régulier, maintenance liée à la facturation ou activités d’actualisation périodiques.
• Sauvegardes applicatives : travaux de sauvegarde uniquement lorsque l’application les déclenche ou les gère elle-même.
• Rapports : compilation de rapports gourmands en données ou génération de rapports récurrents.
• Traitement de médias : création de miniatures, conversions ou autres transformations de fichiers lorsque l’application le prend en charge.
• Indexation et traitement lié à la recherche : mise à jour d’index dérivés après modification de contenus ou d’enregistrements.
• Automatisation : traitement du travail déclenché par des formulaires, des intégrations ou des événements de workflow.

Utilisez un modèle en cinq parties avant de discuter de la taille du serveur

Un déploiement avec workers est plus facile à comprendre lorsque ses responsabilités sont séparées. Les noms exacts varient selon l’application, mais cinq rôles reviennent régulièrement : le processus web, le planificateur, la file d’attente, le worker et le stockage persistant.

Le processus web reçoit le trafic provenant des navigateurs ou des API. Il peut créer une tâche et placer une référence vers celle-ci dans une file d’attente. La file d’attente conserve le travail en attente. Un ou plusieurs workers consomment les tâches et les exécutent. Un planificateur crée du travail à des moments définis, tandis que le stockage persistant conserve les données de l’application et, selon la conception, peut aussi conserver des informations de file d’attente ou de tâches.

Le travail planifié et la consommation d’une file d’attente sont différents. Un planificateur crée du travail à intervalles réguliers ; un worker récupère en continu le travail disponible dans une file d’attente. Kubernetes décrit les CronJobs comme utiles pour des actions telles que les sauvegardes et la génération de rapports, tout en avertissant que leur planification ne doit pas être considérée comme une garantie d’exécution exactement une fois (Kubernetes, « CronJob » : https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/). Le planificateur propre à votre application a ses propres règles de fonctionnement : vérifiez donc ce qu’il garantit et concevez le travail récurrent en conséquence.

Docker Compose peut définir plusieurs services depuis une seule configuration, et Docker recommande de séparer les responsabilités plutôt que de placer toutes les fonctions dans un unique conteneur. Il devient ainsi possible d’exploiter indépendamment les composants web, worker, file d’attente et base de données lorsque l’application l’exige réellement (Docker, « How Compose Works » : https://docs.docker.com/compose/intro/compose-application-model/).

• Processus web : sert les requêtes interactives.
• Planificateur : déclenche du travail selon un calendrier récurrent.
• File d’attente : stocke les tâches en attente ou les références aux tâches jusqu’à leur traitement.
• Worker : exécute les tâches en file d’attente hors du chemin de la requête.
• Stockage persistant : conserve les données de l’application et peut conserver des informations de file d’attente, de tâches ou d’état.

Cinq signaux indiquant que le travail en arrière-plan affecte déjà les utilisateurs

Le besoin de workers devient généralement visible à travers des symptômes plutôt que lors d’une discussion abstraite sur l’architecture. Recherchez des tendances sur les périodes normales et de pointe, et non une seule action lente isolée.

Commencez par la durée des requêtes. Si de longues requêtes visibles par les utilisateurs coïncident avec des importations, des rapports, des notifications par lots ou d’autres actions coûteuses, le travail dans le chemin de la requête peut concurrencer le trafic interactif. Lorsque les journaux d’accès Traefik sont disponibles, leur champ « Duration » inclut le temps total de traitement de la réponse, y compris le temps du serveur d’origine ; ils constituent donc une source utile d’éléments sur la durée des requêtes (Traefik, « Logs and Access Logs » : https://doc.traefik.io/traefik/observability/access-logs/).

Examinez ensuite le cycle de vie de la tâche lui-même. Une tâche peut être acceptée mais retardée, échouer de manière répétée, disparaître sans visibilité claire ou concurrencer le processus web pour les ressources de calcul et de mémoire disponibles. L’augmentation de la file d’attente est particulièrement importante : Laravel indique qu’un afflux soudain peut submerger une file d’attente et allonger considérablement le délai d’achèvement (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues).

• Requêtes lentes : les utilisateurs attendent sensiblement plus longtemps lorsque des actions intensives sont exécutées.
• Résultats retardés : les e-mails, importations, rapports ou autres résultats arrivent plus tard que prévu après leur demande.
• Travail planifié en échec : la maintenance ou les rapports récurrents ne s’exécutent pas de manière fiable, ou une exécution en double est possible et non maîtrisée.
• Augmentation de la file d’attente : le travail en attente augmente et ne revient pas à un niveau normal après un pic.
• Concurrence pour les ressources : les tâches longues dégradent la réactivité de l’application web ou d’autres services nécessaires.

Répondez à ces questions de dépendances avant d’ajouter un worker

Un worker n’est pas simplement un processus supplémentaire à démarrer. Il doit utiliser la commande, la configuration, le backend de file d’attente et le modèle de cycle de vie pris en charge par l’application. Commencez par la documentation officielle de la version exacte de l’application que vous exploitez. Confirmez si le traitement en arrière-plan est facultatif, recommandé pour certaines fonctions ou requis pour les fonctions principales.

Identifiez ensuite le backend de file d’attente. Les implémentations de files d’attente varient. Laravel, par exemple, documente des connexions utilisant des bases de données relationnelles et Redis, ainsi que d’autres backends (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues). La présence d’une base de données ne signifie pas qu’elle est automatiquement le bon choix pour la file d’attente ; utilisez le backend, les identifiants, la persistance et le modèle opérationnel pris en charge par l’application.

L’état de préparation des dépendances est une autre cause fréquente d’échec de déploiement. Démarrer un conteneur de base de données ou de file d’attente avant un worker ne prouve pas à lui seul que la dépendance est prête à accepter du travail. Docker Compose prend en charge des conditions de dépendance fondées sur des healthchecks, mais la configuration doit les utiliser explicitement. Testez les redémarrages, et pas uniquement le premier démarrage (Docker, « Control Startup and Shutdown Order » : https://docs.docker.com/compose/how-tos/startup-order/).

Enfin, déterminez comment les opérateurs sauront qu’une tâche a échoué. Les journaux de l’application seuls peuvent être insuffisants. La documentation de supervision de Celery distingue notamment les événements reçu, démarré, réussi, échoué et relancé (Celery, « Monitoring and Management Guide » : https://docs.celeryq.dev/en/stable/userguide/monitoring.html). Que votre application fournisse ou non ces événements exacts, définissez les éléments de preuve équivalents dont vous avez besoin avant de vous appuyer sur des workers pour une activité métier importante.

• Quelles commandes officielles de worker et de planificateur l’application prend-elle en charge ?
• Une file d’attente est-elle requise, et quels backends et quelles versions l’application prend-elle en charge ?
• Où les charges utiles des tâches, les résultats, les enregistrements d’échec et les fichiers importés sont-ils conservés ?
• Le worker attend-il que la file d’attente et la base de données soient saines, plutôt qu’un simple démarrage de conteneur ?
• Comment les workers sont-ils redémarrés après un délai d’expiration, un crash, un déploiement ou un redémarrage du serveur ?
• Où un opérateur peut-il voir le travail en attente, en cours, relancé et échoué ?
• Qui peut accéder aux identifiants de la file d’attente, aux journaux des workers et aux données des tâches échouées ?

Concevez pour les relances, les doublons et les échecs partiels

Les relances sont nécessaires pour de nombreuses défaillances transitoires, mais elles peuvent transformer un incident mineur en dommages répétés si le comportement des tâches n’est pas compris. Celery conseille que les fonctions de tâche soient idéalement idempotentes, car un message peut être livré à nouveau après une défaillance d’un worker (Celery, « Tasks » : https://docs.celeryq.dev/en/v5.5.0/userguide/tasks.html). En termes simples, l’exécution deux fois de la même tâche ne doit pas créer un résultat en double inacceptable.

Posez des questions concrètes. Si un worker tombe en panne après avoir envoyé un e-mail mais avant d’avoir enregistré l’achèvement, que se passe-t-il lors de la nouvelle livraison ? Si une importation est relancée, des enregistrements sont-ils dupliqués ? Si un paiement ou une action externe est impliqué, existe-t-il une clé d’idempotence au niveau de l’application ou une autre protection sûre ? Les réponses déterminent si les relances automatiques sont appropriées.

Le moment de l’acquittement du message modifie également le modèle de défaillance. Différents systèmes de file d’attente peuvent acquitter un message avant ou après son exécution, et les implications doivent être vérifiées dans la documentation pertinente de l’application ou du framework. Ne copiez pas les paramètres de relance ou d’acquittement d’une application sans rapport.

Utilisez une récupération bornée. Laravel documente des contrôles tels que le nombre maximal de tentatives, les échéances de relance, le nombre maximal d’exceptions non gérées et les délais de backoff (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues). Le principe se généralise : fixez des limites, ajoutez des délais lorsque cela est pertinent, enregistrez le travail échoué et donnez à une personne ou à une procédure documentée un moyen de l’examiner et de le résoudre.

• Confirmez que les tâches peuvent être répétées sans risque.
• Définissez un nombre maximal de tentatives et un délai de relance ou un backoff délibéré lorsque cela est pris en charge.
• Empêchez les relances répétées de créer des e-mails, enregistrements, fichiers ou actions externes en double.
• Conservez suffisamment de contexte sur la tâche pour examiner un échec sans exposer de données sensibles inutiles.
• Définissez à quel moment les tâches échouées sont relancées manuellement, corrigées, abandonnées ou escaladées.

Estimez la capacité à partir du travail, pas d’une seule métrique serveur

Les indicateurs d’utilisation du processeur et de la mémoire comptent, mais ne répondent pas seuls à la question de la capacité. Un modèle de départ utile combine quatre observations : le nombre de tâches qui arrivent, leur durée, le nombre pouvant s’exécuter simultanément et le moment où les pics surviennent.

Si les tâches arrivent plus vite que les workers ne peuvent les terminer pendant une période prolongée, l’arriéré augmente. Si le travail arrive par courtes pointes, un système peut être suffisant en moyenne tout en laissant les utilisateurs attendre après une campagne, une importation ou une période de rapports planifiés. Mesurez la charge de travail ordinaire séparément de la plus grande pointe attendue.

La concurrence est un levier de capacité, pas une solution universelle. Laravel documente une configuration permettant de définir le nombre de processus workers exécutés simultanément (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues). Davantage de workers simultanés peuvent réduire un arriéré, mais ils augmentent aussi la demande simultanée sur la file d’attente, la base de données, les services externes et le serveur. Une tâche limitée par le travail en base de données, une API distante ou de gros fichiers ne s’améliorera pas nécessairement de manière proportionnelle avec des processus workers supplémentaires.

Commencez prudemment, établissez la profondeur normale de la file d’attente et le temps d’achèvement, puis testez un pic représentatif. Modifiez une seule variable à la fois : regroupement des tâches, concurrence, horaire de planification ou allocation des workers. Conservez les temps de réponse interactifs dans l’évaluation ; une conception avec workers n’est pas réussie si elle vide la file d’attente en dégradant l’application web.

• Taux d’arrivée : combien de tâches sont créées par minute, heure ou jour ?
• Durée des tâches : combien de temps prend chaque tâche avec des volumes de données typiques et lors des pics ?
• Concurrence : combien de tâches peuvent s’exécuter en parallèle en toute sécurité ?
• Périodes de pointe : quand les campagnes, importations, rapports ou travaux planifiés créent-ils des rafales ?
• Délai d’achèvement attendu : à quelle vitesse l’activité a-t-elle besoin du résultat après la soumission d’une tâche ?
• Dépendances partagées : des workers supplémentaires surchargeront-ils la base de données, la file d’attente, le stockage ou le service externe ?

Entourez les services workers de protections opérationnelles

Les workers méritent leur propre visibilité opérationnelle, car leur défaillance peut être moins évidente qu’une indisponibilité du web. Séparez les journaux des workers et du planificateur des journaux de requêtes web lorsque le modèle de déploiement le permet. Cela aide à distinguer une erreur visible par l’utilisateur d’une défaillance de traitement des tâches et facilite le suivi d’une tâche tout au long de son cycle de vie.

Les alertes doivent refléter les conséquences métier. Surveillez les tâches échouées, l’augmentation de la file d’attente, le travail en attente anormalement ancien et la disponibilité des workers. Laravel indique que les workers de production peuvent s’arrêter après des événements tels que des délais d’expiration et recommande une supervision des processus ou un mécanisme équivalent pour détecter les arrêts et redémarrer les workers (Laravel, « Queues » : https://laravel.com/framework/docs/12.x/queues). Le mécanisme de supervision exact dépend du déploiement, mais un worker non supervisé est un point faible prévisible.

Les sauvegardes exigent le même soin que toute autre donnée applicative. Déterminez où est stocké l’état lié aux tâches : base de données de l’application, backend de file d’attente, volume Docker, stockage de fichiers ou plusieurs de ces emplacements. Docker documente les volumes comme adaptés aux flux de sauvegarde, restauration et migration, mais la couverture de sauvegarde doit être vérifiée par rapport au chemin réel des données (Docker, « Volumes » : https://docs.docker.com/engine/storage/volumes/). Un plan de sauvegarde qui omet des données critiques de tâches ou de fichiers importés peut ne pas permettre une restauration significative.

Les contrôles d’accès font également partie de la fiabilité. Les identifiants de la file d’attente, les journaux et les charges utiles de tâches échouées peuvent contenir des informations opérationnelles ou sensibles. Limitez l’accès, documentez les responsabilités et assurez-vous que la rétention des données répond à vos besoins de gouvernance.

• Gardez les journaux web, workers et planificateur distincts.
• Alertez sur les arrêts de workers, les tâches échouées, une profondeur anormale de la file d’attente et l’âge excessif des tâches en attente.
• Utilisez des relances bornées et conservez des éléments sur les tâches échouées pour l’enquête.
• Vérifiez la couverture de sauvegarde et de restauration des bases de données, volumes, fichiers importés et états liés aux tâches.
• Restreignez l’accès aux données des tâches, aux identifiants de file d’attente et aux journaux opérationnels.
• Testez une procédure de redémarrage et de restauration plutôt que de supposer que la configuration est suffisante.