AWS Kinesis us-east-1 (2020): Quando um Limite de Threads do SO Derrubou Metade da AWS

Na manhã de 25 de novembro de 2020, véspera do Thanksgiving nos EUA e início da semana da Black Friday, a equipe do Amazon Kinesis executou uma expansão de capacidade planejada na região us-east-1. O objetivo era aumentar o número de servidores front-end do Kinesis para suportar a carga crescente esperada para o período de pico comercial. Trata-se de uma operação de rotina em qualquer sistema distribuído de larga escala: adicionar nós para distribuir carga.

O problema estava em um detalhe de implementação dos servidores front-end do Kinesis. Cada servidor front-end mantém conexões com todos os outros nós do cluster, um modelo de topologia all-to-all que é comum em sistemas que precisam rotear requisições para shards específicos sem uma camada adicional de indireção. À medida que o número de servidores front-end aumentava, cada servidor precisava abrir e manter mais conexões simultâneas. Cada conexão, por sua vez, utilizava uma thread dedicada para gerenciamento I/O.

O sistema operacional Linux impõe um limite no número de threads que um único processo pode criar, o parâmetro ulimit -u (ou threads-max em nível de kernel). Quando o número de servidores front-end cruzou um determinado limiar, os processos Java nos servidores existentes tentaram criar novas threads para gerenciar as conexões com os novos nós e falharam com erros do tipo java.lang.OutOfMemoryError: unable to create new native thread. A partir desse ponto, os servidores front-end do Kinesis começaram a rejeitar requisições e a apresentar falhas de health check.

Até aqui, o incidente seria contido ao Kinesis. O que transformou isso em um desastre regional foi algo que a maioria dos engenheiros externos à AWS não sabia: uma parcela significativa dos serviços AWS internos utiliza o próprio Kinesis como infraestrutura de telemetria, logging e entrega de eventos. O SDK interno da AWS, utilizado por serviços como Cognito, CloudWatch, Lambda e ECS para publicar métricas e logs, dependia do Kinesis. Quando o Kinesis ficou degradado, esses serviços começaram a acumular filas de envio de telemetria, e os próprios mecanismos de health check e recuperação automática desses serviços, que dependiam de CloudWatch para alarmes e de Cognito para autenticação de chamadas internas, também falharam.

O aspecto mais instrutivo deste incidente não é o bug em si, é o que ele revelou sobre a arquitetura interna da AWS. O Kinesis não é apenas um serviço de streaming para clientes externos; ele é uma peça de infraestrutura interna crítica usada por outros serviços AWS para transportar telemetria, logs e eventos de controle. Essa é uma decisão arquitetural que faz sentido: usar o próprio produto como infraestrutura interna (dogfooding) valida o serviço em produção real e reduz a necessidade de manter stacks de observabilidade paralelas.

O problema é que essa dependência criou um acoplamento estrutural não documentado publicamente. Quando o Kinesis falhou, o CloudWatch, que dependia do Kinesis para ingerir métricas, parou de receber dados. Sem métricas chegando, alarmes que deveriam disparar automaticamente ficaram silenciosos. Isso criou uma situação de alarm blindness: as próprias ferramentas que deveriam detectar e alertar sobre o incidente estavam comprometidas pelo incidente. As equipes de on-call perderam visibilidade justamente quando mais precisavam dela.

O Cognito, por sua vez, usava Kinesis para telemetria interna. Quando o Kinesis ficou degradado, chamadas de autenticação do Cognito começaram a falhar, não porque o Cognito em si estava quebrado, mas porque o caminho de telemetria estava bloqueado e isso afetava o fluxo de controle. Isso impactou diretamente usuários finais que dependiam do Cognito para autenticação em suas aplicações, e também impactou o Console AWS, que usa Cognito para autenticação de sessão. O resultado foi que engenheiros tentando diagnosticar o problema pelo Console também encontravam dificuldades para fazer login.

Esse padrão, onde o sistema de observabilidade depende do sistema que está falhando, é um anti-padrão clássico de resiliência. Em sistemas financeiros onde trabalhei, chamamos isso de observer coupling: quando o observador e o observado compartilham o mesmo plano de falha, você perde a capacidade de diagnóstico exatamente quando mais precisa dela. A solução arquitetural é garantir que o plano de controle e observabilidade seja completamente independente do plano de dados que está sendo monitorado.

A remediação imediata foi direta: reverter a expansão de capacidade, reduzindo o número de servidores front-end para abaixo do limiar que causava o esgotamento de threads. À medida que os servidores front-end voltaram a funcionar normalmente, os serviços dependentes começaram a se recuperar, primeiro o Kinesis em si, depois CloudWatch, depois Cognito, e assim por diante, em ordem inversa à cascata de falhas.

A AWS publicou um post-mortem detalhado (Summary of the Kinesis Event) que identificou várias ações corretivas. Em termos de mitigação imediata, a equipe aumentou os limites de threads do SO nos servidores front-end e modificou o código para usar conexões assíncronas (non-blocking I/O) em vez de threads dedicadas por conexão, uma mudança arquitetural que elimina a dependência linear entre número de conexões e número de threads. Com NIO/async, um único pool de threads pode gerenciar milhares de conexões simultâneas.

Para prevenir recorrência, a AWS comprometeu-se com: (1) monitoramento ativo de métricas de recursos do SO, incluindo uso de threads, em todos os serviços críticos; (2) implementação de testes de capacidade que validem limites de recursos do SO antes de mudanças operacionais de scaling; (3) revisão das dependências internas entre serviços para identificar e mitigar acoplamentos que poderiam propagar falhas; (4) melhoria do plano de observabilidade para garantir que métricas críticas de saúde dos serviços sejam entregues por um caminho independente do Kinesis quando o Kinesis está degradado.

Do ponto de vista de clientes, a lição operacional é clara: não assuma que o Service Health Dashboard da AWS reflete com precisão e em tempo real o estado de todos os serviços. Durante este incidente, o dashboard estava ele próprio comprometido pelo mesmo problema que afetava o CloudWatch. Sistemas críticos devem ter health checks sintéticos independentes, fora da AWS ou em múltiplas regiões, que validem o comportamento real da aplicação, não apenas o status reportado pelo provedor.