Redis: Como Identificar e Reduzir o Uso Desnecessário

Resumo

Este artigo descreve o processo completo de análise e otimização do uso do Redis em um microsserviço Spring Boot. Utilizamos ferramentas como Datadog e redis-cli para identificar gargalos, eliminar redundâncias, e reduzir o consumo de memória. Foram implementadas ações como unificação de chaves, compressão de dados em cache, e refatoração de métodos com @Cacheable. O resultado foi a diminuição da pressão sobre o Redis e a criação de boas práticas reaproveitáveis em outras áreas da aplicação.

Ferramentas Utilizadas na Análise

Para realizar a análise de uso do Redis e identificar oportunidades de otimização, utilizei duas ferramentas principais:

🔍 Datadog

O Datadog é “uma plataforma de observabilidade e segurança para aplicações em nuvem” (fonte). Utilizei-o para:

• Monitorar métricas de cache em tempo real;
• Identificar quais endpoints e serviços realizavam mais acessos ao Redis;
• Priorizar os pontos de maior impacto para investigação e otimização.

💻 Redis-cli

O redis-cli, ferramenta oficial de linha de comando do Redis, foi essencial para obter dados detalhados. Usando comandos como:

• INFO memory
• SCAN e KEYS
• MEMORY USAGE <key>

Analisamos:

• Volume de dados por padrão de chave;
• Quantidade de registros armazenados;
• Impacto de cada grupo de chave no consumo total de memória.

Tipos de Análises para Redução de Custos

Após identificar os serviços com maior impacto, executamos seis tipos principais de análises.

1. Agrupamento e Unificação de Chaves e Endpoints

Objetivo: Eliminar duplicidade de chaves e reduzir chamadas redundantes ao Redis.

Exemplo prático:

Três métodos distintos utilizavam o mesmo endpoint no backend, mudando apenas os parâmetros. Isso resultava em múltiplas chaves Redis para a mesma origem de dados. A solução foi:

• Unificar os métodos e comandos em uma só função de cache;
• Utilizar uma chave parametrizada única, facilitando a manutenção e reduzindo o espaço em memória.

2. Compactação de Dados Armazenados

Objetivo: Reduzir a memória consumida por objetos Java serializados.

Solução aplicada:

Implementamos um decorator da interface org.springframework.cache.Cache que aplica compactação GZIP antes de salvar e descompacta ao recuperar. Exemplo:

public class GzipCacheDecorator implements Cache {
private final Cache delegate;

public GzipCacheDecorator(Cache delegate) {
  this.delegate = delegate;
}

@Override
public void put(Object key, Object value) {
  byte[] compressed = GzipUtils.compress(SerializationUtils.serialize(value));
  delegate.put(key, compressed);
}

@Override
public ValueWrapper get(Object key) {
  byte[] compressed = (byte[]) delegate.get(key, byte[].class);
  return () -> SerializationUtils.deserialize(GzipUtils.decompress(compressed));
}

// outros métodos omitidos
}

3. Eliminação de Registros Desnecessários

Objetivo: Evitar o armazenamento de dados vazios.

Exemplo real:

Cache exemplo tinha mais de 22.000 registros, muitos dos quais continham listas vazias.

Solução Aplicada:

• Adicionamos uma flag pré-processada como condicional à busca do dado ou não.

4. Evitar Auto-invocação com @Cacheable

Problema: Em chamadas internas entre métodos de uma mesma classe, a anotação @Cacheable é ignorada pelo proxy do Spring.

Solução:

Extrair o método anotado com @Cacheable para um novo componente injetado na classe original.

5. Verificação de Local Adequado para o Cache

Objetivo: Garantir que os caches estejam no ponto certo da aplicação.

Mesmo sem ajustes necessários nesse caso, validamos que os caches estavam todos aplicados na camada de serviço, evitando duplicidade com cache local em controladores e serviços. Mas, vale destacar que essa analise é crucial.

Conclusão

A análise estruturada do uso do Redis com Spring Boot, utilizando Datadog e redis-cli, resultou em diversas melhorias:

• Redução de consumo de memória via unificação e compressão;
• Melhoria de legibilidade e manutenção com refatorações de chave;
• Ajustes de lógica de cache para evitar falhas silenciosas (como auto-invocação);

Essas ações não apenas reduziram o custo de infraestrutura, mas também abriram caminhos para um uso mais inteligente do Redis em outros microsserviços da plataforma.