Se você é um profissional antenado, com certeza deve ter visto/ouvido algo sobre o anúncio, de certa forma inesperado, feito há alguns meses (mais precisamente, de Agosto de 2017), de um novo serviço para o Microsoft Azure – o Event Grid. Se você não viu, segue o post do anúncio oficial.
O que é o Event Grid?
A maioria das aplicações modernas são baseadas em eventos. Isso é um fato. É difícil imaginar uma aplicação hoje em dia que não precise, de maneira reativa ou proativa, disparar ações especializadas com base em algum comportamento ou evento ocorrendo em seu contexto. Imagine, por exemplo, uma aplicação de processamento de vídeos online (como o Youtube). Podemos imaginar o seguinte fluxo de operação para ela:
- Usuário faz o upload do vídeo.
- O serviço de upload recebe a requisição, aguarda o envio do stream de dados ser concluído (upload), monta então o arquivo de vídeo na memória do servidor e o envia para uma estrutura de armazenamento permanente (ou temporário).
- Após isso, o serviço de upload notifica o sistema de que existe um novo vídeo para ser processado. Esta notificação pode ser realizada de diferentes maneiras, entretanto, uma das mais utilizadas, é o enfileiramento em alguma estrutura especializada.
- Outro serviço (de processamento de vídeos) está atento às mensagens da fila. E ele precisa estar, uma vez que é este o gatilho que fará com que ele acorde e vá fazer o seu trabalho. Dessa forma, ele “pega” a mensagem para ele, executa a ação de processamento do vídeo e remove a mensagem da fila.
- Ao final, ele coloca o vídeo gerado em outra estrutura de armazenamento e, novamente, notifica o sistema dizendo que o vídeo está pronto para ser exibido. Novamente esta comunicação é realizada através da postagem de uma mensagem em uma fila específica.
- De igual forma, o serviço especializado por finalizar o processo de publicação do vídeo pega esta nova mensagem e faz o que tem que ser feito (por exemplo, publica o vídeo e notifica todos os assinantes daquele canal de que um novo vídeo foi postado e está disponível para ser consumido).
O fluxograma desta aplicação de exemplo pode ser visto (há dez mil pés) através do diagrama apresentado pela Figura 1. Vale lembrar que trata-se apenas de uma aplicação fictícia.
Figura 1. Visão geral da arquitetura da aplicação de processamento de vídeos
Basta pensarmos um pouco para identificarmos uma série de eventos que estão ocorrendo de maneira assíncrona neste ambiente. Veja alguns deles:
- “Fazer algo” quando o vídeo chegar ao servidor de uploads.
- “Fazer algo” quando um novo vídeo chegar na estrutura de armazenamento.
- “Fazer algo” quando uma nova mensagem chegar na fila.
- “Fazer algo” quando a mensagem for retirada da fila.
Ou seja, uma aplicação simples como essa pode possuir (e geralmente possui) vários tipos de eventos associados a ela e, considerando este fato, é preciso pensar em maneiras de como resolver isso. Basicamente existem dois caminhos possíveis: 1) Implementar o gerenciamento destes eventos manualmente; 2) Recorrer a serviços já prontos para realizar tal gerenciamento (não tão fácil de se encontrar). Como todos sabemos, gerenciar todo este processo de mensageria e comunicação asíncrona não é tarefa fácil. Para muitas empresas, isso (implementar manualmente) não é uma opção viável, uma vez que expertise e recursos podem não estar disponíveis.
Event Grid é a resposta da Microsoft para estes cenários. Trata-se de um serviço de plataforma (PaaS) pioneiro no mercado de nuvem que tem a capacidade de gerenciar todo o fluxo de eventos entre os serviços do Azure que suportam uma dada aplicação. Ele já vem munido com capacidades importantíssimas como, retrys automatizados, roteamento automatizado de mensagens, assinaturas simplificadas para serviços do Azure, dentre outros. Você cria e configura o serviço (através do portal do Azure, Powershell ou CLI) e pronto, está a sua disposição um serviço altamente escalável, altamente disponível, serverless e com cobrança apenas pelo uso.
Desta forma, no exemplo acima, poderíamos utilizar o Event Grid para, por exemplo, monitorar storage e com base em determinados eventos do mesmo, fazer um post em uma API ou ainda, disparar um fluxo de execução para um Logic App, etc.
Um caso real
Há alguns dias recebemos algumas empresas na Microsoft para um hackaton. Como já é comum em nossas atividades de “code-with“, no primeiro dia, entendemos técnica e profundamente como as soluções dos clientes funcionam e, após isso, partimos para as ações necessárias para alcançar as expectativas dos clientes com a nuvem da Microsoft.
Em meu caso, fui alocado junto com Allan Targino (meu par no time de technical evangelists) para trabalhar com um cliente específico que possuía uma solução de Inteligência Artificial (IA) 100% offline. A solução deste cliente envolvia dois elementos básicos: hardware e software. O hardware (criado por eles) captava imagens (que mais tarde seriam analisadas pelos algoritmos de IA) e as salvava em um diretório específico no sistema de arquivos do computador onde o mesmo estava conectado. O software (foi desenvolvido em .NET (4.6) com frontend em Windows Form) “lia” as imagens salvas, as processava, salvava os dados da análise em um arquivo específico e, após isso, exibia os dados a partir deste arquivo.
O cliente queria criar um modelo de assinaturas (SaaS), ou seja, sair de um modelo 100% offline para, com o maior nível de reaproveitamento de código possível, um modelo híbrido de offline (10%) com online (90%). Com isso, além de um novo modelo de negócio, ele ganharia também densidade computacional, otimizaria o processo de entrega de código no ambiente produtivo e ainda, facilitaria o processo de manutenção e suporte ao sistema.
Fizemos então um processo de análise detalhado no código. Separamos o que era o coração do software (os algoritmos de IA) e transformamos isso em uma API RESTFul (Web API). Criamos também dois frontends distintos: o primeiro para ser instalado na máquina cliente (feito em Windows Forms – ele serviria apenas para fazer a comunicação entre o hardware e a nuvem) e o segundo, um frontend web, que serviria como dashboard online para o cliente visualizar os dados do processamento e mais informações que se fizessem necessárias. Além disso, definimos que um banco de dados NoSQL seria utilizado para armazenar os dados do cliente e das análises. Para controlar o processo de contas de clientes e usuários e ainda, para controlar o acesso a API, optamos pela utilização do Azure Active Directory. Para coordenar todos os eventos da solução, optamos por testar o Azure Event Grid.
A arquitetura final do frontend web + backend pode ser visualizada através do fluxograma exposto na Figura 2.
Figura 2. Visão geral da solução após o refactoring de arquitetura
Basicamente, o fluxo da aplicação ficou da seguinte maneira:
- O usuário manda as imagens para serem processadas na nuvem através do frontend local.
- A imagem chega diretamente para um blob em um storage account.
- Como o Event Grid foi configurado para monitorar este storage account, assim que uma operação de create ocorresse no container específico, um post com a imagem seria realizado na API de processamento. Todo o processo de retry e garantia da entrega do post é realizado pelo Event Grid.
- A API de processamento (que estava executando sobre Web Apps) então faz o seu trabalho e guarda o resultado do processamento no Cosmos DB.
- Após isso, o frontend web requisitava informações para a API que por sua vez, lia os dados do banco e os retornava para a visualização do cliente.
Tudo amplamente escalável e altamente disponível com grande densidade computacional.
Testes que provaram a viabilidade do Event Grid
Uma coisa é a teoria. Outra coisa, é a prática. Dessa maneira, antes de colocarmos esta solução em produção, o Allan Targino realizou alguns testes com o Event Grid (em um cenário semelhante ao de nosso cliente). Era especialmente para nós ver a eficiência do processo de retry, uma vez que queríamos eliminar filas da arquitetura sem abrir mão da garantia da entrega da mensagem. O teste consistiu basicamente de:
1. Um algoritmo simples gerava imagens de forma concorrente em um determinado storage account no Azure.
2. Ao gerar o evento de “create” no blob, o Event Hub então “pegaria a mensagem” e faria um post da mesma para um Azure Function (que aqui simula o serviço de processamento). O código da Function pode ser visualizado através da Figura 3.
Figura 3. Código do Function que força a re-entrega da mensagem pelo Event Grid ao gerar um bad request
Caso o Function gerasse um erro no recebimento da mensagem, o Event Hub deveria disparar o processo de retry e por isso mesmo, geramos alguns mensagens de erro propositais para testar este processo. A cada retry, logavamos os dados em um arquivo CSV. A Figura 4 apresenta um trecho do arquivo CSV, indicando as chamadas realizadas pelo Event Hub ao serviço.
Figura 4. Log de cada tentativa de entrega por parte do Event Grid
Durante os testes, o Allan verificou que, ao longo de 24 horas, são feitas 30 tentativas de entrega pelo Event Hub (veja a Figura 5). Verificando a documentação, entendemos porque isso ocorre. O modelo de retry é exponencial, seguindo a seguinte agenda de tentativas:
- 10 segundos
- 30 segundos
- 1 minuto
- 5 minutos
- 10 minutos
- 30 minutos
- 1 hora
Se um serviço não responder em 24 horas e ainda, após 30 tentativas, este serviço realmente possui um problema, certo? Fila nenhuma seria capaz de resolver algo dessa natureza.
Figura 5. Event Grid tentando entregar a mensagem
Como os resultados dos testes se mostraram amplamente satisfatórios (não apenas no aspecto do retry descrito aqui, mas também em outros como escalabilidade, etc.), optamos por adotar o Event Grid de maneira produtiva para o projeto deste cliente mencionado anteriormente. O resultado? Satisfação do cliente. Tudo funcionou de maneira amplamente satisfatória em uma arquitetura bem robusta utilizando apenas serviços PaaS, o que impacta positivamente em dois principais aspectos: 1) melhoria do custo da solução; 2) a simplificação de todo o processo de operação do ambiente.
Considerações importantes
Alguns outros pontos importantes que pudemos perceber com relação ao Event Grid:
- O Azure está muito grande, isto é, existem centenas de serviços atualmente disponíveis e o Event Grid ainda não dá cobertura para todos eles. É importante ter isso mente ao pensar em uma aplicação que irá coordenar eventos através deste serviço. Hoje estão disponíveis os seguintes event publishers: Blog Storage, Storage GPv2, Azure Subscriptions, Resource Groups, Event Hubs, IoT Hub e Custom Topics. Em relação aos event handlers, estão disponíveis neste momento: Azure Functions, Logic Apps, Azure Automation, Web Hooks, Event Hubs.
- O serviço, de fato, ajuda muito. Estamos falando do fato de uma aplicação web passar de um modelo de pooling para um modelo de webhook e isso é MUITO bacana.
- Ao se trabalhar com blobs, apenas dois tipos são aceitos: “Blob storage accounts” e “Storage Account General Purpose v2” e nem todos os datacenters do Azure já receberam a atualização para este tipo de recurso. Você pode encontrar uma lista com as regiões disponíveis seguindo este link.
É isso. Espero que este post possa lhe dar uma noção mais clara sobre o Event Grid e os benefícios proporcionados pelo serviço.
Forte abraço e até o próximo post.
Facebook
Twitter
Instagram
LinkedIn
RSS