Arquiteturas de Referência

Projetando Workloads para tratar processamentos com longa duração ou custo computacional no Azure

Eventualmente, precisamos projetar workloads que recebem requisições dos clientes – usuários ou outros sistemas – demandando processamentos de longa duração ou com elevado custo computacional.

Workload (Carga de Trabalho)

Um workload é uma coleção de itens de infraestrutura, aplicações e dados que, coletivamente, suportam um objetivo de negócio ou a execução de um processo de negócios.  Exemplos de workloads são aplicações LoB, como “folha de pagamento”, CRM, fluxos de trabalho para aprovação de documentos, etc.

Eventualmente, workloads compartilham recursos técnicos (como bancos de dados).

O usual é que tais workloads sejam projetados para garantir baixo response time para as requisições dos clientes, postergando os processamentos mais pesados para que ocorram, mais tarde, em segundo plano, com o melhor throughput possível.

Abstração arquitetônica

As arquiteturas para workloads como os descritos neste post costumam contemplar:

  • uma ou mais interfaces (web frontend) para atender as demandas dos clientes, com o melhor response time possível;
  • algum mecanismo de sequenciamento ou agendamento onde as demandas mais “pesadas” são enfileiradas para processamento posterior;
  • um ou mais artefatos computacionais (workers) que executam o trabalho, com o melhor throughput possível;

Não raro, as arquiteturas também incluem:

  • uma ou mais bases de dados (relacionais ou não relacionais);
  • proxies para APIs internas ou para serviços remotos;
  • algum mecanismo de caching para diminuir a pressão sobre as bases de dados, APIs internas ou serviços remotos, diminuindo tempos de leitura;
  • CDN para conteúdos estáticos.

Com vistas a garantir elasticidade horizontal, tanto web frontends quanto workers, nessas arquiteturas, costumam ser stateless e usam caching distribuído para armazenamento de estados transientes.

Todo trabalho “pesado” é executado assincronamente pelos workers que são acionados por mecanismos de mensageria ou de agendamento. Operações “leves” podem ser executadas diretamente pelos web frontends.

Essa proposta de design tem as vantagens de ser simples de entender e manter. Também é positivo o desacoplamento entre o frontend e o worker, reforçado pelo mecanismo de mensageria. Entretanto, principalmente para as operações síncronas, é importante evitar implementações demasiadamente complexas, sobretudo no frontend que possam aumentar o custo de manutenção futura.

Implementação no Azure

A opção pela implementação da arquitetura descrita acima, na nuvem, é natural implicando no uso das tecnologias apropriadas em cada componente.

Caso o frontend seja implementado usando Azure App Service, será possível utilizar mecanismos de escalonamento automatizado para suportar flutuações de demanda. Aliás, é importante colocar o frontend e o worker em planos diferentes para que o escalonamento de ambos componentes seja independente.

Principais ganhos para a organização

Workloads que tratam requisições de longa duração e com alto custo computacional costumam ser específicos e com baixa dependência de outras rotinas da empresa, entregando valor consistente. Por isso, são ideais para iniciar jornadas de modernização e migração de aplicações para a nuvem, mitigando receios eventuais.

Outro aspecto importante é que esse tipo de solução, frequentemente, demanda estratégias de provisionamento complexas, quando executadas on-premises. Usar uma infraestrutura em nuvem reduz significativamente essa complexidade.

Finalmente, todos os componentes e soluções de nuvem usados nessa proposta arquitetura são aplicáveis e comuns, também, para outros cenários. Dessa forma, a “curva de aprendizado” do time acaba ficando menos desafiadora para o futuro.

Em Resumo
  • O problema

    Determinados workloads que recebem requisições dos clientes - usuários ou outros sistemas - demandando processamentos de longa duração ou com elevado custo computacional. Eles devem ser projetados para garantir baixo "response time" para as requisições dos clientes, postergando os processamentos mais pesados para que ocorram, mais tarde, em segundo plano, com o melhor "throughput" possível.
  • O insight

    Desacoplar o tratamento das requisições dos clientes, com um "frontend" leve, usando algum mecanismo de mensageria para permitir execução mais tarde por parte de um "worker". Além disso, utilizar estratégias de caching para reduzir tanto o custo de obtenção de dados interno, quanto o fornecimento de artefatos estáticos para o cliente. Tudo isso, é natural com tecnologias e recursos fornecidos pelo Azure.
  • Os benefícios

    Esses workloads, além de gerar valor percebido, geralmente são "independentes". Por isso, são ótimas "primeiras opções" para iniciar a jornada para a nuvem. Além disso, na nuvem, reduzem a complexidade do provisionamento. Finalmente, todo o aprendizado envolvido nesse tipo de projeto será útil em projetos futuros envolvendo a nuvem por terem grande aplicabilidade.

Mais posts da série Arquiteturas de Referência

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *