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.
