A sua aplicação autoalojada precisa de workers em segundo plano? Um framework prático para decidir

Os workers em segundo plano protegem a experiência interativa

Um pedido web é o trabalho que acontece enquanto uma pessoa espera: abrir um painel, submeter um formulário, guardar um registo ou ver uma página. O pedido deve devolver rapidamente um resultado útil. Um worker em segundo plano é um processo separado que assume trabalho que pode continuar depois de a resposta ter sido enviada.

Esta distinção é importante quando uma ação desencadeia trabalho com duração imprevisível ou prolongada. Enviar um lote de mensagens, analisar um ficheiro carregado, gerar um relatório ou processar conteúdos multimédia pode consumir tempo e recursos muito para além da interação do utilizador que o iniciou. A documentação de filas do Laravel usa a análise e o armazenamento de CSV como exemplo de trabalho que pode demorar demasiado num pedido web normal e que deve, em vez disso, ser processado em segundo plano.

Não trate os workers como um sinal automático de uma implementação madura. Acrescentam componentes, dependências operacionais e modos de falha. A pergunta certa não é «esta aplicação tem uma fila?», mas sim «o trabalho obrigatório desta aplicação cabe de forma segura no caminho do pedido ou precisa de execução e supervisão independentes?»

• Mantenha o processo web focado no tráfego interativo.
• Mova trabalho para segundo plano quando o utilizador não precisa do resultado final antes de continuar.
• Use a documentação da própria aplicação como autoridade para determinar se são necessários workers, um agendador ou um backend de fila.
• Não assuma que todas as aplicações autoalojadas suportam a mesma arquitetura de workers.

Que cargas de trabalho pertencem habitualmente ao segundo plano?

A documentação de frameworks identifica consistentemente o envio de e-mails, o processamento de dados e a manutenção recorrente como casos de utilização de tarefas em segundo plano. Em implementações autoalojadas práticas, o mesmo padrão surge em muitos fluxos de trabalho empresariais, de publicação, análise e automatização.

O fator decisivo não é o nome da funcionalidade. É saber se o trabalho pode ser aceite agora e concluído mais tarde sem fazer o utilizador esperar, desde que a aplicação forneça um estado, notificação ou resultado adequado quando termina.

• Importações e exportações: analisar dados, validar registos, transformar ficheiros e produzir resultados para descarregar.
• Notificações: envio de e-mails, geração de resumos e outras comunicações não imediatas.
• Tarefas agendadas: limpeza regular, manutenção relacionada com faturação, cópias de segurança iniciadas pela aplicação ou atividade de atualização periódica.
• Relatórios: compilar relatórios com uso intensivo de dados ou gerar relatórios recorrentes.
• Processamento multimédia: criar miniaturas, conversões ou outras transformações de ficheiros suportadas pela aplicação.
• Processamento de indexação e relacionado com pesquisa: atualizar índices derivados depois de alterações em conteúdos ou registos.
• Automatização: processar trabalho desencadeado por formulários, integrações ou eventos de fluxos de trabalho.

Use um modelo de cinco partes antes de discutir o tamanho do servidor

Uma implementação com workers é mais fácil de compreender quando as respetivas responsabilidades são separadas. Os nomes exatos variam consoante a aplicação, mas cinco funções repetem-se: o processo web, o agendador, a fila, o worker e o armazenamento persistente de dados.

O processo web recebe tráfego do navegador ou da API. Pode criar uma tarefa e colocar uma referência à mesma numa fila. A fila mantém o trabalho pendente. Um ou mais workers consomem tarefas e executam-nas. Um agendador cria trabalho em horários definidos, enquanto o armazenamento persistente guarda os dados da aplicação e, consoante a arquitetura, também pode guardar informações de filas ou tarefas.

O trabalho agendado e o consumo de filas são diferentes. Um agendador cria trabalho em intervalos; um worker recolhe continuamente o trabalho disponível de uma fila. A documentação do Kubernetes descreve Jobs agendados como úteis para ações como cópias de segurança e geração de relatórios, alertando também que não se deve assumir que o agendamento garante execução exatamente uma vez. O agendador da sua aplicação tem a sua própria semântica, por isso verifique o que garante e planeie o trabalho recorrente em conformidade.

O Docker Compose pode definir vários serviços a partir de uma configuração, e o Docker recomenda separar responsabilidades em vez de colocar todas as funções num único contentor. Isto permite operar os componentes web, worker, fila e base de dados de forma independente quando a aplicação realmente o exige.

• Processo web: serve pedidos interativos.
• Agendador: desencadeia trabalho segundo um calendário recorrente.
• Fila: armazena tarefas pendentes ou referências a tarefas até serem tratadas.
• Worker: executa tarefas em fila fora do caminho do pedido.
• Armazenamento persistente de dados: retém os dados da aplicação e pode reter informações de fila, tarefas ou estado.

Cinco sinais de que o trabalho em segundo plano já está a afetar os utilizadores

A necessidade de workers torna-se habitualmente visível através de sintomas, e não de uma discussão abstrata sobre arquitetura. Procure padrões durante períodos normais e de pico, e não apenas uma ação lenta isolada.

Comece pela duração dos pedidos. Se pedidos demorados voltados para o utilizador coincidirem com importações, relatórios, notificações em lote ou outras ações dispendiosas, o trabalho no caminho do pedido pode estar a competir com o tráfego interativo. Quando estão disponíveis logs de acesso do Traefik, o respetivo campo de duração inclui o tempo total de processamento da resposta, incluindo o tempo do servidor de origem, o que os torna uma fonte útil de evidência sobre a duração dos pedidos.

Depois, observe o próprio ciclo de vida da tarefa. Uma tarefa pode ser aceite, mas atrasada, falhar repetidamente, desaparecer sem visibilidade clara ou competir com o processo web pelos recursos de computação e memória disponíveis. O crescimento da fila é particularmente importante: o Laravel observa que um aumento súbito pode sobrecarregar uma fila e criar uma longa espera até à conclusão.

• Pedidos lentos: os utilizadores esperam visivelmente mais tempo quando são executadas ações intensivas.
• Resultados atrasados: e-mails, importações, relatórios ou outros resultados chegam mais tarde do que o esperado após serem solicitados.
• Trabalho agendado com falhas: manutenção recorrente ou relatórios não são executados de forma fiável, ou é possível haver tratamento duplicado sem controlo.
• Crescimento da fila: o trabalho pendente aumenta e não regressa a um nível normal depois de um pico.
• Contenção de recursos: tarefas longas prejudicam a capacidade de resposta da aplicação web ou de outros serviços obrigatórios.

Responda a estas perguntas sobre dependências antes de adicionar um worker

Um worker não é apenas mais um processo para iniciar. Tem de usar o comando, a configuração, o backend de fila e o modelo de ciclo de vida suportados pela aplicação. Comece pela documentação oficial da versão exata da aplicação que opera. Confirme se o processamento em segundo plano é opcional, recomendado para determinadas funções ou obrigatório para funções essenciais.

Em seguida, identifique o backend de fila. As implementações de fila variam. Por exemplo, o Laravel documenta ligações que usam bases de dados relacionais e Redis, além de outros backends. A presença de uma base de dados não significa que esta seja automaticamente a escolha certa para a fila; use o backend, as credenciais, a persistência e o modelo operacional suportados pela aplicação.

A prontidão das dependências é outra fonte frequente de falhas de implementação. Iniciar um contentor de base de dados ou de fila antes de um worker não prova, por si só, que a dependência está pronta para aceitar trabalho. O Docker Compose suporta condições de dependência baseadas em healthchecks, mas a configuração tem de as usar explicitamente. Teste reinícios, e não apenas o primeiro arranque.

Por fim, determine como os operadores saberão que uma tarefa falhou. Apenas os logs da aplicação podem não ser suficientes. As orientações de monitorização do Celery, por exemplo, distinguem eventos como recebido, iniciado, concluído com sucesso, falhado e repetido. Quer a sua aplicação forneça ou não exatamente esses eventos, defina a evidência equivalente de que necessita antes de depender de workers para atividade empresarial importante.

• Que comandos oficiais de worker e agendador são suportados pela aplicação?
• É necessária uma fila e que backends e versões são suportados pela aplicação?
• Onde são persistidas as cargas úteis das tarefas, os resultados, os registos de falhas e os ficheiros carregados?
• O worker espera por uma fila e uma base de dados saudáveis, em vez de apenas por um contentor iniciado?
• Como são reiniciados os workers após um timeout, falha, implementação ou reinício do servidor?
• Onde pode um operador consultar trabalho pendente, em execução, repetido e falhado?
• Quem pode aceder às credenciais da fila, aos logs dos workers e aos dados de tarefas falhadas?

Conceba para repetições, duplicados e falhas parciais

As repetições são necessárias para muitas falhas transitórias, mas podem transformar uma pequena falha em danos repetidos se o comportamento das tarefas não for compreendido. O Celery aconselha que as funções das tarefas sejam idealmente idempotentes, porque uma mensagem pode ser reenviada após uma falha do worker. Em termos simples, executar a mesma tarefa duas vezes não deve criar um resultado duplicado inaceitável.

Faça perguntas concretas. Se um worker falhar depois de enviar um e-mail, mas antes de registar a conclusão, o que acontece quando a mensagem é reenviada? Se uma importação for repetida, os registos são duplicados? Se estiver envolvida uma ação relacionada com pagamentos ou externa, existe uma chave de idempotência ao nível da aplicação ou outra salvaguarda segura? As respostas determinam se as repetições automáticas são adequadas.

O momento do reconhecimento também altera o modelo de falha. Sistemas de fila diferentes podem reconhecer uma mensagem antes ou depois da execução, e as implicações devem ser verificadas na documentação relevante da aplicação ou do framework. Não copie definições de repetição ou reconhecimento de uma aplicação não relacionada.

Use recuperação limitada. O Laravel documenta controlos como o número máximo de tentativas, tempos de repetição até determinada data, máximo de exceções não tratadas e atrasos de backoff. O princípio é generalizável: defina limites, acrescente atrasos quando apropriado, registe o trabalho falhado e dê a uma pessoa ou a um procedimento documentado uma forma de o inspecionar e resolver.

• Confirme se é seguro repetir as tarefas.
• Defina um número máximo de tentativas e um atraso ou backoff deliberado para repetições, quando suportado.
• Evite que repetições sucessivas criem e-mails, registos, ficheiros ou ações externas duplicados.
• Retenha contexto suficiente sobre a tarefa para investigar uma falha sem expor dados sensíveis desnecessários.
• Defina quando as tarefas falhadas são repetidas manualmente, corrigidas, descartadas ou escaladas.

Estime a capacidade a partir do trabalho, não de uma única métrica do servidor

As leituras de CPU e memória são importantes, mas não respondem sozinhas à questão da capacidade. Um modelo inicial útil combina quatro observações: quantas tarefas chegam, quanto tempo demoram, quantas podem ser executadas em simultâneo e quando ocorrem os picos.

Se as tarefas chegarem mais depressa do que os workers conseguem concluí-las durante um período sustentado, a acumulação cresce. Se o trabalho chegar em picos curtos, um sistema pode ser adequado em média, mas ainda assim deixar os utilizadores à espera depois de uma campanha, importação ou período de relatórios agendados. Meça a carga de trabalho normal separadamente do maior pico esperado.

A concorrência é uma alavanca de capacidade, não uma solução universal. Mais workers em simultâneo podem reduzir uma acumulação, mas também aumentam a procura simultânea sobre a fila, a base de dados, os serviços externos e o servidor. Uma tarefa limitada por trabalho na base de dados, uma API remota ou ficheiros grandes pode não melhorar proporcionalmente com processos de worker adicionais.

Comece de forma conservadora, estabeleça a profundidade normal da fila e o tempo de conclusão, e teste depois um pico representativo. Altere uma variável de cada vez: processamento em lotes, concorrência, horário de agendamento ou alocação de workers. Mantenha os tempos de resposta interativos na avaliação; uma arquitetura de workers não é bem-sucedida se esvaziar a fila degradando a aplicação web.

• Taxa de chegada: quantas tarefas são criadas por minuto, hora ou dia?
• Duração das tarefas: quanto tempo demora cada tarefa com tamanhos de dados típicos e de pico?
• Concorrência: quantas tarefas podem ser executadas em paralelo em segurança?
• Períodos de pico: quando é que campanhas, importações, relatórios ou trabalho agendado criam picos?
• Expectativa de conclusão: quão rapidamente precisa a empresa do resultado após uma tarefa ser submetida?
• Dependências partilhadas: workers adicionais irão sobrecarregar a base de dados, a fila, o armazenamento ou um serviço externo?

Implemente salvaguardas operacionais em torno dos serviços de worker

Os workers merecem visibilidade operacional própria porque a sua falha pode ser menos evidente do que uma indisponibilidade web. Separe os logs de workers e agendadores dos logs de pedidos web quando o modelo de implementação o permitir. Isto ajuda a distinguir um erro voltado para o utilizador de uma falha de processamento de tarefas e facilita o acompanhamento de uma tarefa ao longo do seu ciclo de vida.

Os alertas devem refletir as consequências para a empresa. Monitorize tarefas falhadas, crescimento da fila, trabalho pendente invulgarmente antigo e disponibilidade dos workers. O Laravel observa que os workers de produção podem parar após eventos como timeouts e recomenda monitorização de processos ou um mecanismo equivalente para detetar saídas e reiniciar os workers. O mecanismo exato de supervisão depende da implementação, mas um worker sem supervisão é um ponto fraco previsível.

As cópias de segurança exigem o mesmo cuidado que quaisquer outros dados da aplicação. Determine onde é guardado o estado relacionado com tarefas: na base de dados da aplicação, num backend de fila, num volume Docker, no armazenamento de ficheiros ou em mais do que um destes locais. O Docker documenta volumes como adequados para fluxos de trabalho de cópia de segurança, restauro e migração, mas a cobertura das cópias de segurança deve ser verificada em relação ao percurso real dos dados. Um plano de cópias de segurança que omita dados críticos de tarefas ou de ficheiros carregados pode não permitir um restauro significativo.

Os controlos de acesso também fazem parte da fiabilidade. As credenciais da fila, os logs e as cargas úteis de tarefas falhadas podem conter informações operacionais ou sensíveis. Limite o acesso, documente a responsabilidade e assegure que a retenção de dados corresponde às suas necessidades de governação.

• Mantenha os logs web, de workers e de agendadores distinguíveis.
• Crie alertas para saídas de workers, tarefas falhadas, profundidade anormal da fila e idade excessiva de tarefas pendentes.
• Use repetições limitadas e retenha evidências de tarefas falhadas para investigação.
• Verifique a cobertura de cópia de segurança e restauro para bases de dados, volumes, ficheiros carregados e estado relacionado com tarefas.
• Restrinja o acesso aos dados das tarefas, às credenciais da fila e aos logs operacionais.
• Teste um procedimento de reinício e de restauro em vez de assumir que a configuração é suficiente.