AWS Kinesis 2020: limite de threads do SO depois de adicionar capacidade

01 · CONTEXTO

Uma frota na frente de células

Em 25 de novembro de 2020, uma falha na região Northern Virginia (US-EAST-1) da AWS afetou o Kinesis, serviço de processamento de dados em fluxo, e vários serviços que dependem dele. O caso vale pelo que o resumo oficial da AWS mostra: o gatilho foi uma operação rotineira, e a causa estava em um limite que ninguém vigiava. Ele conversa com disponibilidade e tolerância a falhas, filas e streams e observabilidade.

O Kinesis tem dois níveis. No fundo, muitas células de back-end processam os streams: cada uma é dona de vários shards e funciona como unidade de escala e de isolamento de falhas. À frente fica uma frota de front-end que autentica, limita a taxa e roteia cada requisição ao shard certo. É essa frota que mantém, em cada servidor, um cache chamado shard-map.

1. Clientes e outros serviços da AWS gravam e leem registros pelo front-end.

2. O front-end roteia cada requisição à célula de back-end dona do shard. A célula é a unidade de escala e de isolamento de falhas.

3. Para rotear, o servidor consulta o shard-map, montado com dados de membros, de configuração e de mensagens dos outros servidores.

4. Cada servidor abre uma thread do sistema operacional para cada outro servidor da frota. É nesse detalhe que o incidente nasce.

02 · O GATILHO

Capacidade nova, limite escondido

Entre 2h44 e 3h47, no horário do Pacífico, a AWS adicionou uma quantidade relativamente pequena de capacidade ao front-end. Segundo o resumo, esse foi o gatilho, e não a causa raiz. Os servidores que já operavam levam até uma hora para descobrir os novos e abrir as threads correspondentes.

Os primeiros alarmes de erro ao gravar e ler registros dispararam às 5h15. A causa, confirmada depois, foi que a nova capacidade fez todos os servidores da frota excederem o número máximo de threads permitido por uma configuração do sistema operacional. Sem threads, o cache não terminava de ser montado, e o servidor ficava com um shard-map inútil, incapaz de rotear para o back-end.

1. A frota recebe servidores novos. Parece uma mudança segura e pequena.

2. Cada servidor existente descobre os novos aos poucos e abre mais threads, uma por par.

3. Em todos os servidores, o total de threads passa do limite do sistema operacional.

4. Sem threads suficientes, o cache não termina de ser montado. O shard-map fica inutilizável.

5. O front-end não sabe a qual célula enviar a requisição. As células seguem de pé, mas ficam inalcançáveis.

O total de threads de cada servidor cresce em proporção ao tamanho da frota. Adicionar servidores, que normalmente dá folga, aqui consumiu o recurso que ninguém media. Isso é uma limitação de escala por servidor, não de capacidade total.

03 · O DIAGNÓSTICO

Muitos erros, uma causa só

O diagnóstico foi lento porque havia erros em todos os aspectos das chamadas feitas por servidores novos e antigos, o que dificultou separar efeito de causa. A nova capacidade era suspeita, e a equipe começou a removê-la por precaução. Às 7h51 restavam algumas hipóteses, e todas as mais prováveis exigiam reiniciar a frota inteira, um processo longo e cuidadoso. A causa foi confirmada às 9h39.

O reinício não podia ser rápido. Os recursos de um servidor usados para montar o shard-map competem com os usados para atender requisições. Religar servidores depressa criaria contenção, deixaria poucos recursos para atender e faria servidores lentos serem tratados como não saudáveis e retirados da frota, o que atrasaria a recuperação.

04 · A RECUPERAÇÃO

Voltar devagar para voltar de vez

Com a nova capacidade já removida, a contagem de threads não passaria mais do limite, então a equipe optou por reiniciar sem aumentar o limite do sistema operacional. Os primeiros servidores voltaram a receber tráfego às 10h07. Como a frota tem muitos milhares de servidores, só era possível adicionar algumas centenas por hora, e o Kinesis só voltou totalmente ao normal às 22h23.

1. Um servidor reiniciado precisa montar o shard-map e atender requisições com os mesmos recursos.

2. Se muitos voltam ao mesmo tempo, o atendimento fica lento. Servidores lentos podem ser tidos como não saudáveis e removidos, o que atrasa a recuperação.

3. No método original, o servidor obtém dados do shard-map dos vizinhos, que também estão se recuperando.

4. Em paralelo, a equipe configurou os servidores para obter os dados direto do armazenamento autoritativo de metadados, acelerando o bootstrap.

05 · O EFEITO CASCATA

Quem dependia do Kinesis caiu junto

O Kinesis é usado por vários outros serviços da AWS, e a falha se espalhou por dependências que, no papel, eram toleráveis. O Cognito, por exemplo, usa o Kinesis só para coletar padrões de acesso, em regime de melhor esforço, com buffer local. A falha prolongada ativou um bug latente nesse buffer, e os servidores web do Cognito passaram a bloquear. Usuários externos não conseguiram autenticar nem obter credenciais temporárias da AWS.

1. O Kinesis fica degradado e todos os serviços que enviam dados a ele passam a sofrer.

2. O Cognito enviava dados em melhor esforço, mas o bug latente no buffer o fez bloquear nas filas represadas.

3. A ferramenta que publica o painel público de status dependia do Cognito e ficou indisponível no início.

4. O CloudWatch, que usa o Kinesis para métricas e logs, perdeu a maior parte delas e seus alarmes foram a um estado de dados insuficientes.

5. O Lambda acumulou métricas em buffer até causar contenção de memória, e o AutoScaling reativo, sem métricas, atrasou decisões de escala.

6. O EventBridge atrasou eventos, e o ECS e o EKS, que os usam em fluxos internos, tiveram impacto em clusters e tarefas.

06 · O QUE MUDOU

Menos threads, mais células, melhor aviso

No curto prazo, a AWS decidiu usar servidores maiores em CPU e memória, reduzindo o total de servidores e as threads de cada um. Também acrescentou alarmes finos de consumo de threads e passou a testar um aumento do limite do sistema operacional. Para a partida a frio, moveria o cache do front-end para uma frota dedicada e levaria serviços grandes, como o CloudWatch, a uma frota de front-end separada e particionada.

No médio prazo, a AWS prometeu acelerar a celularização do front-end, para igualar o que já havia no back-end. Segundo o resumo, celularização isola os efeitos de falha e mantém componentes, como o cache de shard-map, em uma faixa já testada. O trabalho já estava em andamento, mas era grande e ainda não estava concluído.

Os serviços dependentes também mudaram. O Cognito foi modificado para suportar erros do Kinesis sem esgotar os buffers, e o CloudWatch passou a guardar localmente três horas de métricas, acessíveis ao AutoScaling. A AWS também revisou o treinamento para que os operadores usem a ferramenta de reserva do painel de status, que se mostrou mais manual e menos familiar.