AWS: Aqui está o que deu errado em nossa grande paralisação de computação em nuvem

A AWS pede desculpas por uma longa paralisação depois de tropeçar na tradução de endereços entre as principais e internas redes.

O Amazon Web Services (AWS) raramente cai inesperadamente, mas você pode esperar um explicador detalhado quando uma grande paralisação acontece.

A última das principais paralisações da AWS ocorreu às 7:30 AM PST na terça-feira, 7 de dezembro, durou cinco horas e afetou os clientes usando certas interfaces de aplicativos na Região EUA-LESTE-1. Em uma nuvem pública da escala da AWS, uma paralisação de cinco horas é um grande incidente.

De acordo com a explicação da AWS sobre o que deu errado,a fonte da paralisação foi uma falha em sua rede interna que hospeda “serviços fundamentais” como monitoramento de aplicativos/serviços, DNS (Domain Name Service, serviço de nomes de domínio) interno da AWS, autorização e partes do plano de controle de rede Elastic Cloud 2 (EC2). O DNS foi importante neste caso, pois é o sistema usado para traduzir nomes de domínio legívels por humanos para endereços de INTERNET numérica (IP).

A rede interna da AWS sustenta partes da principal rede AWS com a quais a maioria dos clientes se conectam para fornecer seus serviços de conteúdo. Normalmente, quando a rede principal se dimensiona para atender a um aumento na demanda de recursos, a rede interna deve aumentar proporcionalmente através de dispositivos de rede que lidam com a tradução de endereços de rede (NAT) entre as duas redes.

No entanto, na terça-feira da semana passada, o dimensionamento de redes cruzadas não correu bem, com os dispositivos AWS NAT na rede interna ficando “sobrecarregados”, bloqueando mensagens de tradução entre as redes com efeitos graves de impacto para vários serviços voltados para o cliente que, tecnicamente, não foram diretamente impactados.

“Às 7:30 AM PST, uma atividade automatizada para dimensionar a capacidade de um dos serviços AWS hospedados na rede principal da AWS desencadeou um comportamento inesperado de um grande número de clientes dentro da rede interna”, diz a AWS em sua post mortem.

“Isso resultou em uma grande onda de atividade de conexão que sobrecarregou os dispositivos de rede entre a rede interna e a rede principal da AWS, resultando em atrasos na comunicação entre essas redes.”

Os atrasos estimularam a latência e os erros de serviços fundamentais falando entre as redes, desencadeando tentativas de conexão ainda mais fracassadas que, em última análise, levaram a “persistentes problemas de congestionamento e desempenho” nos dispositivos de rede interna.

Com a conexão entre as duas redes bloqueada, a equipe operacional interna da AWS rapidamente perdeu visibilidade em seus serviços de monitoramento em tempo real e foi forçada a contar com registros de eventos passados para descobrir a causa do congestionamento. Depois de identificar um pico de erros internos de DNS, as equipes desviaram o tráfego interno de DNS para longe de caminhos bloqueados. Este trabalho foi concluído duas horas após a paralisação inicial às 9:28 AM PST.

Isso aliviou o impacto nos serviços voltados ao cliente, mas não corrigiu totalmente os serviços AWS afetados ou desbloqueou o congestionamento do dispositivo NAT. Além disso, a equipe de operações internas da AWS ainda não tinha dados de monitoramento em tempo real, retardando posteriormente a recuperação e a restauração.

Além da falta de visibilidade em tempo real, os sistemas de implantação interna da AWS foram dificultados, retardando novamente a remediação. A terceira principal causa de sua resposta não ideal foi a preocupação de que uma correção para comunicações de rede internas para principais interromperia outros serviços AWS voltados para o cliente que não foram afetados.

“Como muitos serviços AWS na rede principal da AWS e aplicativos de clientes AWS ainda estavam operando normalmente, queríamos ser extremamente deliberados enquanto fazíamos alterações para evitar o impacto das cargas de trabalho em funcionamento”, disse a AWS.

ENTÃO, QUAIS SERVIÇOS DE CLIENTES DA AWS FORAM IMPACTADOS?

Primeiro, a principal rede AWS não foi afetada, então as cargas de trabalho dos clientes da AWS “não foram diretamente impactadas”, diz a AWS. Em vez disso, os clientes foram afetados por serviços da AWS que dependem de sua rede interna.

No entanto, os efeitos de impacto da falha interna da rede foram de longe para os serviços AWS voltados para o cliente, afetando desde serviços de computação, distribuição de contêineres e conteúdo até bancos de dados, virtualização de desktop e ferramentas de otimização de rede.

Os planos de controle AWS são usados para criar e gerenciar recursos AWS. Esses aviões de controle foram afetados por estarem hospedados na rede interna. Assim, enquanto as instâncias EC2 não foram afetadas, as APIs EC2 que os clientes usam para lançar novas instâncias de EC2 foram. Taxas de latência e erro mais altas foram os primeiros impactos que os clientes viram às 7:30 AM PST.

Com esse recurso perdido, os clientes tiveram problemas com o Amazon RDS (serviços de banco de dados relacional) e com a plataforma de big data Amazon EMR, enquanto os clientes com o serviço de virtualização gerenciada de desktop da Amazon Workspaces não puderam criar novos recursos.

Da mesma forma, os Balancers de Nuvem Elástico (ELB) da AWS não foram diretamente afetados, mas, como as APIs do ELB foram, os clientes não puderam adicionar novas instâncias aos ELBs existentes tão rapidamente quanto de costume.

As APIs da Rota 53 (CDN) também foram prejudicadas por cinco horas, impedindo que os clientes alterassem as entradas de DNS. Houve também falhas de login no Console AWS, latência afetando o Amazon Secure Token Services para serviços de identidade de terceiros, atrasos no CloudWatch e acesso prejudicado aos baldes Amazon S3, tabelas DynamoDB via VPC Endpoints e problemas na invocação de funções lambda sem servidor.

O incidente de 7 de dezembro compartilhou pelo menos uma característica com uma grande paralisação que ocorreu nesta época do ano passado: impediu a AWS de se comunicar rapidamente com os clientes sobre o incidente através do Painel de Saúde do Serviço AWS.

“O prejuízo aos nossos sistemas de monitoramento atrasou nossa compreensão deste evento, e o congestionamento da rede prejudicou nossa ferramenta do Service Health Dashboard de falhar adequadamente em nossa região de espera”, explicou a AWS.

Além disso, a central de contato de suporte da AWS conta com a rede interna da AWS, para que a equipe não pudesse criar novos casos em velocidade normal durante a interrupção de cinco horas.

A AWS diz que lançará uma nova versão de seu Service Health Dashboard no início de 2022, que será executado em várias regiões para “garantir que não tenhamos atrasos na comunicação com os clientes”.

Paralisações de nuvens acontecem. O Google Cloud teve sua participação nas tarifas e a Microsoft em outubro teve que explicar sua paralisação de oito horas. Embora raras, as paralisações são um lembrete de que a nuvem pública pode ser mais confiável do que os data centers convencionais, mas as coisas dão errado, às vezes catastroficamente, e podem impactar um grande número de serviços críticos.

“Finalmente, queremos pedir desculpas pelo impacto que esse evento causou aos nossos clientes”, disse a AWS. “Embora estejamos orgulhosos de nosso histórico de disponibilidade, sabemos o quão críticos nossos serviços são para nossos clientes, seus aplicativos e usuários finais e seus negócios. Sabemos que esse evento impactou muitos clientes de forma significativa. Faremos tudo o que pudermos para aprender com este evento e usá-lo para melhorar ainda mais nossa disponibilidade.”