Nesta postagem, gostaríamos de compartilhar os detalhes da interrupção do serviço que ocorreu na Virgínia do Norte (US-EAST-1) em 25 de novembro de 2020.
O Amazon Kinesis coleta, processa e analisa dados de streaming em tempo real. Além do uso direto pelos clientes, ele está envolvido em vários serviços da AWS. Esses serviços também sofreram uma interrupção. O gatilho (mas não a razão principal) para esse evento foi a adição relativamente pequena de capacidade ao serviço, que começou às 2h44 PST e terminou às 3h47.
Sobre o dispositivo Kinesis
O Kinesis usa um grande número de clusters "back-end" de células (células) que processam fluxos de dados. Esses são os cavalos de batalha do Kinesis. Eles são responsáveis pela distribuição, acesso e escalonamento para streaming. Os fluxos são distribuídos por servidores front-end para servidores back-end usando sharding. O cluster de back-end "possui" muitos fragmentos e fornece dimensionamento consistente e isolamento de falhas. O trabalho de front-end em nosso caso é pequeno, mas importante. Ele é responsável por autenticar, controlar e rotear solicitações para os fragmentos de encadeamento corretos nos clusters de backend.
Estávamos adicionando novas capacidades à frota de máquinas front-end. Cada servidor front-end forma um cache de dados, incluindo membros e proprietários de shard (entre clusters de back-end), formando um chamado mapa de shard. Ele obtém essas informações enviando solicitações ao serviço que fornece informações de associação e recuperando dados de configuração do DynamoDB.
Além disso, cada servidor processa continuamente mensagens de outros servidores front-end Kinesis. Para fazer isso, threads são criados no sistema operacional de cada máquina front-end para cada um dos servidores front-end. Quando novas capacidades são adicionadas, os servidores que já estão operando no parque de front-end aprendem sobre os novos membros e criam os fluxos correspondentes. Cada servidor front-end existente leva até uma hora para saber sobre as novas máquinas.
Diagnóstico e resolução de problemas
Às 5:15 PST, as primeiras mensagens de erro apareceram durante a gravação e recuperação de registros do Kinesis. Nossas equipes imediatamente começaram a estudar os registros. A suspeita caiu imediatamente sobre as novas capacidades, mas alguns dos erros não estavam de forma alguma relacionados com as novas máquinas e, muito provavelmente, não teriam ido a lugar nenhum, mesmo se removêssemos todas as novas capacidades.
No entanto, por precaução, começamos mesmo assim a eliminá-los, tentando ao longo do caminho estabelecer a causa de outros erros. Sua grande variedade retardou nosso diagnóstico. Vimos bugs em todos os aspectos de todos os tipos de chamadas feitas por membros novos e existentes da frota de máquinas front-end, e isso tornou muito difícil separar os efeitos colaterais da causa raiz.
A partir das 7h51 PST, reduzimos os suspeitos a alguns candidatos e determinamos que qualquer uma das causas mais prováveis exigiria uma reinicialização completa do front-end. A equipe Kinesis sabia muito bem que esse processo deveria ser lento e detalhado.
O fato é que o preenchimento do shard card compete com o processamento das solicitações de entrada dos recursos do servidor front-end. Portanto, colocar os servidores front-end on-line novamente muito rapidamente criará um conflito entre os dois processos e deixará muito pouco para processar as solicitações de entrada. O resultado final é previsível: um aumento nas taxas de erro e um aumento nas latências. Além disso, servidores front-end lentos podem ser percebidos como um sinal de não integridade, o que pode fazer com que sejam removidos da lista de servidores disponíveis, o que, por sua vez, tornará ainda mais lento o processo de recuperação.
Todas as soluções possíveis envolviam alterar a configuração de cada servidor front-end e reiniciá-lo. Embora nosso principal candidato para a fonte de nossos problemas (um problema que parecia colocar pressão sobre a memória) parecesse promissor, se estivéssemos errados, arriscávamos dobrar o tempo de recuperação, já que teríamos que consertar e reiniciar tudo. Para acelerar o reinício, em paralelo com a investigação, começamos a fazer alterações na configuração dos servidores front-end, permitindo que você receba dados diretamente do repositório de metadados no momento da inicialização, e não dos vizinhos de front-end.
razão principal
Às 21h39 PST, finalmente pudemos confirmar a causa raiz da falha. Descobriu-se que não está relacionado à memória. A adição de novas capacidades resultou no número de threads em todos os servidores front-end excedendo o máximo possível, permitido pela configuração do sistema. Como o limite foi excedido, o cache (cartões de fragmentos) não pôde ser criado. Como resultado, os servidores front-end não conseguiram encaminhar solicitações aos clusters de back-end.
Não queríamos aumentar o limite de threads no SO sem testes preliminares e, como a capacidade adicional já havia sido removida naquele momento, decidimos que o risco de exceder o limite do sistema no número de threads era mínimo e continuamos a reiniciar os servidores. O primeiro grupo de novos front-ends começou a aceitar o tráfego do Kinesis às 10h07 PST.
A frota de front-end consiste em muitos milhares de servidores e, pelos motivos descritos acima, poderíamos adicionar servidores a uma taxa de não mais do que algumas centenas por hora. Continuamos a adicionar tráfego lentamente ao front-end, observando o declínio constante nos erros de serviço do Kinesis desde o meio-dia. O serviço se recuperou completamente às 22h23 PST.
O que aprendemos
Aprendemos várias lições com o incidente do Kinesis e estamos planejando fazer correções em um futuro próximo.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
A falha também afetou alguns serviços que usam o Kinesis.
O Amazon Cognito usa Kinesis Data Streams para coletar e analisar padrões de acesso de API. Embora essas informações sejam extremamente úteis para a operação do serviço Cognito, não há garantia de entrega (melhor esforço) . Os dados são armazenados em buffer localmente para ajudar o serviço a lidar com a latência ou curtos períodos de indisponibilidade no serviço Kinesis Data Streams.
Infelizmente, a indisponibilidade prolongada do Kinesis Data Streams revelou um bug latente no código de buffer que fez com que os servidores da Web Cognito começassem a bloquear os buffers do Kinesis Data Stream. Como resultado, os consumidores do Cognito enfrentaram travamentos de API e aumento da latência para os pools de usuários e identidades do Cognito. Os usuários externos não conseguiram autenticar ou obter credenciais temporárias da AWS.
Nos estágios iniciais da interrupção, a equipe do Cognito tentou mitigar o impacto dos bugs do Kinesis adicionando mais capacidade e, assim, aumentando os recursos de buffer de chamada do Kinesis. Inicialmente, isso teve um efeito positivo sobre o serviço, mas às 7:01 PST, a taxa de erros aumentou significativamente. Paralelamente, a equipe trabalhou para reduzir a dependência do Cognito do Kinesis. Às 10h15, essa solução foi implantada e a taxa de erros começou a diminuir. Às 12h15, o número de erros havia diminuído significativamente e, às 14h18 PST, o Cognito estava funcionando normalmente. Para evitar que esse problema ocorra novamente, modificamos os servidores da web Cognito. Eles agora podem tolerar erros da API do Kinesis sem esgotar seus buffers (levando a problemas do usuário).
CloudWatchusa Kinesis Data Streams para processar métricas e logs. Começando às 5:15 da manhã, o CloudWatch estava apresentando erros e latências crescentes para as APIs PutMetricData e PutLogEvents, e os alertas entraram no estado
INSUFFICIENT_DATA. Enquanto algumas métricas do CloudWatch continuaram a ser processadas durante a interrupção, a maioria delas foi vítima de vários erros e aumento da latência.
Às 17:47 PST, os primeiros sinais de recuperação apareceram conforme a situação do Kinesis Data Stream melhorava e, às 10:31 da noite, as métricas e alertas do CloudWatch haviam se recuperado totalmente. Nas horas seguintes, o processamento de métricas e registros atrasados continuou. Enquanto o CloudWatch estava lutando contra bugs, os clientes internos e externos não conseguiam fornecer dados de métricas para o CloudWatch. Como resultado, existem lacunas nos dados de métricas do CloudWatch.
No momento, o serviço CloudWatch conta com Kinesis para coletar métricas e logs, mas sua equipe implementará em breve uma mudança após a qual CloudWatch armazenará dados por três horas no armazenamento local. Essa mudança permitirá que usuários e serviços vinculados às métricas do CloudWatch (incluindo AutoScaling) acessem diretamente as métricas recém-coletadas (no datastore local do CloudWatch). Essa ideia já foi implementada na região US-EAST-1 e, nas próximas semanas, planejamos implementá-la globalmente.
Mais dois serviços tornaram-se reféns de problemas com as métricas do CloudWatch:
- Primeiro, as políticas de AutoScaling com base nas métricas do CloudWatch experimentaram latência até 17:47, o ponto em que o CloudWatch começou a se recuperar.
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
O CloudWatch Events e o EventBridge estavam experimentando um aumento nos erros de API e na latência no processamento de eventos a partir das 5h15 ET. Após melhorar a disponibilidade, o Kinesis EventBridge retomou a entrega de novos eventos aos destinatários, processando simultaneamente os eventos acumulados.
O Elastic Container Service (ECS) e o Elastic Kubernetes Service (EKS) usam EventBridge em seus fluxos de trabalho internos para gerenciar clusters e tarefas de cliente. Isso afetou o provisionamento de novos clusters, atrasou o dimensionamento dos existentes e afetou o desprovisionamento de tarefas. Às 16h15 PST, a maioria desses problemas havia sido resolvida.
Notificação do cliente
Além das dificuldades com os serviços, logo no início do incidente, encontramos alguns atrasos na comunicação de informações sobre o status dos serviços aos clientes.
Temos duas maneiras de nos comunicar com os clientes durante eventos operacionais:
- Service Health Dashboard - um painel publicamente disponível para alertar sobre grandes problemas operacionais;
- Painel de saúde pessoal - para notificação direta dos clientes afetados.
Durante eventos como este, geralmente postamos informações no Painel de Integridade do Serviço. No entanto, neste caso, logo no início da falha, não foi possível atualizar as informações no Painel de integridade do serviço, porque a ferramenta usada para publicar atualizações é usada pelo Cognito com falha.
Temos um método alternativo para atualizar o Painel de Integridade do Serviço com dependências de serviço mínimas. Funcionou como planejado, mas enfrentamos alguns atrasos ao publicar informações no Painel de Integridade do Serviço no início do evento. O ponto é que essa ferramenta de backup é muito menos automatizada e menos familiar para os operadores de helpdesk.
Para garantir a entrega oportuna de atualizações a todos os clientes afetados, a equipe de suporte aproveitou o Personal Health Dashboard para alertá-los sobre possíveis problemas de serviço. Também colocamos um banner global com informações atualizadas no Service Health Dashboard para garantir que os usuários sejam totalmente informados sobre o incidente. Até o final da falha, uma combinação do Service Health Dashboard (com resumos em banners globais e detalhes sobre a operação de serviços específicos) e Personal Health Dashboard, onde tentamos manter os clientes afetados por problemas com os serviços atualizados. Com base em nossa experiência, introduzimos exercícios obrigatórios com um sistema de fallback para postar mensagens no Painel de Integridade do Serviço em nosso treinamento regular de engenheiro de suporte.
...
Por fim, gostaria de pedir desculpas pelo impacto negativo que esse incidente teve sobre nossos clientes. Temos orgulho da alta disponibilidade do Amazon Kinesis e estamos bem cientes da importância deste e de outros serviços da AWS para nossos clientes, seus aplicativos / usuários finais e seus negócios. Faremos o nosso melhor para aprender com este incidente e usá-lo para melhorar ainda mais a acessibilidade.
PS
Leia também em nosso blog:
- « O Post Mortem da indisponibilidade Quay.io »;
- “ Histórias práticas dos nossos dias SRE. Parte 2 ";
- " Como as prioridades do pod no Kubernetes causaram tempo de inatividade no Grafana Labs ."