A Agoda migrou seu cache de preços de hotéis, com 1,5 TB de dados voláteis e 1,5 milhão de escritas por segundo, de 72 shards de SQL Server para o memtier_benchmark no GitHub (github.com).com/dragonflydb/dragonfly" target="_blank" rel="nofollow noopener">DragonflyDB no GitHub (github.com), e registrou melhora de cerca de oito vezes na latência de leitura P99.
- Agoda substituiu 72 shards de SQL Server por clusters DragonflyDB no cache de preços de 1,5 TB
- Latência de leitura P99 melhorou cerca de oito vezes, atendendo 300 mil requisições por segundo a 8 ms
- Migração usou leituras duplas com métricas de paridade do Prometheus acima de 99,9%
- Tráfego foi migrado gradualmente por experimento A/B até 100% no novo sistema
- Failover descentralizado por pod detectou falha simulada e respondeu em cerca de dois minutos
Por que o SQL server deixou de ser viável para o cache de preços da agoda
A arquitetura anterior exigia roteamento de shards no nível da aplicação, distribuído entre 72 shards de SQL Server. Escalar significava adicionar hardware em incrementos predefinidos, seguido de remapeamento manual dos shards e migração de dados.
Depois de dobrar a capacidade de hardware no início de 2024, a equipe já se aproximava dos limites novamente em menos de um ano. Clarkson Chang, engenheiro líder da Agoda, afirmou que continuar adicionando recursos ao SQL Server não era uma estratégia viável nem economicamente sustentável.
Como a agoda validou o dragonflydb antes da troca
A equipe avaliou o DragonflyDB contra a carga real de trabalho, usando o memtier_benchmark para reproduzir proporção de leitura e escrita de 1 para 6 com operações MGET de 10 chaves.
A migração foi incremental: uma instância de 1 TB para dados quentes, depois um desenho de três shards por cluster até comportar os 1,5 TB completos, processando cerca de 1,6 milhão de escritas por segundo com P99 em torno de 10 milissegundos.
# publicidade
O failover descentralizado que dispensou coordenador central
Dois clusters DragonflyDB, A e B, garantem alta disponibilidade. Cada pod de aplicação compara independentemente as taxas de acerto de cache usando cinco minutos de observações locais.
| Arquitetura | Modelo | Latência/volume observado |
|---|---|---|
| SQL Server, 72 shards | Roteamento de shards na aplicação, escalonamento manual por hardware | 1,5 TB; limites atingidos menos de um ano após dobrar a capacidade em 2024 |
| DragonflyDB, 3 shards por cluster | Cluster com shared-nothing multithread e expiração nativa de chaves | 1,6 milhão de escritas/s a 10 ms P99; 300 mil leituras/s a 8 ms P99 |
Arraste para o lado para ver toda a tabela.
Uma divergência de 10 pontos percentuais marca um cluster como ilegível; a recuperação exige diferença abaixo de três pontos. Em simulação de falha, cerca de 40 pods entraram em failover em aproximadamente dois minutos, sem intervenção manual.
Leia também:
Fonte: Infoq
