A magia de trabalhar com Azure WebJobs

A magia de trabalhar com Azure WebJobs

No atual cenário de desenvolvimento aplicações web, tenho notado muita gente fazendo alguns questionamentos, vou citar alguns: Como eu posso “aliviar” o pipeline de execução da minha aplicação web? Como eu posso ter um serviço em Background que ajude a minha plataforma web, a ter uma melhor performance? Como eu posso separar toda a minha execução em um “contexto” de execução diferente da minha aplicação web? Como eu posso escalar esses serviços, sem ter que escalar consequentemente minha aplicação web? Ufa.. são tantas perguntas. Então, para responder a todas essas perguntas, eu resumo minha resposta em um recurso bem interessante, porém não é tão novo assim dentro do azure, e o melhor – FREE do Azure: WebJobs.

O ambiente de nuvem da Microsoft, oferece uma variedade imensa de recursos que podem ajudar quando pensamos em processos que rodam em Background, o Azure disponibiliza outros recursos que podem ser utilizados para executar em background, tais como: Worker Role ou Azure Functions, mas no post de hoje quero mostrar algo simples e fácil de Gerenciar, Escalar, Atualizar e Monitorar, que são os WebJobs.

1. O QUE SÃO WEBJOBS?

São processos que são executados em background dentro de um ambiente de um WebApp no Azure. Os WebJobs podem ser desenvolvidos de duas formas: Scripts ou aplicações Console, e o deploy da aplicação também disponibiliza uma série de tipos diferentes de binários que podem ser executados no ambiente do Azure, como por exemplo:

  • .cmd, .bat
  • .exe (usando aplicações .NET que usam o SDK do WebJobs)
  • .sh (utilizando arquivo de bash)
  • .php (usando um simples arquivo PHP)
  • .py (usando Python)
  • .js (usando NodeJS)

Como você pode observar esse recurso te dá uma boa gama de opções para rodar como serviço em background por trabalhar com vários tipos de binários e que você pode gerar instalar dentro do seu ambiente. Eles tem ligação direta com o ambiente de uma WebApp, ou seja, ele vai sim ajudar a “aliviar” o pipeline de execução da sua aplicação web, mas vai concorrer com: Memória e CPU, diretamente com a sua aplicação web, conforme a imagem abaixo:

image

Essa é a parte que eu não considero tão vantajosa ao ponto de sugerir WebJobs como solução para TODOS os casos, onde uma aplicação web demanda um recurso de processamento desacoplado do pipeline da camada web. Porém, você pode contornar esse “probleminha”! Como? Não é algo do outro mundo e, também, dependendo do orçamento do seu projeto, porque pode ser uma solução que não se encaixe dentro do orçamento, mas vale como uma sugestão.

Quando você se deparar com uma situação que demande a criação de um webjobs e a premissa do seu projeto é que não pode haver nenhum tipo de concorrência entre o processo de execução do seu webjobs com sua aplicação web, a indicação que eu faço aqui é: Crie um WebApp para realizar a publicação dos seus webjobs, mas tenha cautela e bom senso nesse momento para não incorrer no erro de publicar serviços em background que não façam nenhum sentido dentro desse web app.

"Web Apps não é exclusivo apenas de Web Sites. Hoje, um Web Apps podem hospedar Web Sites e também WebJobs ou somente um WebSite ou somente WebJobs."

O que eles resolvem?

Resposta: WebJobs tem a intenção de resolver um problema, que é frequentemente encontrado em aplicações web: Processamento em Background. Com os WebJobs podemos trabablhar a separação das responsabilidades, ou seja, a camada web tem a responsabilidade de ter a iteração com o usuário final, onde este requisita dados do servidor e exibi os dados recebidos do servidor. Webjobs, também, trabalha com integração com a parte de Queues (Filas) do azure, além de integrar-se com Blob Storage e Azure Table Storage.

Os recurso de WebJobs possui dois tipos de Publicação:

  • Recorrente – Neste modelo de publicação, WebJobs são executados de tempos em tempos. Esse tempo varia de acordo com a parametrização que você configurou no momento de publica-lo.
  • Execução Continua – Neste tipo de publicação, WebJobs ficam em execução continua, ou seja, o Azure é quem garantirá esse funcionamento. PS.: Esse mecanimos só tem pleno funcionamento nos planos PAGOS, caso contrário, após 20min. de funcionamento, WebJobs são parados pelo Azure.

2. WEBJOBS SÃO FREE*

Sim, para utilizar webjobs no Azure é FREE. Mas porque eu coloquei um '' no FREE? Para que você possa utilizar webjobs, este precisa de um WebApp para que seja possível realizar a publicação desta aplicação. Mas existem alguns aspectos que quero deixar claro e, também, possa ajudá-los a tomar a decisão que atenda as necessidades do seu projeto.

Quando estamos criando nosso ambiente no Azure, temos a possibilidade de escolher o tipo de plano que a nossa WebApp utilizará para ser publicada e, assim, torne possível também a publicação de WebJobs. Para qualquer tipo de plano que você escolher: F1, D1, B1 até o P3, todos eles vão possibilitar que você publique WebJobs dentro de um WebApp. Maravilha, isso quer dizer que mesmo no plano FREE eu posso desfrutar de tudo que WebJobs pode me oferecer? A resposta para essa pergunta é: NÃO! Existem algumas diferenças que gostaria de esclarecer:

  1. Plano FREE (F1 e D1): Todo e qualquer WebJobs que seja publicado em um WebApp dentro desse plano funcionará 100%, porém após 20min. de funcionamento – Isso inclui o status de Processing, WebJobs são parado pelo ambiente do Azure. Sério? Sim! Esse ambiente FREE ele é todo compartilhado com todos que utilizam o azure ao redor do mundo, ou seja, neste tipo de plano você não disponibilizará da opção AlwaysOn que permite, ao ser ligada, que o ambiente do Azure mantenha e garanta que seus WebJobs não irão parar. Imagine que você colocasse um processamento absurdo para ser processado por um WebJob, neste ambiente compartilhado, você consumiria mais recursos de hardware, concorreria em prioridade com os demais que estão utilizando esse ambiente, deteriorando o ambiente de TODOS, além de que financeiramente isso não é interessante para a Microsoft Smile
  2. Demais planos PAGOS (B1 até P3): Neste tipo de plano, a opção AlwaysOn mencionada no item-1 encontra-se habilitada para ser ligada, garantindo com isso que o seu WebJob não pare de rodar após 20min. de funcionamento.

3. OS WEBJOBS FUNCIONAM MAGICAMENTE COM FILAS (QUEUES) NO AZURE

Filas? Sim, isso mesmo: Queues (Filas). Os WebJobs funcionam de uma maneira “mágica” com as filas do azure. O mecanimos dos WebJobs foi todo desenvolvido para trabalhar com um mecanismo que assemelha-se bastante com o pattern: Publish/Subscribe, ou seja, a cada mensagem que é enfileirada numa fila específica que o serviço do WebJob está esperando, esta mensagem é desenfileirada – é executado um procedimento chamado: Dequeue. Desta forma, o WebJob deserializa os dados fazendo com que estes entrem para o pipeline de execução. Apenas como informativo: Fazer esse tipo de implmentação utilizando o recurso de Worker Role, além de ser mais custoso por depender de uma VM específica para ele, teriamos que implementar o Desenfileiramento (Dequeuing) manual, mensagem por mensagem.

public void ExtrairHtmlDoUsuario(  
 [QueueTrigger(“usuarios”)] Usuario usuario,  
 [Queue(“conteudohtml”)] out string conteudoHtml,  
 CloudStorageAccount storageAccount,  
 string id,  
 string popReceipt,  
 TextWriter log)

O código acima é executado toda vez que uma mensagem é enfileirada na fila “usuarios”, o segundo parâmetro será a fila de OUTPUT que será utilizada para jogar o resultado do processamento dessa função do WebJob. Dessa forma, o WebJob entende que se a fila “conteudohtml” não existir, a fila precisa ser criada; esse procedimento da criação da fila, caso ela não exista, é feito automaticamente pelo SDK do WebJob. Sendo assim, após o processamento da mensagem da fila “usuarios”, essa mensagem que acabou de ser processada, será delatada da fila. Mas caso aconteça algum erro, o que pode acontecer com a minha mensagem? Eu a perco? Calma, você não vai perder sua mensagem, ao menos que você a delete sem querer, até nisso o SDK e o Azure pensaram para você Smile.

4. ELES SÃO RESILIENTES A ERROS

Os WebJobs realmente são resilientes a erros. Imagine a situação em que acabou de chegar uma mensagem na fila “usuarios” – vamos utilizar o exemplo do código da Seção 3 para facilitar nossa explicação e ilustração – e no meio do processamento aconteceu alguma exceção que causou a não conclusão do processamento dessa mensagem… E agora José? O que vou fazer com a minha mensagem perdida?

Espera um pouco, ninguém falou que sua mensagem foi perdida. O que vai acontecer nesse momento é o re-enfileiramento desta mesma mensagem, dentro da mesma fila, porém será acrescentado o valor da propriedade DCount dessa mensagem, informando para o sistema de Queue (Fila) do Azure e para o SDK do WebJob, que esta mensagem teve X tentativas de Dequeuing mas não teve sucesso no seu processamento, Porque X tentativas? O mecanismo de Queue no Azure foi implementado para que, dentro de um limite padrão de 5 Dequeuing sem sucesso, esta mensagem precisa ser retirada da fila imediatamente para uma outra fila – Essa quantidade de vezes do Dequeuing é customizável pelo SDK do WebJob. Neste momento, uma nova fila será criada com um sufixo: –poison. Agora, começou a melhorar hein Smile.

O mecanismo de Queue do Azure tem um mecanismo de filas de POISON, mecanismo normal de qualquer mecanismo de fila. Com esse mecanismo sendo executado automaticamente, toda e qualquer mensagem que exceda o contado de vezes de Dequeuing, serão automaticamente retiradas da fila principal, uma nova fila é criada com o mesmo nome da fila principal mais o sufixo –poison, conforme ilustrado na imagem abaixo:

image

5. É POSSÍVEL TRABALHAR COM INJEÇÃO DE DEPENDÊNCIA COM WEBJOBS

Trabalhar com WebJobs é algo que realmente traz bastante facilidades, e uma delas é permitir que essas implementações possam ser testáveis, trabalhando em conjunto com injeção de Dependência. Neste post não vou me ater aos detalhes de implementação sobre como configurar um container de injeção de dependência para um WebJob, mas quero apresentar por onde você pode realizar essa implementação.

Através da interface da propriedade JobActivator, você pode configurar o seu próprio mecanismo de injeção de dependência usando o Container que você ficar mais confortável para implementar. A imagem abaixo mostra a estrutura da classe JobHostConfiguration, responsável por toda a configuração, via código, para que seu WebJob tenha pleno funcionamento.

image

6. WEBJOBS DESERIALIZA A SUA MENSAGEM SEM NENHUM TRABALHO ADICIONAL

De fato WebJobs tem muita coisa bacana e interessante para explorarmos e uma delas – Que para mim é fantástica – é trabalhar com deserialização automática. Sim, isso é possível com WebJobs e seu SDK surpreendente. Conforme mostrado na Seção 3 deste post, você observou um trecho de código, que representa a assinatura de um método de um WebJob. O código em questão, tem uma peculiaridade que se você não se atentou para se questionar no momento, vou apresentar agora!

O código da Seção 3, apresenta na assinatura do método um tipo POCO. Mas espera lá! Uma mensagem dentro de uma fila, pelo que eu já entendi é uma String, certo? CERTO! Mas concorda comigo que um JSON também é uma String? Open-mouthed smile Então, com base em uma string no formato JSON, o SDK tenta deserializar essa string no tipo informado no parâmetro QueueTrigger, no caso do código de exemplo é uma classe do tipo “Usuario”. Sendo assim, toda vez que um usuário for enfileirado na fila “usuarios”, uma mensagem em formato JSON seria utilizada para registrar essa mensagem dentro desta fila especifica, com isso favorecendo e possibilitando acontecer a “mágica” da deserialização. Sensacional, não acha?! Smile

7. SÃO GERENCIAVEIS ATRAVÉS DO PORTAL DA FERRAMENTA KUDU

Como você pode observar através das imagens abaixo, trabalhar com WebJobs se torna algo muito mais gerenciável, fácil de monitorar e fácil de escalar. Dado que o funcionamento dos WebJobs se dá através de um WebApp, então toda a escala que um WebApp demandar, essa escala também será dada aos WebJobs.

image

As imagens abaixo, são diretamente do portal da ferramenta de publicação, utilizada pelo Azure, chamada: KUDU. Para chegar nesse portal, você pode clicar no botão Logs. Esse botão, é facilmente localizado na imagem acima.

image

Nesta imagem, você é capaz de acompanhar todas as execuções do seu WebJob:

image

image

8. WEBJOBS SÃO EXECUTADOS USANDO PARALELISMO

Esse é um outro recursos que eu realmente gosto bastante do WebJobs, que é a capacidade de executar o mesmo método utilizando paralelismo, ou seja, a cada mensagem que cair na fila que o WebJob estiver ouvindo, este método será executado paralelamente a outra execução do mesmo método. Isso é incrível, pois esse mecanismo todo é controlado pelo próprio SDK em conjunto com o poder de processamento do Azure. Mas vamos com calma pois nem tudo são Flores.

As filas no Azure são excelentes e atende muito bem esse cenário de processamento em Background, Messaging, mas existem algumas limitações e uma delas é a quantidade de mensagens que podem ser retiradas de uma fila específica em uma só leitura. Para o ambiente dos WebJobs, esse número foi padronizado em 16 mensagens, o que quer dizer que tendo uma quantidade de 20 mensagens numa fila, apenas as 16 primeiras serão lidas em uma única leitura e serão inicializadas 16 tasks (tarefas) que chamarão, em seus próprios contextos, o método do WebJob que depende das mensagens dessa fila. Mas e as outras? As outras mensagens, serão lidas a medida que as mensagens que já foram retiradas da fila, forem sendo processadas. Esse limite de 16 mensagens também é configurável, mas tenham muita calma nessa hora, porque o limite do Azure Queue é que possa ocorrer a leitura de , no máximo, 32 mensagens.

Multiple simultaneous functions running

A imagem acima, mostra exatamente o comportamento da execução utilizando paralelismo. Onde várias mensagens foram colocadas na fila e o WebJob retirou-as e executou simultaneamente estas mensagens.

Conclusão

Trabalhar com WebJobs realmente é algo incrível e que trás muitos beneficios quando o assunto é Background Services, além de oferecer uma boa variedade de opções de configuração, gerenciamento e controle sobre o que está acontecendo com o serviço; Eu o encorajo a utilizar esse recurso fantástico que é disponibilizado pela plataforma do Azure. Além de trabalhar muito bem com Queues (Filas), os WebJobs também oferecem possibilidades de se trabalhar com Blobs e Azure Table Storage, além de poder serem orquestrados por mecanismos de Schedule (Agendamento) no Azure.

Hoje quando eu penso em serviços em Background no Azure, penso primeiramente em WebJobs para qualquer tipo de processamento, desde que esses webjobs não concorram com o mesmo ambiente que a minha aplicação web Smile. WebJobs te oferece rápido desenvolvimento, publicação e execução, e também todo o conforto de se trabalhar com paralelismo (lembre-se das limitações das Queues do Azure, que podem processar no máximo 32 mensagens simultaneamente), WebJobs são fáceis de escalar e seu monitoramente se torna muito mais fácil através do painel de gestão que você pode acessar através da ferramenta KUDU. E outro ponto que favorece os WebJobs é que eles são FREE*.

Espero que tenham gostado desse Overview sobre WebJobs, como disse anteriormente, eu encorajo muito o uso desse mecanismo de processamento em Background no azure devido a tudo que foi apresentado neste artigo e muito mais que há de interessante nesta implementação.

Fique antenado no blog porque sairão artigos bem interessantes sobre WebJobs, Azure Storage e muito mais sobre desenvolvimento de software.

Deixe seu comentário, vamos construir o conhecimento de forma saudável e até o nosso próximo artigo Smile

Comments