Compartilhar via

Recomendações para o desenvolvimento de trabalhos de fundo

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Confiabilidade do Azure Well-Architected Framework:

RE:07 Fortaleça a resiliência e a capacidade de recuperação de sua carga de trabalho implementando medidas de autopreservação e autorrecuperação. Incorpore recursos à solução usando padrões de confiabilidade baseados em infraestrutura e padrões de projeto baseados em software para lidar com falhas de componentes e erros transitórios. Incorpore recursos ao sistema para detectar falhas de componentes da solução e iniciar automaticamente ações corretivas enquanto a carga de trabalho continua a operar com funcionalidade total ou reduzida.

Guias relacionados: Falhas transitórias | Autopreservação

Este guia descreve as recomendações para o desenvolvimento de trabalhos em segundo plano. Trabalhos em segundo plano são executados automaticamente sem a necessidade de interação do usuário. Muitos aplicativos exigem trabalhos em segundo plano que são executados independentemente da interface do usuário.

Alguns exemplos de trabalhos em segundo plano incluem trabalhos em lote, tarefas de processamento intensivo e processos de longa execução, como fluxos de trabalho. O aplicativo inicia o trabalho e processa solicitações interativas dos usuários. Por exemplo, se um aplicativo precisar gerar miniaturas de imagens carregadas pelos usuários, um trabalho em segundo plano poderá ser executado para gerar a miniatura e salvá-la no armazenamento. O usuário não precisa aguardar a conclusão do processo. Como outro exemplo, um cliente faz um pedido, que inicia um fluxo de trabalho em segundo plano que processa o pedido. O cliente continua a navegar no aplicativo Web enquanto o trabalho em segundo plano é executado. Após a conclusão do trabalho em segundo plano, ele atualiza os dados armazenados do pedido e envia um e-mail ao cliente para confirmar o pedido.

Trabalhos em segundo plano ajudam a minimizar a carga na interface do usuário do aplicativo, o que melhora a disponibilidade e reduz o tempo de resposta interativo.

Principais estratégias de design

Para escolher qual tarefa designar como um trabalho em segundo plano, considere se a tarefa é executada sem interação do usuário e se a interface do usuário precisa aguardar a conclusão da tarefa. As tarefas que exigem que o usuário ou a interface do usuário aguarde enquanto são executadas normalmente não são trabalhos em segundo plano apropriados.

Tipos de trabalhos em segundo plano

Alguns exemplos de trabalhos em segundo plano são:

  • Trabalhos com uso intensivo de CPU, como cálculos matemáticos ou análises de modelo estrutural.

  • Trabalhos de E/S com uso intensivo de E/S, como a execução de uma série de transações de armazenamento ou indexação de arquivos.

  • Trabalhos em lote, como atualizações de dados que são feitas todas as noites ou processamentos agendados.

  • Fluxos de trabalho de longa execução, como atendimento de pedidos ou provisionamento de serviços e sistemas.

  • Processamento de dados confidenciais que transfere a tarefa para um local mais seguro para processamento. Por exemplo, não convém processar dados confidenciais em um aplicativo 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 a armazenamento protegido.

Gatilhos

Inicie trabalhos em segundo plano com:

  • Gatilhos orientados a eventos: um evento, normalmente uma ação do usuário ou uma etapa em um fluxo de trabalho, dispara a tarefa.

  • Gatilhos controlados por agenda: uma agenda baseada em um temporizador invoca a tarefa. O trabalho pode ser agendado de forma recorrente ou para uma única execução.

Gatilhos acionados por eventos

Uma ação dispara uma invocação orientada a eventos que inicia a tarefa em segundo plano. Exemplos de gatilhos orientados a eventos incluem:

  • A interface do usuário ou um trabalho diferente coloca uma mensagem em uma fila, conforme descrito no estilo de arquitetura Web-Queue-Worker. A mensagem contém dados sobre uma ação executada anteriormente, como um cliente que fez um pedido. O trabalho em segundo plano monitora essa fila e detecta a chegada de uma nova mensagem. Ele lê a mensagem e usa os dados da mensagem como entrada para o trabalho em segundo plano. Esse padrão é chamado de comunicação assíncrona baseada em mensagem.

  • A interface do usuário ou um trabalho diferente salva ou atualiza um valor que está no armazenamento. O trabalho em segundo plano monitora o armazenamento e detecta alterações. Ele lê os dados e os usa como entrada para o trabalho em segundo plano.

  • A interface do usuário ou um trabalho diferente faz uma solicitação para um ponto de extremidade, como um URI HTTPS ou uma API exposta como um serviço Web. Como parte da solicitação, a interface do usuário ou o trabalho transfere os dados exigidos pela tarefa em segundo plano. O ponto de extremidade ou serviço Web invoca a tarefa em segundo plano, que usa os dados como entrada.

Outros exemplos de tarefas adequadas à invocação orientada a eventos incluem processamento de imagens, fluxos de trabalho, envio de informações para serviços remotos, envio de mensagens de email e provisionamento de novos usuários em aplicativos multilocatário.

Gatilhos acionados por agendamentos

Um temporizador dispara uma invocação orientada por agendamento que inicia a tarefa em segundo plano. Exemplos de gatilhos orientados por agendamento incluem:

  • Um temporizador executado localmente no aplicativo ou como parte do sistema operacional do aplicativo invoca regularmente uma tarefa em segundo plano.

  • Um temporizador executado em um aplicativo diferente, como os Aplicativos Lógicos do Azure, envia regularmente uma solicitação para uma API ou serviço Web. O serviço Web ou API chama a tarefa em segundo plano.

  • Um processo ou aplicativo separado inicia um temporizador que invoca a tarefa em segundo plano após um atraso de tempo ou em um horário específico.

Outros exemplos de tarefas que são adequadas para a invocação orientada por agendamento incluem rotinas de processamento em lote (como atualizar listas de produtos relacionados para clientes com base em seu comportamento recente), tarefas rotineiras de processamento de dados (como 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 de dados.

Se você usar uma tarefa controlada por agendamento que deve ser executada como uma única instância, revise as seguintes considerações:

  • Se a instância de computação que executa o agendador, como uma máquina virtual (VM) que usa tarefas agendadas do Windows, for dimensionada, você estará executando várias instâncias do agendador. Várias instâncias do agendador podem iniciar várias instâncias da tarefa. Para obter mais informações, consulte O que significa idempotente em sistemas de software?

  • Se as tarefas forem executadas por mais tempo do que o período entre os eventos do agendador, o agendador poderá iniciar outra instância da tarefa enquanto a tarefa anterior é executada.

Retornar resultados

Os trabalhos em segundo plano são executados de forma assíncrona em um processo separado, ou mesmo em um local separado, da interface do usuário ou do processo que invocou o trabalho em segundo plano. O ideal é que os trabalhos em segundo plano sejam operações de incêndio e esquecimento . Seu progresso de tempo de execução não tem um efeito na interface do usuário ou no processo de chamada, o que significa que o processo de chamada não aguarda a conclusão das tarefas. A interface do usuário e o processo de chamada não podem detectar quando a tarefa termina.

Se você precisar de uma tarefa em segundo plano para se comunicar com a tarefa de chamada para indicar o progresso ou a conclusão, deverá implementar um mecanismo. Alguns exemplos são:

  • Escreva um valor de indicador de status no armazenamento acessível à interface do usuário ou à tarefa do chamador, que pode monitorar ou verificar esse valor. Outros dados que a tarefa em segundo plano retorna ao chamador podem ser colocados no mesmo armazenamento.

  • Estabeleça uma fila de resposta que a interface do usuário ou o chamador monitora. A tarefa em segundo plano pode enviar mensagens para a fila que indicam o status. Os dados que a tarefa em segundo plano retorna ao chamador podem ser colocados nas mensagens. Para o Barramento de Serviço do Azure, use as ReplyTo propriedades e CorrelationId para implementar esse recurso.

  • Expor uma API ou um ponto de extremidade da tarefa em segundo plano que a interface do usuário ou o chamador pode acessar para obter informações de status. A resposta pode incluir os dados que a tarefa em segundo plano retorna ao chamador.

  • Configure a tarefa em segundo plano para chamar de volta à interface do usuário ou ao chamador por meio de uma API para indicar o status em pontos predefinidos ou na conclusão. Você pode usar eventos gerados localmente ou um mecanismo de publicação e assinatura. A solicitação ou a carga do evento pode incluir os dados que a tarefa em segundo plano retorna ao chamador.

Trabalhos em segundo plano de partição

Se você incluir trabalhos em segundo plano em uma instância de computação existente, considere como essas alterações afetam os atributos de qualidade da instância de computação e do trabalho em segundo plano. Considere esses fatores para decidir se deseja colocalizar as tarefas com a instância de computação existente ou separá-las em uma instância de computação diferente:

  • Disponibilidade: as tarefas em segundo plano podem não precisar do mesmo nível de disponibilidade que outras partes do aplicativo, em particular a interface do usuário e as partes que envolvem diretamente a interação do usuário. As tarefas em segundo plano podem ter uma tolerância maior para latência, falhas de conexão repetidas e outros fatores que afetam a disponibilidade porque as operações podem ser enfileiradas. No entanto, deve haver capacidade suficiente para impedir o backup de solicitações que podem bloquear filas e afetar todo o aplicativo.

  • Escalabilidade: as tarefas em segundo plano provavelmente têm requisitos de escalabilidade diferentes em comparação com a interface do usuário e as partes interativas do aplicativo. Talvez seja necessário dimensionar a interface do usuário para atender aos picos de demanda. Tarefas pendentes em segundo plano podem ser executadas durante períodos menos ocupados e com menos instâncias de computação.

  • Resiliência: se uma instância de computação que hospeda apenas tarefas em segundo plano falhar, ela pode não afetar fatalmente todo o aplicativo. As solicitações para essas tarefas podem ser enfileiradas ou adiadas até que a tarefa esteja disponível. Se a instância de computação ou as tarefas puderem ser reiniciadas em um intervalo apropriado, isso pode não afetar os usuários do aplicativo.

  • Segurança: as tarefas em segundo plano podem ter requisitos ou restrições de segurança diferentes em comparação com a interface do usuário ou outras partes do aplicativo. Use uma instância de computação separada para especificar um ambiente de segurança diferente para as tarefas. Para maximizar a segurança e a separação, você também pode usar padrões como o Gatekeeper para isolar as instâncias de computação em segundo plano da interface do usuário.

  • Desempenho: escolha o tipo de instância de computação para tarefas em segundo plano que corresponda especificamente aos requisitos de desempenho da tarefa. Você pode usar uma opção de computação mais barata se as tarefas não exigirem os mesmos recursos de processamento que a interface do usuário. Ou você pode usar uma instância maior se as tarefas exigirem mais capacidade e recursos.

  • Capacidade de gerenciamento: as tarefas em segundo plano podem ter um ritmo de desenvolvimento e implantação diferente em comparação com o código do aplicativo principal ou a interface do usuário. Para simplificar as atualizações e o controle de versão, implante tarefas em segundo plano em uma instância de computação separada.

  • Custo: se você adicionar instâncias de computação para executar tarefas em segundo plano, os custos de hospedagem aumentarão. Considere cuidadosamente a compensação entre mais capacidade e custos extras.

Para obter mais informações, consulte Padrão de eleição de líder e Padrão de consumidores concorrentes.

Conflitos

Se você tiver várias instâncias de um trabalho em segundo plano, elas poderão competir por acesso a recursos e serviços, como bancos de dados e armazenamento. Esse acesso simultâneo pode resultar em contenção de recursos, o que pode causar conflitos de disponibilidade de serviço e prejudicar a integridade dos dados armazenados em armazenamento. Resolva a contenção de recursos usando uma abordagem de bloqueio pessimista. Essa abordagem impede que instâncias concorrentes de uma tarefa acessem simultaneamente um serviço ou corrompam dados.

Outra abordagem para resolver conflitos é definir tarefas em segundo plano como um singleton, para que apenas uma instância seja executada. No entanto, essa abordagem elimina os benefícios de confiabilidade e desempenho que uma configuração de várias instâncias oferece. Essa desvantagem é especialmente verdadeira se a interface do usuário fornecer trabalho suficiente para manter mais de uma tarefa em segundo plano ocupada.

Verifique se a tarefa em segundo plano pode ser reiniciada automaticamente e se ela tem capacidade suficiente para lidar com picos de demanda. Aloque uma instância de computação com recursos suficientes, implemente um mecanismo de enfileiramento que armazene solicitações a serem executadas quando a demanda diminui ou use uma combinação dessas técnicas.

Coordenação

Tarefas em segundo plano podem ser complexas e exigir várias tarefas a serem executadas. Nesses cenários, é comum dividir a tarefa em etapas ou subtarefas menores e discretas que vários consumidores podem executar. Os trabalhos de várias etapas são mais eficientes e mais flexíveis porque as etapas individuais geralmente são reutilizáveis em vários trabalhos. Também é fácil adicionar, remover ou modificar a ordem das etapas.

Pode ser um desafio coordenar várias tarefas e etapas, mas há três padrões comuns para orientar sua solução:

  • Decomponha uma tarefa em várias etapas reutilizáveis. Um aplicativo pode ser necessário para executar várias tarefas de complexidade diferente nas informações que ele processa. Uma abordagem simples, mas inflexível, para implementar tal aplicativo é executar esse processamento como um módulo monolítico. Mas essa abordagem provavelmente reduzirá as oportunidades de refatoração do código, otimizando-o ou reutilizando-o se o aplicativo exigir partes do mesmo processamento em outro lugar. Para saber mais, confira Padrão de tubos e filtros.

  • Gerenciar a orquestração das etapas de uma tarefa. Um aplicativo pode executar tarefas que compreendem muitas etapas, algumas das quais podem invocar serviços remotos ou acessar recursos remotos. Às vezes, as etapas individuais são independentes umas das outras, mas são orquestradas pela lógica do aplicativo que implementa a tarefa. Para saber mais, confira Padrão do Supervisor do Agente do Agendador.

  • Gerencie a recuperação das etapas da tarefa que falharem. Se uma ou mais das etapas falharem, um aplicativo pode precisar desfazer o trabalho que uma série de etapas executa, o que, em conjunto, define uma operação eventualmente consistente. Para obter mais informações, consulte Compensando o padrão de transação.

Considerações de resiliência

Crie tarefas em segundo plano resilientes para fornecer serviços confiáveis para o aplicativo. Ao planejar e projetar tarefas em segundo plano, considere os seguintes pontos:

  • As tarefas em segundo plano precisam lidar com reinicializações normalmente, sem corromper dados ou introduzir inconsistência no aplicativo. Para tarefas de longa duração ou de várias etapas, considere o uso de pontos de verificação. Use pontos de verificação para salvar o estado dos trabalhos no armazenamento persistente ou como mensagens em uma fila. Por exemplo, você pode armazenar informações de estado em uma mensagem que está em uma fila e atualizar incrementalmente essas informações de estado com o progresso da tarefa. A tarefa pode ser processada a partir do último ponto de verificação conhecido em vez de reiniciar a partir do início.

    Para filas do Barramento de Serviço, use sessões de mensagem para essa finalidade. Com sessões de mensagem, salve e recupere o estado de processamento do aplicativo usando os métodos SetState e GetState . Para obter mais informações sobre como criar processos e fluxos de trabalho confiáveis em várias etapas, consulte Padrão do Supervisor do Agente do Agendador.

  • Ao usar filas para se comunicar com as tarefas em segundo plano, as filas podem agir como um buffer para armazenar solicitações enviadas para as tarefas, enquanto o aplicativo estiver com carga maior que o normal. As tarefas podem alcançar a interface do usuário durante períodos menos ocupados e as reinicializações não bloqueiam a interface do usuário. Para obter mais informações, consulte Padrão de Nivelamento de carga baseado em fila. Se algumas tarefas forem mais importantes do que outras, considere implementar o padrão Fila de Prioridade para garantir que essas tarefas sejam executadas primeiro.

Mensagens

Configure tarefas em segundo plano iniciadas por mensagens ou que processam mensagens para lidar com inconsistências, como mensagens que chegam fora de ordem, mensagens que causam um erro repetidamente (mensagens suspeitas) e mensagens que são entregues mais de uma vez. Considere as seguintes recomendações:

  • Às vezes, você precisa que as mensagens sejam processadas em uma ordem específica, como mensagens que alteram dados com base no valor de dados existente, por exemplo, adicionando um valor a um valor existente. Nem sempre as mensagens chegam na ordem em que foram enviadas. Além disso, instâncias diferentes de uma tarefa em segundo plano podem processar mensagens em uma ordem diferente devido a cargas variáveis em cada instância.

    Para mensagens que devem ser processadas em uma ordem específica, inclua um número de sequência, chave ou outro indicador que as tarefas em segundo plano possam usar para processar mensagens na ordem correta. Para o Service Bus, use sessões de mensagens para garantir a ordem correta de entrega. É mais eficiente projetar o processo para que a ordem das mensagens não seja importante. Para obter mais informações, consulte Sequenciamento de mensagens e carimbos de data/hora.

  • Normalmente, uma tarefa em segundo plano espia as mensagens na fila, o que as oculta temporariamente de outros consumidores de mensagens. Depois que a tarefa processa a mensagem com êxito, ela a exclui. Se uma tarefa em segundo plano falhar ao processar uma mensagem, essa mensagem reaparecerá na fila depois que o tempo limite de visualização expirar. Uma instância diferente da tarefa processa a mensagem ou o próximo ciclo de processamento da instância original processa a mensagem.

    Se a mensagem consistentemente causar um erro no consumidor, ela bloqueará a tarefa, a fila e, eventualmente, o próprio aplicativo quando a fila ficar cheia. É vital detectar e remover mensagens suspeitas da fila. Se você usar o Service Bus, mova automaticamente ou manualmente mensagens suspeitas para uma fila de mensagens mortas associada.

  • As filas são mecanismos de entrega pelo menos uma vez , mas podem entregar a mesma mensagem mais de uma vez. Se uma tarefa em segundo plano falhar depois de processar uma mensagem, mas antes de excluí-la da fila, a mensagem estará disponível para processamento novamente.

    As tarefas em segundo plano devem ser idempotentes, o que significa que, quando a tarefa processa a mesma mensagem mais de uma vez, ela não causa um erro ou inconsistência nos dados do aplicativo. Algumas operações são naturalmente idempotentes, por exemplo, se um valor armazenado é definido como um novo valor específico. No entanto, algumas operações causam inconsistências, por exemplo, se um valor é adicionado a um valor armazenado existente sem verificar se o valor armazenado ainda é o mesmo de quando a mensagem foi enviada originalmente. Configure as filas do Barramento de Serviço para remover automaticamente mensagens duplicadas. Para obter mais informações, consulte Processamento de mensagens Idempotent.

  • Alguns sistemas de mensagens, como filas de Armazenamento do Azure e filas do Barramento de Serviço, oferecem suporte a uma propriedade de contagem de filas que indica quantas vezes uma mensagem da fila é lida. Esses dados são úteis para lidar com mensagens repetidas e mensagens suspeitas. Para obter mais informações, consulte Primer de mensagens assíncronas e Padrões de idempotência.

Considerações sobre dimensionamento e desempenho

As tarefas em segundo plano devem oferecer desempenho suficiente para garantir que elas não bloqueiem o aplicativo ou atrasem a operação quando o sistema estiver suportando uma carga. Normalmente, o desempenho melhora quando você dimensiona as instâncias de computação que hospedam as tarefas em segundo plano. Ao planejar e projetar tarefas em segundo plano, considere os seguintes pontos relacionados à escalabilidade e ao desempenho:

  • As Máquinas Virtuais do Azure e o recurso Aplicativos Web do Serviço de Aplicativo do Azure podem hospedar implantações. Eles oferecem suporte ao dimensionamento automático, tanto de dimensionamento quanto de dimensionamento. O dimensionamento automático é determinado pela demanda e carga ou por um cronograma predefinido. Use o dimensionamento automático para ajudar a garantir que o aplicativo tenha recursos de desempenho suficientes e, ao mesmo tempo, minimize os custos de tempo de execução.

  • Algumas tarefas em segundo plano têm um recurso de desempenho diferente em comparação com outras partes de um aplicativo, por exemplo, a interface do usuário ou componentes, como a camada de acesso a dados. Nesse cenário, hospede as tarefas em segundo plano juntas em um serviço de computação separado para que a interface do usuário e as tarefas em segundo plano possam ser dimensionadas independentemente para gerenciar a carga. Se várias tarefas em segundo plano tiverem recursos de desempenho significativamente diferentes, divida-as e dimensione cada tipo independentemente. Essa técnica pode aumentar os custos de tempo de execução.

  • Para evitar a perda de desempenho sob carga, talvez você também precise dimensionar filas de armazenamento e outros recursos para que um único ponto da cadeia de processamento não cause um afunilamento. Considere outras limitações, como a taxa de transferência máxima de armazenamento e outros serviços nos quais o aplicativo e as tarefas em segundo plano dependem.

  • Projetar tarefas em segundo plano para dimensionamento. Por exemplo, as tarefas em segundo plano devem detectar dinamicamente o número de filas de armazenamento utilizadas para monitorar mensagens ou enviar mensagens para a fila apropriada.

  • Por padrão, um WebJob é dimensionado com sua instância de Aplicativos Web associada. No entanto, se desejar que um WebJob seja executado como apenas uma única instância, você poderá criar um arquivo Settings.job que contenha os dados { "is_singleton": true }JSON. Esse método força o Azure a executar apenas uma instância do WebJob, mesmo que haja várias instâncias do aplicativo Web associado. Essa técnica é útil para trabalhos agendados que devem ser executados como apenas uma única instância.

  • Os trabalhos em segundo plano podem criar desafios para a sincronização de dados e a coordenação de processos, especialmente se as tarefas em segundo plano dependerem umas das outras ou de outras fontes de dados. Por exemplo, trabalhos em segundo plano podem lidar com problemas de consistência de dados, condições de corrida, deadlocks ou tempos limites.

  • Os trabalhos em segundo plano podem afetar a experiência do usuário se os resultados das tarefas em segundo plano forem apresentados ao usuário. Por exemplo, trabalhos em segundo plano podem exigir que o usuário aguarde uma notificação, atualize a página ou verifique manualmente o status da tarefa. Esses comportamentos podem aumentar a complexidade da interação do usuário e afetar negativamente a experiência do usuário.

Compensação: os trabalhos em segundo plano introduzem mais componentes e dependências no sistema, o que pode aumentar a complexidade e os custos de manutenção da solução. Por exemplo, trabalhos em segundo plano podem exigir um serviço de fila separado, serviço de trabalho, serviço de monitoramento e mecanismo de repetição.

Azure facilitation

As seções a seguir descrevem os serviços do Azure que você pode usar para hospedar, executar, configurar e gerenciar trabalhos em segundo plano.

Ambientes de host

Há vários serviços da plataforma Azure que podem hospedar tarefas em segundo plano:

  • Aplicativos Web e WebJobs: use o recurso WebJobs do Serviço de Aplicativo para executar trabalhos personalizados baseados em scripts ou programas diferentes que você pode executar em um aplicativo Web.

  • Azure Functions: use aplicativos de função para trabalhos em segundo plano que não são executados por muito tempo. Você também pode usar aplicativos de função se hospedar sua carga de trabalho em um plano do Serviço de Aplicativo subutilizado.

  • Máquinas Virtuais: Se você tiver um serviço do Windows ou quiser usar o Agendador de Tarefas do Windows, hospede suas tarefas em segundo plano em uma VM dedicada.

  • Lote do Azure: o lote é um serviço de plataforma que você pode usar para agendar trabalho intensivo de computação para execução em uma coleção gerenciada de VMs. Ele pode dimensionar automaticamente os recursos de computação.

  • Serviço de Kubernetes do Azure (AKS): o AKS fornece um ambiente de hospedagem gerenciado para o Kubernetes no Azure.

  • Aplicativos de Contêiner do Azure: com os Aplicativos de Contêiner, você pode criar microsserviços sem servidor baseados em contêineres.

As seções a seguir fornecem considerações para cada uma dessas opções para ajudá-lo a escolher a melhor opção para você.

Aplicativos Web e WebJobs

Você pode usar o recurso WebJobs para executar trabalhos personalizados como trabalhos em segundo plano em um aplicativo Web. Um WebJob é executado como um processo contínuo no contexto do seu aplicativo Web. Um WebJob também pode ser executado em resposta a um evento de gatilho de Aplicativos Lógicos ou fatores externos, como alterações em blobs de armazenamento ou filas de mensagens. Os WebJobs podem ser iniciados e interrompidos sob demanda e encerrados normalmente. Se um WebJob em execução contínua falhar, ele será reiniciado automaticamente. Você pode configurar ações de repetição e erro.

Quando você configura um WebJob:

  • Se desejar que o trabalho responda a um gatilho controlado por eventos, configure-o para Executar continuamente. O script ou programa é armazenado na pasta chamada site/wwwroot/app_data/jobs/continuous.

  • Se você quiser que o trabalho responda a um gatilho controlado por agenda, configure-o para Executar em uma agenda. O script ou o programa é armazenado na pasta chamada site/wwwroot/app_data/jobs/triggered.

  • Se você escolher a opção Executar sob demanda ao configurar um trabalho, ele executará o mesmo código que a opção Executar em uma agenda quando você iniciar o trabalho.

Um WebJob é executado na área restrita do aplicativo Web. Ele tem acesso a variáveis de ambiente e pode compartilhar informações, como cadeias de conexão, com o aplicativo Web. O WebJob tem acesso ao identificador exclusivo da máquina que executa o WebJob. A cadeia de conexão nomeada AzureWebJobsStorage fornece acesso a filas de armazenamento, blobs e tabelas para dados de aplicativos. Ele também fornece acesso ao Service Bus para mensagens e comunicação. A cadeia de conexão nomeada AzureWebJobsDashboard fornece acesso aos arquivos de log de ação WebJob.

Os WebJobs têm as seguintes características:

  • Segurança: as credenciais de implantação do aplicativo Web fornecem proteção para WebJobs.

  • Tipos de arquivo suportados: Defina WebJobs usando scripts de comando (.cmd), arquivos em lote (.bat), scripts PowerShell (.ps1), scripts de shell Bash (.sh), scripts PHP (.php), scripts Python (.py), código JavaScript (.js) e programas executáveis (.exe e .jar).

  • Implantação: você pode implantar scripts e executáveis usando o portal do Azure, o Visual Studio ou o SDK do WebJobs, ou pode copiá-los diretamente para os seguintes locais:

    • Para implantação acionada: site/wwwroot/app_data/jobs/triggered/<job name>

    • Para implantação contínua: site/wwwroot/app_data/jobs/continuous/<job name>

  • Arquivos de log: Console.Out é tratado, ou marcado, como INFO. Console.Error é tratado como ERROR. Use o portal para acessar informações de monitoramento e diagnóstico. Baixe arquivos de log diretamente do site. Os arquivos de log são salvos nos seguintes locais:

    • Para implantação acionada: Vfs/data/jobs/triggered/<job name>

    • Para implantação contínua: Vfs/data/jobs/continuous/<job name>

  • Configuração: Configure WebJobs usando o portal, a API REST e o PowerShell. Use um arquivo de configuração chamado settings.job, que está no mesmo diretório raiz que o script WebJob, para fornecer informações de configuração para um WebJob. Por exemplo:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

Considerações sobre Aplicativos Web e WebJobs

  • Por padrão, os WebJobs são dimensionados com o aplicativo Web. Para configurar WebJobs para execução em uma única instância, defina a is_singleton propriedade configuration como true. WebJobs de instância única são úteis para tarefas que você não deseja dimensionar ou executar como várias instâncias simultâneas, como reindexação ou análise de dados.

  • Para minimizar o efeito dos WebJobs no desempenho do aplicativo Web, crie uma instância vazia do aplicativo Web em um novo plano do Serviço de Aplicativo para hospedar WebJobs de longa execução ou com uso intensivo de recursos.

Azure Functions

O Azure Functions é semelhante ao WebJobs. O Azure Functions não tem servidor e é mais adequado para gatilhos orientados a eventos que são executados por um curto período. Você também pode usar o Azure Functions para executar trabalhos agendados por meio de gatilhos de timer se configurar uma função para ser executada em horários especificados.

O Azure Functions não é recomendado para tarefas grandes e de longa execução porque uma função pode causar tempos limite inesperados. No entanto, dependendo do seu plano de hospedagem, considere o uso de funções para gatilhos orientados por agenda.

Considerações sobre o Azure Functions

Se você espera que a tarefa em segundo plano seja executada por uma curta duração em resposta a um evento, considere executar a tarefa no plano de consumo. Você pode configurar o tempo de execução para um tempo máximo. Uma função executada por mais tempo custa mais. Trabalhos com uso intensivo de 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 é adequado se você tiver várias tarefas que são curtas, mas que são executadas continuamente. Esse plano é mais caro porque precisa de mais memória e CPU. Como benefício, você pode usar outros recursos, como integração de rede virtual.

O plano dedicado é adequado para trabalhos em segundo plano se sua carga de trabalho já for executada no plano dedicado. Se você tiver VMs subutilizadas, poderá executar o plano dedicado na mesma VM e compartilhar os custos de computação.

Para saber mais, veja:

Máquinas Virtuais

Você pode implementar tarefas em segundo plano para que elas não sejam implantadas em Aplicativos Web. Por exemplo, você pode implementar tarefas usando serviços do Windows, utilitários de terceiros ou programas executáveis. Você também pode usar programas escritos para um ambiente de tempo de execução diferente do ambiente que hospeda o aplicativo. Por exemplo, você pode usar um programa Unix ou Linux que deseja executar a partir de um aplicativo Windows ou .NET. Escolha entre vários sistemas operacionais para uma VM do Azure e execute seu serviço ou executável nessa VM.

Para saber mais, veja:

Para iniciar a tarefa em segundo plano em uma VM separada, você pode:

  • Envie uma solicitação para um ponto de extremidade que a tarefa expõe para executar a tarefa sob demanda diretamente do seu aplicativo. A solicitação transfere dados que a tarefa requer. O ponto de extremidade invoca a tarefa.

  • Use um agendador ou temporizador do sistema operacional escolhido para configurar a tarefa para ser executada em uma agenda. Por exemplo, no Windows, você pode usar o Agendador de Tarefas do Windows para executar scripts e tarefas. Se você tiver o SQL Server instalado na VM, use o SQL Server Agent para executar scripts e tarefas.

  • Use Aplicativos Lógicos para iniciar a tarefa adicionando uma mensagem a uma fila que a tarefa monitora ou enviando uma solicitação para uma API que a tarefa expõe.

Para obter mais informações sobre como iniciar tarefas em segundo plano, consulte a seção Gatilhos anterior.

Considerações sobre máquinas virtuais

Considere os seguintes pontos ao implantar tarefas em segundo plano em uma VM do Azure:

  • Hospede tarefas em segundo plano em uma VM do Azure separada para fornecer flexibilidade e controle preciso sobre iniciação, implantação, agendamento e alocação de recursos. No entanto, os custos de tempo de execução aumentam se você implantar uma VM somente para tarefas em segundo plano.

  • Não há recurso para monitorar as tarefas no portal e nenhum recurso de reinicialização automatizada para tarefas com falha. Mas você pode usar os cmdlets do Gerenciador de Recursos do Azure para monitorar o status da VM e gerenciá-la. Não há recursos para controlar processos e threads em nós de computação. Normalmente, se você usar uma VM, precisará implementar um mecanismo que coleta dados da instrumentação na tarefa e também do sistema operacional na VM. Você pode usar o Pacote de Gerenciamento do System Center para Azure para essa finalidade.

  • Considere a criação de testes de monitoramento expostos por meio de pontos de extremidade HTTP. Você pode configurar o código para esses testes para executar verificações de integridade e coletar informações operacionais e estatísticas. Você também pode usar os testes para agrupar informações de erro e retorná-las a um aplicativo de gerenciamento.

Para saber mais, veja:

Batch

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

Use Lote para preparar as VMs, atribuir tarefas às VMs, executar as tarefas, monitorar o progresso e dimensionar automaticamente as VMs em resposta à carga de trabalho. O Batch também fornece agendamento de trabalho e oferece suporte a VMs Linux e Windows.

Considerações sobre lotes

O lote é adequado para cargas de trabalho intrinsecamente paralelas. Você pode usar o Lote para executar cálculos paralelos com uma etapa de redução no final ou executar aplicativos MPI (Message Passing Interface) para tarefas paralelas que exigem a passagem de mensagens entre nós.

Um trabalho em lote é executado em um pool de nós ou VMs. Você pode alocar um pool somente quando necessário e, em seguida, excluí-lo após a conclusão do trabalho. Essa abordagem maximiza a utilização porque os nós não estão ociosos, mas o trabalho deve aguardar a alocação de nós. Como alternativa, você pode criar uma piscina com antecedência. Essa abordagem minimiza o tempo que leva para um trabalho ser iniciado, mas pode resultar em nós que ficam ociosos.

Para saber mais, veja:

Serviço de Kubernetes do Azure

Use o AKS para gerenciar seu ambiente Kubernetes hospedado para que você possa implantar e gerenciar facilmente aplicativos em contêineres.

Os contêineres são úteis para executar trabalhos em segundo plano. Alguns dos benefícios são:

  • Os contêineres dão suporte à hospedagem de alta densidade. Você pode isolar uma tarefa em segundo plano em um contêiner ao colocar vários contêineres em cada VM.

  • Use o orquestrador de contêiner para executar o balanceamento de carga interno, configurar a rede interna e executar outras tarefas de configuração.

  • Você pode iniciar e parar contêineres conforme necessário.

  • Com o Registro de Contêiner do Azure, você pode registrar seus contêineres dentro dos limites do Azure para fornecer benefícios de segurança, privacidade e proximidade.

Considerações do AKS

AKS requer uma compreensão de como usar um orquestrador de contêineres.

Para saber mais, veja:

Aplicativos de Contêiner

Com os Aplicativos de Contêiner, você pode criar microsserviços sem servidor baseados em contêineres. Aplicativos de contêiner:

  • É otimizado para executar contêineres de uso geral, especialmente aplicativos que abrangem muitos microsserviços implantados em contêineres.

  • É alimentado pelo Kubernetes e tecnologias de código aberto, como Dapr, Kubernetes Event-driven Autoscaling (KEDA) e Envoy.

  • Suporte a aplicativos no estilo Kubernetes e microsserviços com recursos como descoberta de serviço e divisão de tráfego.

  • Permite arquiteturas de aplicativos orientadas a eventos, oferecendo suporte ao dimensionamento baseado no tráfego e à extração de fontes de eventos, como filas, incluindo a escala para zero.

  • Suporta processos de longa execução e pode executar tarefas em segundo plano.

Considerações sobre aplicativos de contêiner

Os Aplicativos de Contêiner não fornecem acesso direto às APIs subjacentes do Kubernetes. Se você precisar de acesso às APIs do Kubernetes e ao plano de controle, use o AKS. Se você quiser criar aplicativos no estilo Kubernetes e não precisar de acesso direto às APIs nativas do Kubernetes e ao gerenciamento de cluster, use Aplicativos de Contêiner para uma experiência totalmente gerenciada. O Container Apps é mais adequado para a criação de microsserviços de contêiner.

Para saber mais, veja:

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade