Como melhoramos nosso serviço com metodologia Lean e levantamento de métricas

Publicado por Marcelo Xavier no dia agile, dev

Esse post traz a discussão de como conseguimos uma melhora de 6.600% num dos principais serviços do RDStation - a atualização de palavras-chave. Contrariando o senso comum, atingimos esse número via a diminuição da paralelização do serviço.

O que houve?

Recentemente nossa infraestrutura estava sofrendo com a lentidão do serviço responsável por atualizar o ranking de palavras-chave. O serviço estava aquém do esperado para manutenção do sistema, uma vez que mais de 90% das palavras-chave se mantinham desatualizadas.

Lentidão

Ok, entendido, mas onde é que está o problema?

Bom, para atender nossas premissas seria necessário que a taxa fosse de, aproximadamente, 5.750 palavras-chave por dia. Descobrimos, após observar muitos atrasos, que estavámos com uma “incrível” taxa de 300 atualizações diárias.

Margem de erro

Photo by United States Mission Geneva / CC-BY-2.0

Como aqui na Resultados Digitais nós aplicamos a metodologia Lean com foco em dados (data driven), fomos analisar e colher métricas para entender o que estava acontecendo. Munidos dessas métricas praticamos pequenas, e simples, modificações no serviço e conseguimos aumentar, “um pouco”, a taxa: aproximadamente 20.000 palavras-chave atualizadas por dia.

Vamos destrinchar este problema e entender o que foi feito. Contextualizando, a infraestrutura que utilizamos para o serviço é composta de uma base de dados (postgresql), 11 máquinas e um serviço de terceiros que é quem realmenta executa a computação sobre os dados. O sistema funcionava em três passos (i) cada uma destas 11 máquinas buscava todas as palavras-chave que estavam desatualizadas há mais de um dia (cerca de 78.000 no total), (ii) cada uma destas máquinas enviava cada uma destas palavras para o serviço externo (API de terceiros) e (iii) a palavra-chave era salva novamente com a data atualizada. Este processo, apesar de simples, implica em três tipos de desperdícios:

  1. De reprocessamento de dados - Como eram 11 máquinas buscando recursos em apenas um banco de dados através da mesma consulta, isto poderia fazer com que uma palavra-chave fosse atualizada no mesmo momento até 11 vezes, isto é, uma vez por máquina;

  2. De gerência de tempo e recursos - Cada máquina tentava atualizar todos os 78.000 recursos, entretanto, apenas 0.001% eram de fato atualizados. Ou seja, o serviço tomava muito tempo e processamento de todas máquinas;

  3. De rede e de API externa - Como o serviço de terceiros é feito através de requisições HTTP, esta API externa bloqueava os IPs das máquinas por tempo indeterminado em função da alta carga de requisições. Cada máquina tentava fazer até 78.000 requisições por hora. Este era o principal gargalo do serviço.

Bloqueio

Photo by Nevermind2 / CC-BY-S.A 3.0

Caramba, e o que fizeram?

Em um primeiro momento coletamos a quantidade média de requisições que conseguimos efetuar antes de termos o IP bloqueado. Essa estatística nos permitiu fazer com que as chamadas nunca ultrapassassem esse valor máximo. Com isto resolvemos dois problemas, pois deixamos de ter nossos IPs bloqueados - por estarmos utilizando a API adequadamente - e cada máquina termina o processo até 790 vezes mais rápido.

Com a primeira mudança obtivemos um ganho no tempo de processamento, porém, ainda estávamos acessando a base de dados de maneira paralela. Modificamos, portanto, o modo de acesso para ser feito em série. Com isto, cada máquina passou a ser responsável por uma fatia das atualizações e apenas inicia quando sua sucessora tiver terminado o serviço. Isto poderia degradar o desempenho do sistema, não fosse o fato do sistema ter melhorado seu desempenho em até 790 vezes. :-)

Acesso serial

Photo by Hans A Rosbach / CC-BY-S.A 2.0

Apesar do aumento da taxa de atualização, com uma mudança elementar melhoramos ainda mais o desempenho. Reintroduzimos o paralelismo, mas no escopo de grupos. Dividimos dois grupos de máquinas e passamos a atualizar aquelas palavras-chave mais antigas, desatualizadas há mais de dois dias, no grupo 1. As palavras-chave com período mais recente de atualização, de um a dois dias atrás, são atualizadas pelo grupo 2. Os elementos dentro dos grupos ainda funcionam de maneira serial.

Acesso serial

Em suma, fazendo uso de métricas, sem aumento de custo de infraestrutura e com pequenos ajustes no sistema foi possível um ganho de desempenho de 66x em relação ao valor inicial. Lean e data driven levados à sério.

Marcelo Xavier

Marcelo Xavier

Full Stack Developer

Comentários