Resumo

  • Ao ampliar o Kinesis, a AWS aumentou também os threads que cada servidor frontal precisava manter para falar com os demais. A frota inteira ultrapassou o limite configurado no sistema operacional.
  • Na recuperação, refazer os mapas de encaminhamento disputava recursos com os pedidos dos clientes. Máquinas disponíveis tiveram de esperar para voltar a atender.

A promessa de uma tarefa secundária é ocupar pouco espaço. No dia 25 de novembro de 2020, a tarefa de registrar padrões de acesso ajudou a bloquear o acesso de usuários.

O Cognito enviava essas informações ao Kinesis e guardava dados temporariamente quando não conseguia transmiti-los. Uma interrupção prolongada revelou um defeito no código dessa fila: os servidores web começaram a ficar presos ao acúmulo. Houve falhas de autenticação e de obtenção de credenciais temporárias.

O relato oficial da AWS permite seguir a conta até sua origem. Na Virgínia do Norte, uma expansão relativamente pequena da frota frontal do Kinesis havia aumentado o trabalho de comunicação de todos os seus membros. Os servidores ultrapassaram o máximo de threads permitido pela configuração do sistema operacional. A empresa chama a expansão de gatilho e separa dela a causa raiz.

Era capacidade nova chegando com uma despesa para a capacidade antiga. A nuvem, naquele dia, cresceu até deixar de caber na própria organização.

O pedágio cobrado dos servidores antigos

Os fluxos do Kinesis eram divididos em fragmentos processados por grupos de servidores organizados em células. Na entrada, os servidores frontais cuidavam de autenticação, limites de tráfego e encaminhamento. Cada um precisava manter um mapa dos membros e da responsabilidade pelos fragmentos.

Esse mapa usava várias fontes de informação, entre elas as mensagens dos outros servidores frontais. Para conversar com os demais, cada servidor criava threads do sistema operacional. Quando entrava mais gente na lista, os participantes antigos também passavam a manter novas comunicações. A descoberta dos recém-chegados podia levar até uma hora.

Concluir a instalação não encerrava, portanto, seu efeito sobre a frota. O custo ainda se espalhava. Quando o teto de threads foi atingido, os mapas deixaram de ser montados corretamente. A entrada já não conseguia despachar os pedidos para os destinos certos.

A existência de células no processamento não resolvia o tamanho desse trabalho comum na entrada. Separar uma parte do sistema compra uma proteção específica. É preciso perguntar o que continua compartilhado do lado de fora.

Na apresentação comercial, capacidade costuma ser um número pronto para somar. Aqui, havia uma dedução crescente. Cada novo servidor entregava recursos e exigia recursos dos outros. O resultado útil dependia dos dois movimentos.

A volta teve limite de velocidade

Retirar os servidores adicionados permitiu baixar a contagem de threads. A AWS preferiu não aumentar o limite do sistema operacional sem testes adicionais. Mas a correção ainda precisava ser convertida em serviço.

Na inicialização, cada frontal reconstruía seu mapa. Fazer isso e atender às solicitações dos clientes exigia os mesmos recursos. Se muitos voltassem ao mesmo tempo, poderiam responder devagar, ser classificados como problemáticos e sair novamente da frota. A recuperação tinha de proteger a si mesma da pressa.

O início foi alterado para buscar informações diretamente no repositório de metadados de referência, em vez de depender dos vizinhos. Mesmo assim, de muitos milhares de servidores, só algumas centenas podiam voltar por hora. O primeiro grupo recebeu tráfego às 10h07 do horário padrão do Pacífico; o Kinesis voltou ao normal às 22h23. As taxas de erro caíram ao longo da retomada.

O equipamento estava lá. Faltava colocá-lo para trabalhar numa velocidade que não derrubasse o que já estava voltando. É uma diferença importante para quem compra horas de processamento: a capacidade de retomar o atendimento merece um número próprio.

Uma fila de trabalho atrasado torna essa diferença ainda mais concreta. Durante a volta chegam os pedidos novos, o estoque de pedidos pendentes e o trabalho de reconstruir o estado do sistema. Ensaiar apenas a situação em que tudo já está aquecido deixa essa concorrência fora da prova.

Quando observar exige que tudo funcione

O Cognito não foi o único a herdar a dificuldade. O CloudWatch teve problemas no processamento de métricas e registros; alguns alarmes passaram a indicar dados insuficientes. Políticas reativas de Auto Scaling que dependiam dessas métricas demoraram a agir. No Lambda, o acúmulo de métricas nos buffers gerou disputa de memória nos equipamentos de execução e elevou os erros.

Esses mecanismos eram diferentes. O Kinesis atingiu uma configuração de threads; o Lambda sofreu pressão de memória; o Cognito ficou preso à sua fila. Um mesmo serviço de origem pode levar produtos distintos a pontos de falha distintos. Por isso, a marca comum na fatura informa menos que a dependência comum na operação.

Até o instrumento habitual para publicar o estado dos serviços usava o Cognito. A alternativa de poucas dependências funcionou, mas era mais manual e menos familiar à equipe. Os primeiros avisos se atrasaram. Ter uma saída de emergência e saber abri-la durante o susto são entregas que precisam andar juntas.

Menos participantes, mais espaço para servir

A AWS anunciou máquinas com mais CPU e memória para reduzir o número total de frontais e, assim, os threads mantidos por cada um. A lista incluiu alarmes mais detalhados, testes de um limite maior, inicialização mais rápida, separação do cache e frontais particionados para alguns serviços grandes. Também previa acelerar a divisão dos frontais em células.

O fio condutor era restringir a quantidade de organização necessária para fazer o trabalho útil. Comprar processadores, reduzir a lista de interlocutores e limitar a área de uma falha eram partes diferentes da solução.

A explicação de estabilidade estática da AWS defende preparar o serviço para continuar quando uma dependência falha. Seu texto sobre tolerância e isolamento de falhas também trata do custo de reservar recursos antecipadamente. Essa reserva cobra capital antes da pane; a improvisação cobra tempo durante ela.

O relatório histórico não apresenta os limites atuais da frota nem um teste recente de reinicialização completa. Um teste com condições publicadas permitiria rever a avaliação da recuperação hoje. A lição comercial já tem endereço: na próxima compra, perguntar quanto trabalho cada servidor acrescenta aos antigos e com que rapidez a frota inteira pode voltar.