Incidente em US-East causado por esgotamento de conexões Redis
Em 3 de setembro de 2025 (US-East), tivemos tempos de fila elevados e, em alguns períodos, o processamento de Jobs ficou travado devido ao esgotamento de conexões Redis. O problema foi estabilizado no mesmo dia por meio de um hotpatch e de mudanças de configuração. Este post explica o que aconteceu, como mitigamos o problema e o que estamos fazendo para evitar que ele se repita.
Resumo
Um endpoint de serviço interno vazava conexões Redis quando era muito utilizado. Um cliente disparou um pico de requisições excepcionalmente grande para esse endpoint. Embora nosso modelador de tráfego tenha isolado o pico em uma fila de reserva, o vazamento de conexões propagou pressão pelos servidores Redis compartilhados. Quando os servidores atingiram seus limites de conexão, workers e caminhos de API legítimos da região ficaram sem recursos, o que resultou em filas lentas e travamentos intermitentes de Jobs. Implantamos um hotpatch para fechar as conexões vazadas e ajustamos os limites. Depois disso, o processamento voltou ao normal.
Impacto
- Período: 3 de setembro de 2025
- 12:00 UTC: codificação lenta em US-East, com muitas filas
- 19:50 UTC: tempos de fila elevados e excesso de conexões em fila observados
- 21:24 UTC: sistemas estabilizados; investigação da causa raiz em andamento
- 23:06 UTC: causa identificada e hotpatch implantado; recuperação confirmada
- Região:
us-east-1 - Impacto para os usuários:
- Tempos de fila acima do normal para Assemblies
- Em alguns casos, Jobs travados quando os servidores Redis recusavam conexões adicionais
- Webhooks/notificações e algumas interações com a API na região sofreram atrasos
Causa raiz
- Um caminho de código em um endpoint interno de alto tráfego não fechava as conexões Redis de forma confiável em determinadas condições de erro.
- A carga de trabalho de um único cliente utilizou esse endpoint em excesso sem querer, aumentando a rotatividade de conexões e expondo o vazamento.
- Os limites de conexão dos servidores Redis acabaram se esgotando, bloqueando novas conexões de workers e nós de API legítimos.
Fatores que contribuíram:
- Os pools Redis compartilhados ampliaram o raio de impacto quando os limites de conexão foram atingidos.
- O vazamento de conexões não aparecia nos dashboards existentes, porque as métricas do caminho de sucesso estavam saudáveis, enquanto a contabilização de conexões no caminho de erro não estava.
Detecção
Detectamos o problema por meio de alertas de latência de fila e anomalias no heartbeat dos workers.
Os engenheiros correlacionaram picos em connected_clients do Redis, o aumento da
rotatividade de conexões e erros ECONNREFUSED/max clients reached nos
servidores afetados.
Mitigação e recuperação
- O tráfego da carga de trabalho problemática já estava sendo direcionado aos poucos para uma fila de reserva isolada, o que limitou o impacto, mas não o eliminou.
- Aumentamos temporariamente os limites de conexão do Redis para criar margem durante o diagnóstico.
- Lançamos um hotpatch para garantir que as conexões sejam sempre liberadas, tanto no caminho de sucesso quanto no de erro, para o endpoint em questão.
- Reiniciamos os processos afetados para drenar as conexões vazadas e verificamos o funcionamento normal.
Às 21:24 UTC, os sistemas se estabilizaram. Às 23:06 UTC, o vazamento foi confirmado e o hotpatch foi implantado em toda a frota. Desde então, os sistemas continuam saudáveis.
Comunicação com os clientes
Publicamos atualizações na nossa página de status durante todo o incidente e entramos em contato com os clientes afetados. Após a mitigação, recomendamos tentar a reexecução da Assembly para recuperar resultados que, de outra forma, seriam perdidos, nos casos em que os arquivos de entrada ainda estavam disponíveis.
O que faremos a seguir
- Adicionar SLOs e dashboards de vazamento de conexões que acompanhem o ciclo de vida das conexões nos caminhos de sucesso e de erro.
- Introduzir orçamentos de conexão por endpoint e circuit breakers para conter vazamentos.
- Reforçar o pooling do cliente Redis com timeouts rigorosos e blocos
finallyverificáveis por linter em torno da aquisição de conexões. - Separar as funções críticas do Redis (filas, locks, metadados) em pools distintos, com limites próprios.
- Tornar mais rigorosa a limitação de taxa no endpoint afetado, com backpressure que degrada de forma controlada.
- Adicionar testes de caos para simular indisponibilidades parciais do Redis e avalanches de conexões.
Se você foi afetado
Reexecute os Jobs críticos quando for viável. Se os seus arquivos de entrada ainda estiverem disponíveis, você pode reexecutar uma Assembly com falha pela nossa API. Consulte Reexecutar uma Assembly. Se precisar de ajuda para identificar os Jobs impactados, entre em contato com o suporte e nós ajudaremos.
Atualização de 4 de setembro de 2025
Um dia depois, tivemos outro incidente. Embora tivéssemos eliminado uma fonte de vazamento, descobrimos que havia outra. Desta vez, conseguimos detectá-la mais cedo e mitigar o problema em menos de uma hora.
Concluímos um reforço adicional para reduzir a chance de repetição. Adicionamos limites de taxa específicos ao endpoint envolvido, melhoramos a higiene de conexões nos caminhos de código que tratam erros e separamos algumas responsabilidades do Redis em pools distintos, com limites mais claros. Juntas, essas mudanças reduzem o raio de impacto e tornam o sistema mais resiliente sob cargas de trabalho com picos.
Também ampliamos o monitoramento e os alertas para focar em sinais precoces, como rotatividade anormal de conexões e pressão nas filas, para que possamos reagir mais rápido se padrões semelhantes surgirem. Essas melhorias já estão ativas em US-East e serão implantadas nas outras regiões como precaução.
Considerações finais
Pedimos sinceras desculpas pela interrupção. Confiabilidade é nossa maior prioridade, e não cumprimos nossos próprios padrões em US-East no dia 3 de setembro. As correções listadas acima já estão em andamento, e informaremos caso haja outras mudanças relevantes.