Tarefas em segundo plano

  • Artigo

Muitos tipos de aplicações precisam de tarefas em segundo plano que são executadas independentemente da interface de utilizador (IU). Os exemplos incluem tarefas de lote, tarefas de processamento intensivas e processos de longa execução, como os fluxos de trabalho. As tarefas em segundo plano podem ser executadas sem interação do utilizador – a aplicação pode iniciar a tarefa e, em seguida, continuar a processar pedidos interativos dos utilizadores. Isto pode ajudar a minimizar a carga sobre a IU da aplicação, o que pode melhorar a disponibilidade e reduzir os tempos de resposta interativos.

Por exemplo, se uma aplicação precisar de gerar miniaturas de imagens que são carregadas por utilizadores, pode fazê-lo como uma tarefa em segundo plano e guardar a miniatura no armazenamento quando estiver concluída – sem que o utilizador tenha de aguardar que o processo seja concluído. Da mesma forma, um utilizador que faz um pedido pode iniciar um fluxo de trabalho em segundo plano que processa o pedido, enquanto a IU permite ao utilizador continuar a navegar na aplicação Web. Quando a tarefa em segundo plano estiver concluída, pode atualizar os dados dos pedidos armazenados e enviar um e-mail ao utilizador que confirma o pedido.

Quando considerar se deseja implementar uma tarefa como uma tarefa em segundo plano, o critério principal é se a tarefa pode ser executada sem interação do utilizador e sem a IU ter de aguardar que a tarefa seja concluída. As tarefas que exigem que o utilizador ou a IU tenha de esperar enquanto estas são concluídas, podem não ser apropriadas como tarefas em segundo plano.

Tipos de tarefas em segundo plano

As tarefas em segundo plano incluem, geralmente, um ou mais dos seguintes tipos de tarefas:

  • Tarefas com utilização intensiva da CPU, como cálculos matemáticos ou a análise estrutural de modelo.
  • Tarefas com utilização intensiva da E/S, como a execução de uma série de transações de armazenamento ou indexação de ficheiros.
  • Tarefas de lote, como atualizações noturnas de dados ou processamento agendado.
  • Fluxos de trabalho de longa execução, como a execução de pedidos ou o aprovisionamento de sistemas e serviços.
  • Processamento de dados sensíveis em que a tarefa é entregue a uma localização mais segura para processamento. Por exemplo, não deverá processar dados confidenciais numa aplicação Web. Em vez disso, você pode usar um padrão como o padrão Gatekeeper para transferir os dados para um processo em segundo plano isolado que tenha acesso ao armazenamento protegido.

Acionadores

As tarefas em segundo plano podem ser iniciadas de várias formas diferentes. Elas enquadram-se numa das seguintes categorias:

  • Acionadores desencadeados por eventos. A tarefa é iniciada em resposta a um evento, normalmente uma ação tomada por um utilizador ou um passo num fluxo de trabalho.
  • Acionadores desencadeados pela agenda. A tarefa é invocada de acordo com uma agenda baseada num temporizador. Pode ser uma agenda recorrente ou uma invocação pontual especificada para um horário posterior.

Acionadores desencadeados por eventos

A invocação desencadeada por eventos utiliza um acionador para iniciar a tarefa em segundo plano. Exemplos de como utilizar acionadores desencadeados por eventos:

  • A IU ou outra tarefa coloca uma mensagem numa fila. A mensagem contém dados sobre uma ação que foi tomada, como por exemplo, o utilizador realizar um pedido. A tarefa em segundo plano escuta esta fila e deteta a chegada de uma nova mensagem. Lê a mensagem e utiliza os dados como entrada para a tarefa em segundo plano. Esse padrão é conhecido como comunicação assíncrona baseada em mensagem.
  • A IU ou outra tarefa guarda ou atualiza um valor no armazenamento. A tarefa em segundo plano monitoriza o armazenamento e deteta alterações. Lê os dados e utiliza-os como entrada para a tarefa em segundo plano.
  • A IU ou outra tarefa faz um pedido para um ponto final, como um URI de HTTPS ou uma API que está exposta como um serviço Web. Transmite os dados necessários para concluir a tarefa em segundo plano como parte do pedido. O ponto final ou o serviço Web invoca a tarefa em segundo plano, que utiliza os dados como entrada.

Os exemplos típicos de tarefas que são adequadas para a invocação desencadeada por eventos incluem o processamento de imagens, fluxos de trabalho, enviar informações para serviços remotos, enviar mensagens de e-mail e aprovisionar novos utilizadores em aplicações multi-inquilino.

Acionadores desencadeados pela agenda

A invocação desencadeada pela agenda utiliza um temporizador para iniciar a tarefa em segundo plano. Exemplos de como utilizar acionadores desencadeados pela agenda:

  • Um temporizador que está sendo executado localmente dentro do aplicativo ou como parte do sistema operacional do aplicativo invoca uma tarefa em segundo plano regularmente.
  • Um temporizador que está sendo executado em um aplicativo diferente, como os Aplicativos Lógicos do Azure, envia uma solicitação para uma API ou serviço Web regularmente. A API ou o serviço Web invoca a tarefa em segundo plano.
  • Um processo separado ou uma aplicação inicia um temporizador que faz com que a tarefa em segundo plano seja invocada uma vez depois de um tempo de atraso especificado ou num momento específico.

Os exemplos típicos de tarefas que são adequadas para a invocação desencadeada pela agenda incluem rotinas de processamento em lote (por exemplo, atualizar listas relacionadas com produtos para utilizadores com base no seu comportamento recente), tarefas de processamento de dados de rotina (por exemplo, atualizar índices ou gerar resultados acumulados), análise de dados para relatórios diários, limpeza de retenção de dados e verificações de consistência dos dados.

Se utilizar uma tarefa desencadeada pela agenda que deve ser executada como uma única instância, tenha em atenção o seguinte:

  • Se a instância de computação que está a executar o agendador (por exemplo, uma máquina virtual que utiliza tarefas agendadas do Windows) é ajustada, terá várias instâncias do agendador em execução. Estas poderão iniciar várias instâncias da tarefa. Para obter mais informações sobre isso, leia esta postagem no blog sobre idempotência.
  • Se as tarefas são executadas por mais tempo do que o período entre os eventos do agendador, o agendador pode começar outra instância da tarefa enquanto a anterior ainda está em execução.

Devolver resultados

As tarefas em segundo plano são executadas de forma assíncrona num processo separado, ou mesmo numa localização separada, a partir da IU ou do processo que invocou a tarefa em segundo plano. Idealmente, as tarefas em segundo plano são operações de "disparar e esquecer", e seu progresso de execução não tem impacto na interface do usuário ou no processo de chamada. Isto significa que o processo da chamada não aguarda pela conclusão das tarefas. Por isso, não consegue detetar automaticamente quando a tarefa termina.

Se precisar de uma tarefa em segundo plano para comunicar com a tarefa da chamada para indicar o progresso ou a conclusão, tem de implementar um mecanismo para isto. Alguns exemplos são:

  • Escrever um valor do indicador de estado para o armazenamento que está acessível para a tarefa da IU ou do autor da chamada, que pode monitorizar ou verificar este valor quando necessário. Podem ser colocados outros dados que a tarefa em segundo plano tem de devolver ao autor da chamada no mesmo armazenamento.
  • Estabelece uma fila de resposta que a IU ou o autor da chamada escuta. A tarefa em segundo plano pode enviar mensagens para a fila que indicam o estado e a conclusão. Podem ser colocados dados que a tarefa em segundo plano tem de devolver ao autor da chamada nas mensagens. Se estiver a utilizar o Azure Service Bus, pode utilizar as propriedades ReplyTo e CorrelationId para implementar esta capacidade.
  • Exponha uma API ou ponto final a partir da tarefa em segundo plano que a IU ou o autor da chamada podem aceder para obter informações do estado. Podem ser incluídos dados que a tarefa em segundo plano tem de devolver ao autor da chamada na resposta.
  • A tarefa em segundo plano devolve a chamada à IU ou ao autor da chamada através de uma API para indicar o estado em pontos predefinidos ou após a conclusão. Esta ação pode ocorrer através de eventos gerados localmente ou através de um mecanismo de publicação e subscrição. Podem ser incluídos dados que a tarefa em segundo plano tem de devolver ao autor da chamada no pedido ou no payload do evento.

Ambiente de alojamento

Pode alojar tarefas em segundo plano com uma variedade de diferentes serviços da plataforma do Azure:

  • Aplicações Web do Azure e WebJobs. Pode utilizar o WebJobs para executar tarefas personalizadas com base numa variedade de diferentes tipos de scripts ou programas executáveis dentro do contexto de uma aplicação Web.
  • Funções do Azure. Você pode usar funções para trabalhos em segundo plano que não são executados por muito tempo. Outro caso de uso é se sua carga de trabalho já estiver hospedada no plano do Serviço de Aplicativo e estiver subutilizada.
  • Máquinas Virtuais do Azure. Se tiver um serviço Windows ou pretende utilizar o Programador de Tarefas do Windows, é comum alojar as suas tarefas em segundo plano numa máquina virtual dedicada.
  • Azure Batch. O Batch é um serviço de plataforma que agenda trabalho com utilização intensiva de computação para executar numa coleção gerida de máquinas virtuais. Pode dimensionar automaticamente recursos de computação.
  • Serviço Kubernetes do Azure (AKS). O Serviço Kubernetes do Azure fornece um ambiente de hospedagem gerenciado para o Kubernetes no Azure.
  • Aplicativos de contêiner do Azure. Os Aplicativos de Contêiner do Azure permitem que você crie microsserviços sem servidor com base em contêineres.

As seções a seguir descrevem essas opções com mais detalhes e incluem considerações para ajudá-lo a escolher a opção apropriada.

Aplicações Web e WebJobs do Azure

Pode utilizar o WebJobs do Azure para executar tarefas personalizadas como tarefas em segundo plano numa aplicação Web do Azure. O WebJobs é executado no contexto da sua aplicação Web como um processo contínuo. Os WebJobs também são executados em resposta a um evento de gatilho dos Aplicativos Lógicos do Azure ou a fatores externos, como alterações em blobs de armazenamento e filas de mensagens. As tarefas podem ser iniciadas e paradas a pedido, e encerradas facilmente. Se um WebJob em execução contínua falhar, é reiniciado automaticamente. As ações de repetição e erro são configuráveis.

Quando configura um WebJob:

  • Se pretender que a tarefa responda a um acionador desencadeado por eventos, deve configurá-la para Executar continuamente. O script ou o programa é armazenado na pasta site/wwwroot/aplicação_dados/tarefas/contínua.
  • Se pretender que a tarefa responda a um acionador desencadeado pela agenda, deve configurá-la para Executar com base numa agenda. O script ou o programa é armazenado na pasta site/wwwroot/aplicação_dados/tarefas/acionada.
  • Se escolher a opção Executar a pedido ao configurar uma tarefa, esta irá executar o mesmo código que a opção Executar com base numa agenda ao iniciá-la.

O WebJobs do Azure é executado na sandbox da aplicação Web. Isto significa que pode aceder a variáveis de ambiente e partilhar informações, como cadeias de ligação com a aplicação Web. A tarefa tem acesso ao identificador exclusivo do computador que está a executar a tarefa. A cadeia de conexão chamada AzureWebJobsStorage fornece acesso a filas, blobs e tabelas do Armazenamento do Azure para dados de aplicativos e acesso ao Service Bus para mensagens e comunicação. A cadeia de ligação AzureWebJobsDashboard concede acesso aos ficheiros de registo da ação de tarefa.

O WebJobs do Azure tem as seguintes características:

  • Segurança: o WebJobs está protegido pelas credenciais de implementação da aplicação Web.
  • Tipos de arquivo suportados: Você pode definir WebJobs usando scripts de comando (.cmd), arquivos em lote (.bat), scripts PowerShell (.ps1), scripts shell Bash (.sh), scripts PHP (.php), scripts Python (.py), código JavaScript (.js) e programas executáveis (.exe, .jare muito mais).
  • Implantação: você pode implantar scripts e executáveis usando o portal do Azure, usando o Visual Studio, usando o SDK de WebJobs do Azure ou copiando-os diretamente para os seguintes locais:
    • Para execução acionada: site/wwwroot/aplicação_dados/tarefas/acionada/{job name}
    • Para execução contínua: site/wwwroot/aplicação_dados/tarefas/contínua/{job name}
  • Registo: O Console.Out é tratado (marcado) como INFORMAÇÃO. O Console.Error é tratado como ERRO. Pode aceder às informações de monitorização e diagnóstico com o portal do Azure. Pode transferir os ficheiros de registo diretamente do site. Eles são salvos nos seguintes locais:
    • Para execução acionada: Vfs/dados/tarefas/acionada/jobName
    • Para execução contínua: Vfs/dados/tarefas/contínua/jobName
  • Configuração: pode configurar o WebJobs com o portal, a API REST e o PowerShell. Pode utilizar um ficheiro de configuração denominado settings.job no mesmo diretório de raiz que o script da tarefa para dar informações de configuração de uma tarefa. Por exemplo:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Considerações

  • Por predefinição, o WebJobs é ajustado com a aplicação Web. No entanto, pode configurar tarefas para serem executadas numa única instância, ao definir a propriedade de configuração is_singleton para verdadeiro. O WebJobs de instância única é útil para tarefas que não pretende dimensionar ou executar como múltiplas instâncias simultâneas, como a reindexação, a análise de dados e tarefas semelhantes.
  • Para minimizar o impacto dos trabalhos no desempenho do aplicativo Web, considere a criação de uma instância vazia do Aplicativo Web do Azure em um novo plano do Serviço de Aplicativo para hospedar WebJobs de longa execução ou que consomem muitos recursos.

Funções do Azure

Uma opção semelhante ao WebJobs é o Azure Functions. Este serviço é sem servidor que é mais adequado para gatilhos controlados por eventos que são executados por um curto período. Uma função também pode ser usada para executar trabalhos agendados através de gatilhos de temporizador, quando configurada para ser executada em horários definidos.

O Azure Functions não é uma opção recomendada para tarefas grandes e de longa execução porque podem causar problemas inesperados de tempo limite. No entanto, dependendo do plano de hospedagem, eles podem ser considerados para gatilhos orientados por agendamento.

Considerações

Se se espera que a tarefa em segundo plano seja executada por uma curta duração em resposta a um evento, considere executá-la em um plano de consumo. O tempo de execução é configurável até um tempo máximo. Uma função que funciona por mais tempo custa mais. Além disso, trabalhos intensivos em CPU que consomem mais memória podem ser mais caros. Se você usar gatilhos adicionais para serviços como parte de sua tarefa, eles serão cobrados separadamente.

O plano Premium é mais adequado se você tiver um grande número de tarefas que são curtas, mas espera-se que sejam executadas continuamente. Este plano é mais caro porque precisa de mais memória e CPU. A vantagem é que você pode usar recursos como a integração de rede virtual.

O plano Dedicado é mais adequado para trabalhos em segundo plano se a sua carga de trabalho já for executada nele. Se você tiver VMs subutilizadas, poderá executá-las na mesma VM e compartilhar os custos de computação.

Para mais informações, consulte estes artigos:

Máquinas Virtuais do Microsoft Azure

As tarefas em segundo plano podem ser implementadas de uma forma que impeça que sejam implantadas nos Aplicativos Web do Azure ou essas opções podem não ser convenientes. Os exemplos típicos incluem os serviços Windows, utilitários de terceiros e programas executáveis. Outro exemplo poderá ser os programas escritos para um ambiente de execução que é diferente do que aloja a aplicação. Por exemplo, poderá ser um programa Unix ou Linux que pretende executar a partir de uma aplicação do Windows ou .NET. Pode escolher entre uma variedade de sistemas operativos para uma máquina virtual do Azure e executar o serviço ou a executável nessa máquina virtual.

Para o ajudar a escolher quando deve utilizar Máquinas Virtuais, veja Serviço de Aplicações do Azure, Serviços Cloud e Máquinas Virtuais. Para obter informações sobre as opções de máquinas virtuais, consulte Tamanhos para máquinas virtuais do Windows no Azure. Para obter mais informações sobre os sistemas operativos e as imagens pré-criadas que estão disponíveis para as Máquinas Virtuais, veja Marketplace das Máquinas Virtuais do Azure.

Para iniciar a tarefa em segundo plano numa máquina virtual separada, tem diversas opções:

  • Pode executar a tarefa a pedido diretamente a partir da sua aplicação, ao enviar um pedido para um ponto final que expõe a tarefa. Isto ocorre em todos os dados que a tarefa precisa. Este ponto final invoca a tarefa.
  • Pode configurar a tarefa para ser executada com base numa agenda através de um agendador ou temporizador que está disponível no sistema operativo escolhido. Por exemplo, no Windows pode utilizar o Programador de Tarefas do Windows para executar scripts e tarefas. Em alternativa, se tiver o SQL Server instalado na máquina virtual, pode utilizar o SQL Server Agent para executar scripts e tarefas.
  • Você pode usar os Aplicativos Lógicos do Azure para iniciar a tarefa adicionando uma mensagem a uma fila na qual a tarefa escuta ou enviando uma solicitação para uma API exposta pela tarefa.

Veja a secção anterior Acionadores para obter mais informações sobre como pode iniciar tarefas em segundo plano.

Considerações

Quando estiver a decidir se vai implementar tarefas em segundo plano numa máquina virtual do Azure, considere os seguintes pontos:

  • Alojar tarefas em segundo plano numa máquina virtual do Azure separada oferece flexibilidade e permite um controlo preciso sobre a iniciação, a execução, o agendamento e a alocação de recursos. No entanto, irá aumentar os custos do runtime se tiver de implementar uma máquina virtual apenas para executar tarefas em segundo plano.
  • Não existe um local para monitorizar as tarefas no portal do Azure, nem uma capacidade de reinício automático para as tarefas com falha – no entanto, pode monitorizar o estado básico da máquina virtual e geri-lo com os Cmdlets do Azure Resource Manager. No entanto, não existem locais para controlar os processos e os threads nos nós de computação. Normalmente, a utilização de uma máquina virtual irá exigir um esforço adicional para implementar um mecanismo que recolhe dados a partir da instrumentação na tarefa e a partir do sistema operativo na máquina virtual. Utilizar o Pacote de Gestão do System Center para o Azure pode ser uma solução adequada.
  • Pode considerar a criação de sondas de monitorização que estão expostas através de pontos finais HTTP. O código para estas sondas pode executar verificações do estado de funcionamento, recolher informações operacionais e estatísticas – ou agrupar informações de erro e devolve-las a uma aplicação de gestão. Para obter mais informações, consulte o padrão Health Endpoint Monitoring.

Para obter mais informações, consulte:

Azure Batch

Considere o Azure Batch se precisar de executar cargas de trabalho de computação grandes e paralelas de elevado desempenho (HPC) em dezenas, centenas ou milhares de VMs.

O serviço do Batch aprovisiona as VMs, atribui tarefas às VMs, executa as tarefas e monitoriza o progresso. O Batch pode aumentar horizontalmente as VMs de forma automática em resposta à carga de trabalho. O Batch também concede o agendamento de tarefas. O Azure Batch suporta VMs do Linux e do Windows.

Considerações

O Batch funciona bem com cargas de trabalho intrinsecamente paralelas. Também pode realizar cálculos paralelos com um passo de redução no final ou executar aplicações de Interface de Passagem de Mensagens (MPI) para tarefas paralelas que exigem a passagem de mensagens entre nós.

É executada uma tarefa do Azure Batch num conjunto de nós (VMs). Uma abordagem é alocar um conjunto apenas quando for necessário e, em seguida, eliminá-lo assim que a tarefa for concluída. Isto maximiza a utilização porque os nós não estão inativos, mas a tarefa tem de aguardar que os nós estejam alocados. Em alternativa, pode criar um conjunto antecipadamente. Essa abordagem minimiza o tempo que a tarefa demora a iniciar, mas pode resultar em nós que ficam inativos. Para obter mais informações, veja Duração do nó de computação e do conjunto.

Para obter mais informações, consulte:

Azure Kubernetes Service

O Serviço Kubernetes do Azure (AKS) gerencia seu ambiente Kubernetes hospedado, o que facilita a implantação e o gerenciamento de aplicativos em contêineres.

Os contentores podem ser úteis para executar tarefas em segundo plano. Alguns dos benefícios incluem:

  • Os contentores suportam alojamento de alta densidade. Pode isolar uma tarefa em segundo plano num contentor enquanto coloca vários contentores em cada VM.
  • O orquestrador de contentores processa o balanceamento de carga interna, configura a rede interna e realiza outras tarefas de configuração.
  • Os contentores podem ser iniciados e parados conforme necessário.
  • O Azure Container Registry permite-lhe registar os seus contentores dentro dos limites do Azure. Isto inclui benefícios de segurança, privacidade e proximidade.

Considerações

  • Exige uma compreensão sobre como utilizar o orquestrador do contentor. Dependendo do conjunto de habilidades da sua equipe de DevOps, isso pode ou não ser um problema.

Para obter mais informações, consulte:

Azure Container Apps

Os Aplicativos de Contêiner do Azure permitem que você crie microsserviços sem servidor com base em contêineres. Os recursos distintivos dos Container Apps incluem:

  • Otimizado para executar contêineres de uso geral, especialmente para aplicativos que abrangem muitos microsserviços implantados em contêineres.
  • Desenvolvido por Kubernetes e tecnologias de código aberto como Dapr, Kubernetes Event-driven Autoscaling (KEDA) e envoy.
  • Suporta aplicativos e microsserviços no estilo Kubernetes com recursos como descoberta de serviços e divisão de tráfego.
  • Permite arquiteturas de aplicativos orientadas a eventos, oferecendo suporte à escala com base no tráfego e extraindo de fontes de eventos, como filas, incluindo escala até zero.
  • Suporte de processos de longa execução e pode executar tarefas em segundo plano.

Considerações

Os Aplicativos de Contêiner do Azure não fornecem acesso direto às APIs subjacentes do Kubernetes. Se você precisar de acesso às APIs do Kubernetes e ao plano de controle, deverá usar o Serviço Kubernetes do Azure. No entanto, se você quiser criar aplicativos no estilo Kubernetes e não precisar de acesso direto a todas as APIs nativas do Kubernetes e gerenciamento de cluster, o Container Apps oferece uma experiência totalmente gerenciada com base nas práticas recomendadas. Por esses motivos, muitas equipes podem preferir começar a criar microsserviços de contêiner com os Aplicativos de Contêiner do Azure.

Para obter mais informações, consulte:

Você pode começar a criar seu primeiro aplicativo de contêiner usando os inícios rápidos.

Criação de partições

Se você decidir incluir tarefas em segundo plano em uma instância de computação existente, deverá considerar como isso afetará os atributos de qualidade da instância de computação e a própria tarefa em segundo plano. Estes fatores irão ajudá-lo a decidir se pretende colocar as tarefas com a instância de computação existente ou separá-las numa instância de computação separada:

  • Disponibilidade: as tarefas em segundo plano não precisam de ter o mesmo nível de disponibilidade como as outras partes da aplicação, em particular a IU e outras partes diretamente envolvidas na interação do utilizador. As tarefas em segundo plano podem ter mais tolerância à latência, falhas de nova tentativa de ligação e outros fatores que afetam a disponibilidade, porque as operações podem ser colocadas em fila. No entanto, tem de existir capacidade suficiente para impedir a cópia de segurança de pedidos que pode bloquear filas e afetar a aplicação como um todo.

  • Escalabilidade: é provável que as tarefas em segundo plano tenham um requisito de escalabilidade diferente da IU e das partes interativas da aplicação. O dimensionamento da interface do usuário pode ser necessário para atender a picos de demanda, enquanto tarefas pendentes em segundo plano podem ser concluídas durante períodos menos ocupados por menos instâncias de computação.

  • Resiliência: a falha de uma instância de computação que aloja apenas tarefas em segundo plano pode não afetar fatalmente a aplicação como um todo se os pedidos para estas tarefas puderem ser colocados em fila ou adiados até que a tarefa esteja novamente disponível. Se a instância ou tarefas de computação puderem ser reiniciadas dentro de um intervalo apropriado, os usuários do aplicativo poderão não ser afetados.

  • Segurança: as tarefas em segundo plano podem ter diferentes requisitos de segurança ou restrições da IU ou de outras partes da aplicação. Ao utilizar uma instância de computação separada, pode especificar um ambiente de segurança diferente para as tarefas. Também pode utilizar padrões como o Gatekeeper para isolar as instâncias de computação em segundo plano da IU, para maximizar a segurança e a separação.

  • Desempenho: pode escolher o tipo de instância de computação para as tarefas em segundo plano para corresponder especificamente aos requisitos de desempenho das tarefas. Isto pode significar a utilização de uma opção de computação menos dispendiosa, se as tarefas não exigirem as mesmas capacidades de processamento que a IU, ou uma instância maior se exigirem capacidade adicional e recursos.

  • Capacidade de gestão: as tarefas em segundo plano podem ter um ritmo de desenvolvimento e implementação diferentes do código da aplicação principal ou da IU. Pode simplificar as atualizações e o controlo de versões ao implementá-las numa instância de computação separada.

  • Custo: adicionar instâncias de computação para executar tarefas em segundo plano aumenta os custos de alojamento. Pondere cuidadosamente o equilíbrio entre a capacidade adicional e estes custos adicionais.

Para obter mais informações, consulte o padrão Eleição do líder e o padrão Consumidores concorrentes.

Conflitos

Se tiver várias instâncias de uma tarefa em segundo plano, é possível que estas compitam para terem acesso a recursos e serviços, como bases de dados e armazenamento. Este acesso simultâneo pode resultar em contenção de recursos, o que poderá causar conflitos na disponibilidade dos serviços e na integridade dos dados no armazenamento. Pode resolver a contenção de recursos com uma abordagem de bloqueio pessimista. Isto impede que as instâncias concorrentes de uma tarefa acedam simultaneamente a um serviço ou danifiquem dados.

Outra abordagem para resolver conflitos consiste em definir tarefas em segundo plano como singleton, de modo a que exista sempre e apenas uma única instância em execução. No entanto, isto elimina as vantagens de fiabilidade e desempenho que uma configuração de várias instâncias pode oferecer. O que é particularmente verdadeiro se a IU fornecer trabalho suficiente para manter mais do que uma tarefa em segundo plano ocupada.

É fundamental assegurar que a tarefa em segundo plano pode reiniciar automaticamente e ter capacidade suficiente para lidar com picos a pedido. Pode conseguir isto ao alocar uma instância de computação com recursos suficientes, através da implementação de um mecanismo de colocação em fila que pode armazenar pedidos para posterior execução quando a procura diminui ou através da combinação destas técnicas.

Coordenação

As tarefas em segundo plano podem ser complexas e podem exigir várias tarefas individuais a serem executadas para produzir um resultado ou para cumprir todos os requisitos. É comum nestes cenários dividir a tarefa em passos mais pequenos e discretos ou subtarefas que podem ser executadas por vários consumidores. As tarefas com vários passos podem ser mais eficientes e flexíveis porque os passos individuais podem ser reutilizáveis em várias tarefas. Também é fácil adicionar, remover ou modificar a ordem dos passos.

Coordenar várias tarefas e passos pode ser um desafio, mas existem três padrões comuns que pode utilizar para guiar a sua implementação de uma solução:

  • Decompor uma tarefa em vários passos reutilizáveis. Pode ser preciso uma aplicação para realizar uma série de tarefas de complexidade variada nas informações que vai processar. Uma abordagem simples, mas inflexível, para implementar esta aplicação pode consistir em realizar este processamento como um módulo monolítico. No entanto, é provável que esta abordagem reduza as oportunidades para refatorizar o código, ao otimizá-lo ou reutilizá-lo se forem precisas partes do mesmo processamento noutro local na aplicação. Para obter mais informações, consulte o padrão Pipes and Filters.

  • Gerir a execução dos passos para uma tarefa. Uma aplicação pode realizar tarefas que compõem um número de passos (alguns dos quais podem invocar serviços remotos ou aceder a recursos remotos). Os passos individuais podem ser independentes entre si, mas são orquestrados pela lógica da aplicação que implementa a tarefa. Para obter mais informações, consulte Scheduler Agent Supervisor pattern.

  • Gestão da recuperação para passos com falhas. Uma aplicação pode precisar de anular o trabalho realizado por uma série de passos, que em conjunto definem uma operação eventualmente consistente, em caso de falha de um ou mais passos. Para obter mais informações, consulte o padrão de transação de compensação.

Considerações de resiliência

As tarefas em segundo plano têm de ser resilientes para oferecer serviços fiáveis à aplicação. Quando estiver a planear e a criar tarefas em segundo plano, considere os seguintes pontos:

  • As tarefas em segundo plano devem ser capazes de lidar normalmente com reinicializações sem corromper dados ou introduzir inconsistência no aplicativo. Para tarefas de longa execução ou com vários passos, considere utilizar o apontador de verificação ao guardar o estado das tarefas no armazenamento persistente ou como mensagens numa fila se esta ação for adequada. Por exemplo, pode manter as informações de estado de uma mensagem numa fila e atualizar incrementalmente estas informações de estado com o progresso da tarefa, para que a tarefa possa ser processada a partir do último bom ponto de verificação conhecido – em vez de reiniciar a partir do início. Quando utilizar filas do Azure Service Bus, pode utilizar sessões de mensagens para ativar o mesmo cenário. As sessões permitem-lhe guardar e obter o estado de processamento da aplicação com os métodos SetState e GetState. Para obter mais informações sobre como projetar processos e fluxos de trabalho confiáveis de várias etapas, consulte o padrão Scheduler Agent Supervisor.

  • Quando utiliza filas para comunicar com tarefas em segundo plano, as filas podem atuar como uma memória intermédia para armazenar os pedidos que são enviados para as tarefas enquanto a aplicação se encontra sob uma carga superior ao habitual. Isto permite que as tarefas alcancem a IU em períodos menos ocupados. Isso também significa que as reinicializações não bloquearão a interface do usuário. Para obter mais informações, consulte o padrão de nivelamento de carga baseado em fila. Se algumas tarefas forem mais importantes do que outras, considere implementar o padrão de fila de prioridades para garantir que essas tarefas sejam executadas antes das menos importantes.

  • As tarefas em segundo plano, que são iniciadas por mensagens ou processam mensagens, têm de ser criadas para lidar com inconsistências, como mensagens que chegam desordenadas, mensagens que originam um erro repetidamente (normalmente designadas como mensagens não processáveis) e mensagens que são enviadas mais do que uma vez. Considere o seguinte:

    • As mensagens que têm de ser processadas numa ordem específica, como as que alteram dados com base no valor dos dados existentes (por exemplo, ao adicionar um valor a um valor existente), podem não chegar pela ordem original em que foram enviadas. Em alternativa, podem ser processadas por várias instâncias de uma tarefa em segundo plano por uma ordem diferente devido a cargas variadas em cada instância. As mensagens que têm de ser processadas numa ordem específica devem incluir um número de sequência, uma chave ou outro indicador que as tarefas em segundo plano podem utilizar para se certificarem que são processadas na ordem correta. Se estiver a utilizar o Azure Service Bus, pode utilizar sessões de mensagens para garantir a ordem de entrega. No entanto, sempre que possível, é geralmente mais eficiente criar o processo, para que a ordem da mensagem não seja importante.

    • Normalmente, uma tarefa em segundo plano irá espreitar as mensagens na fila, o que as esconde temporariamente dos outros consumidores de mensagens. Em seguida, elimina as mensagens após terem sido processadas com êxito. Se uma tarefa em segundo plano falhar ao processar uma mensagem, essa mensagem voltará a aparecer na fila após o tempo limite da espreita expirar. Voltará a ser processada por outra instância da tarefa ou durante o próximo ciclo de processamento desta instância. Se a mensagem causa um erro consistentemente no consumidor, esta irá bloquear a tarefa, a fila e, eventualmente, a própria aplicação quando a fila encher. Por conseguinte, é fundamental detetar e remover mensagens não processáveis da fila. Se você estiver usando o Barramento de Serviço do Azure, as mensagens que causam um erro podem ser movidas automática ou manualmente para uma fila de letras mortas associada.

    • As filas são garantidas em, pelo menos, um mecanismo de entrega, mas poderão enviar a mesma mensagem mais do que uma vez. Além disso, se uma tarefa em segundo plano falhar após o processamento de uma mensagem mas antes da eliminação da fila, a mensagem estará disponível para ser novamente processada. As tarefas em segundo plano devem ser idempotentes, o que significa que processar a mesma mensagem mais de uma vez não causa um erro ou inconsistência nos dados do aplicativo. Algumas operações são naturalmente idempotentes, como definir um valor armazenado para um novo valor específico. No entanto, operações como adicionar um valor a um valor armazenado existente sem verificar que o valor armazenado é o mesmo quando a mensagem foi originalmente enviada irá causar inconsistências. As filas do Azure Service Bus podem ser configuradas para remover automaticamente mensagens duplicadas. Para obter mais informações sobre os desafios com a entrega de mensagens pelo menos uma vez, consulte as orientações sobre processamento idempotente de mensagens.

    • Alguns sistemas de mensagens, como o Armazenamento de Filas do Azure e as filas do Barramento de Serviço do Azure, dão suporte a uma propriedade de contagem de eliminação de filas que indica o número de vezes que uma mensagem foi lida da fila. Isto pode ser útil no processamento de mensagens repetidas e não processáveis. Para obter mais informações, veja Manual Básico de Mensagens Assíncronas e Padrões de Idempotência.

Considerações de desempenho e dimensionamento

As tarefas em segundo plano têm de oferecer desempenho suficiente para se certificar de que não bloqueiam a aplicação ou provocam inconsistências devido à operação atrasada quando o sistema está sob carga. Normalmente, o desempenho é melhorado ao dimensionar as instâncias de computação que alojam as tarefas em segundo plano. Quando estiver a planear e a criar tarefas em segundo plano, considere os seguintes pontos sobre escalabilidade e desempenho:

  • O Azure dá suporte ao dimensionamento automático (dimensionamento e redimensionamento) com base na demanda e carga atuais ou em um cronograma predefinido, para implantações hospedadas de Aplicativos Web e Máquinas Virtuais. Utilize esta funcionalidade para garantir que a aplicação completa tem capacidades suficientes de desempenho e minimiza os custos do runtime.

  • Quando as tarefas em segundo plano têm uma capacidade de desempenho diferente das outras partes de um aplicativo (por exemplo, a interface do usuário ou componentes, como a camada de acesso a dados), hospedar as tarefas em segundo plano juntas em um serviço de computação separado permite que a interface do usuário e as tarefas em segundo plano sejam dimensionadas independentemente para gerenciar a carga. Se várias tarefas em segundo plano tiverem capacidades de desempenho significativamente diferentes umas das outras, considere dividi-las e dimensionar cada tipo de forma independente. No entanto, observe que isso pode aumentar os custos de tempo de execução.

  • Simplesmente dimensionar os recursos de computação pode não ser suficiente para evitar a perda de desempenho sob carga. Também poderá precisar de aumentar as filas de armazenamento e outros recursos para impedir que um ponto único do processamento geral da cadeia se torne um estrangulamento. Além disso, considere outras limitações, como o débito máximo de armazenamento e outros serviços que a aplicação e as tarefas em segundo plano dependem.

  • As tarefas em segundo plano têm de ser criadas para dimensionamento. Por exemplo, têm de ser capazes de detetar dinamicamente o número de filas de armazenamento em utilização para escutar ou enviar mensagens para a fila adequada.

  • Por predefinição, o WebJobs dimensiona com a instância das Aplicações Web do Azure associada. No entanto, se pretender que um WebJob seja executado como uma única instância, pode criar um ficheiro Settings.job que contém os dados JSON { "is_singleton": true }. Isto força o Azure a executar apenas uma instância do WebJob, mesmo se existirem várias instâncias da aplicação Web associada. Isto pode ser uma técnica útil para tarefas agendadas que têm de ser executadas como uma única instância.

Próximos passos