4 Estratégias para Processamentos de Longa Duração ou Computação Intensiva

Muitas vezes, em nossos sistemas, temos tarefas que demandam processamento de  longa duração ou possuem alta complexidade computacional.

Na medida em que a demanda por nossos sistemas cresce (número de usuários/requisições), precisamos ter estratégias para suportar esse tipo de tarefa com resiliência e de forma escalável (sem comprometer a disponibilidade).

Neste post, compartilho algumas estratégias para abordar este desafio.

Se tiver interesse em entender mais sobre microsserviços, recomendo que acesse o Guia de Conteúdo para Microsserviços deste site.

1. Implementar cache/reaproveitamento

Com frequência, o resultado de tarefas com alta complexidade computacional pode ser reaproveitado para atender novas demandas. Quando este é o cenário, é inteligente armazenar o resultado do processamento.

Quanto mais “natural” for o armazenamento, melhor. Considere a utilização de bancos de dados NoSQL – como RavenDB, Redis ou MemCached para essa finalidade.

Caching é um tema complexo, nem tanto pela construção do Cache em si, mas pela definição de uma estratégia eficiente para invalidação dos dados armazenados (quando os dados já não são mais atuais). Entretanto, é praticamente impossível pensar em escalabilidade sem definir alguma estratégia eficiente de caching.

2. Adotar pré-processamento ou processamento Incremental

Considere a consulta abaixo:

SELECT Color, SUM(ListPrice), SUM(StandardCost)  
FROM Production.Product  
WHERE Color IS NOT NULL   
    AND ListPrice != 0.00   
    AND Name LIKE 'Mountain%'  
GROUP BY Color  
ORDER BY Color;  
GO  

Para finalidades de processamento e escala, esta consulta é um pesadelo! Considere-a sendo realizada milhares de vezes. Pelo número de variáveis, é muito difícil determinar uma estratégia de caching eficiente aqui. Concorda?

Em cenários com demanda de alta escalabilidade o ideal é converter essa consulta para algum mecanismo de processamento incremental. No RavenDB, por exemplo, suportamos esse tipo consulta com índices map/reduce. Ou seja, pré-computamos o resultado de forma a que, quando o conjunto de dados de origem é modificado, apenas as alterações são consideradas para atualizar o resultado da computação. A consulta ao índice é muito rápida e as atualizações também tem baixo custo. O ponto negativo é a utilização de disco para persistir o índice (além disso, os resultados são eventualmente consistentes).

Se você quer entender melhor o que é map/reduce, recomendo esse post do Ayende.

3. Utilizar mecanismos de mensageria para distribuir o trabalho (Work Queues)

Quando desejamos executar tarefas para computação intensiva, não necessariamente associada a consultas, uma estratégia plausível é distribuir o trabalho em unidades de processamento distribuídas orquestradas por um mecanismo de mensageria.

Uma boa explicação para esta estratégia pode ser encontrada na página do RabbitMQ.

The main idea behind Work Queues (aka: Task Queues) is to avoid doing a resource-intensive task immediately and having to wait for it to complete. Instead we schedule the task to be done later. We encapsulate a task as a message and send it to a queue. A worker process running in the background will pop the tasks and eventually execute the job. When you run many workers the tasks will be shared between them.

IMPORTANTE: Diferente do exemplo indicado, eu prefiro fazer publicação através de um Exchange com mapeamento direto em lugar de adicionar mensagens diretamente na Queue.

4. Formar um Cluster de processamento

Também quando desejamos executar tarefas para computação intensiva, não necessariamente associada a consultas, outra abordagem que utilizei eventualmente foi formar um Cluster para realizar o processamento. Em .NET, utilizei Akka.net Clustering para essa finalidade.

A cluster represents a fault-tolerant, elastic, decentralized peer-to-peer network of Akka.NET applications with no single point of failure or bottleneck. Akka.Cluster is the module that gives you the ability to create these applications.

O grande “pró” do Akka.net foi a supervisão inerente ao Actor Model que ocasionou um mecanismo com altíssima capacidade de recuperação de falhas.

Concluindo

Diferentes estratégias, com diferentes níveis de complexidades, estão a nossa disposição para desenvolver soluções escaláveis quando há demanda por execução de tarefas com alto custo/complexidade computacional.

A estratégia mais adequada sempre será determinada pela especificidade do domínio.

Compartilhe este insight:

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

For years, I have known developers who designed beautiful architectures. A lot of them are questioning the need for a...
Neste post, gostaria de compartilhar a estrutura que venho adotando em meus projetos com microsserviços. São algumas ideias que tenho...
Ontem, dia 25/07/2018, a convite do Canal.NET, compartilhei alguns insights sobre modelagem de microsserviços a partir de processos de negócio....
As professionals, we should focus on developing great technical solutions. But, these solutions need to solve real problems. At the...
Tenho realizado uma série de apresentações, em conferências, onde compartilho um pouco das lições que tenho aprendido implementando microsserviços. Abaixo,...
O que mais me agrada no C4 Model é a forma como detalhes vão sendo explicitados na medida em que...

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano anual do Clube de Estudos:

Crie sua conta

Preencha os dados para iniciar o seu cadastro no plano mensal do Clube de Estudos:

× Precisa de ajuda?