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:

Deixe uma resposta

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

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:

In a previous post, I wrote about how to support sagas using a Workflow Engine as Saga Execution Coordinator (if...
As you probably noted, my old blog posts are gone! It’s sad, but I had to take this way. Main reasons:...
Pimenta nos olhos dos outros é refresco. Quando não é pela satisfação sádica proporcionada pela dor alheia é pelo alívio...
Este post foi originalmente publicado em 2015 (infelizmente, a postagem original não está mais disponível) Nesse post vamos implementar, passo-a-passo,...
It’s time to start learning RavenDB 4. Even if you know previous versions of RavenDB, you will probably get good...
No meu tempo absolutamente livre – quando não estou trabalhando, estudando ou aproveitando com a família – tenho jogado Mario...