- Identificação do problema
- Ocorrência intermitente de latência de resposta no servidor de autenticação da Airbridge.
- Como a autenticação/autorização é realizada antes das requisições de API, a latência do servidor de autenticação afeta diretamente a estabilidade de todo o serviço.
- Pelos resultados de monitoramento, os alertas de atraso de resposta acima de 1 segundo estavam se tornando cada vez mais frequentes → início da análise de causa e do trabalho de otimização.
- Análise da causa
- (1) DB Query excessivas: no processo de verificação de permissões, havia DB Query em excesso a cada requisição, o que esgotava rapidamente o DB Connection Pool → causando atraso de resposta.
- (2) Saturação do HikariCP Connection Pool: ao executar DB Query em excesso, o pool do HikariCP saturava → foi observado que threads ficavam aguardando por mais de 30 segundos.
- (3) Baixa eficiência de cache: TTL configurado de forma muito curta, em 30 segundos + lógica de cache ineficiente → alta probabilidade de recorrência de DB Query.
- Estratégia de melhoria
- (1) Melhoria da estrutura de verificação de permissões e cache
- Adoção do método de consulta em lote ao DB (
findAllBy~) → DB Query reduzidas de 134 para 4 (-97%).
- Aplicação de cache
mutableMap baseado na memória da aplicação.
- Aplicação do princípio da responsabilidade única (SRP) → separação de métodos e definição de estratégias de cache por lógica subordinada.
- (2) Introdução de uma estrutura de cache em 2 camadas
- Aplicação de uma estrutura híbrida com Local Cache (Caffeine, L1) + Remote Cache (Redis, L2).
- As estratégias de cache foram detalhadas em L1-Only, L2-Only e Hybrid, melhorando a eficiência operacional.
- Análise do uso de memória do cache → previsão de 500 mil chaves no Redis, necessidade de aproximadamente 190MB de memória, com margem de segurança garantida.
- (3) Invalidação de cache baseada em Redis Pub/Sub
- Saída da dependência de TTL e sincronização de cache em tempo real quando as informações de permissão mudam.
- Quando ocorre uma alteração em um servidor, o Local Cache de todos os servidores é invalidado de forma sincronizada por meio de um canal do Redis.
- (4) Tuning do pool de conexões do HikariCP
- Expansão do
maximum-pool-size de 10 para 30.
- Otimização de opções detalhadas como Connection Timeout, Idle Timeout e Max Lifetime → alívio da contenção de DB I/O.
- Testes de desempenho e resultados: manutenção de desempenho estável mesmo sob grande volume de tráfego.
- Efeitos da melhoria no ambiente de produção
- Após o deploy, os alertas de atraso de resposta desapareceram, e o tempo geral de resposta se estabilizou.
- A confiabilidade do serviço e a estabilidade operacional melhoraram significativamente.
- Otimização adicional: JVM Warm-Up
- Foi identificado um problema de atraso na resposta das requisições iniciais devido ao atraso na compilação JIT logo após o deploy.
- Introdução do Warm-Up Runner:
- Execução prévia de requisições dummy no início da aplicação.
- No momento da troca de Pods no K8s, o tráfego passou a ser processado após a conclusão do JIT → tempo de resposta inicial reduzido de 1.07s para 94ms.
- Conclusão e efeitos
- Resolução do problema de atraso de resposta + obtenção de uma estrutura capaz de lidar com picos de tráfego.
- Melhoria da estabilidade e da confiabilidade dos serviços da Airbridge como um todo.
- Maior aproveitamento do servidor de autenticação, elevando a produtividade no desenvolvimento de serviços de domínio.
2 comentários
Com o recente encerramento do serviço de deep link do Google, parece que aumentou o número de empresas que usam este serviço.
Espero um serviço estável!
Ah... nossa empresa também fechou contrato aqui recentemente, então vocês estão trabalhando a todo vapor para melhorar o desempenho mesmo!!!