- A AWS relatou problemas operacionais desde a noite de quinta-feira, e a falha ligada ao superaquecimento de um data center na região US-East-1 do Norte da Virgínia afetou plataformas de negociação como Coinbase e FanDuel
- Em uma atualização às 15h29 de sexta-feira (ET), a AWS informou que ainda esperava que a recuperação completa levasse várias horas, e que o trabalho de restauração estava mais lento do que o previsto anteriormente
- A AWS explicou que o problema ocorreu em uma Availability Zone única daquela região e que estava colocando capacidade adicional do sistema de resfriamento em operação para recuperar o hardware restante
- A FanDuel afirmou que, depois de investigar dificuldades técnicas que impediam os usuários de acessar a plataforma, concluiu que isso estava ligado à falha mais ampla da AWS, e usuários reclamaram de perdas em apostas por não conseguirem fazer cash out
- A Coinbase afirmou que falhas em várias zonas da AWS causaram uma longa interrupção nos serviços principais de negociação e publicou que os principais problemas foram totalmente resolvidos
Progresso da recuperação
- Em uma atualização às 9h51 de sexta-feira (ET), a AWS informou: “Estamos trabalhando ativamente para colocar capacidade adicional do sistema de resfriamento em operação, o que nos permitirá recuperar o hardware restante na área afetada”
- A AWS está resolvendo falhas em instâncias EC2 que fornecem capacidade de servidores virtuais
- O painel AWS Health publicou pela primeira vez às 20h25 de quinta-feira (ET) que estava “investigando falhas de instâncias”
- A AWS não fez comentários adicionais
Impacto por serviço
- A FanDuel informou no X às 21h de quinta-feira (ET) que estava ciente das dificuldades técnicas atuais que impediam os usuários de acessar a plataforma e que estava investigando
- Cerca de duas horas depois, a FanDuel atualizou que o problema estava ligado à falha mais ampla da AWS
- Usuários da FanDuel reclamaram de perdas em apostas por não conseguirem fazer cash out na plataforma
- A Coinbase também publicou no X na sexta-feira que falhas em várias zonas da AWS causaram uma “longa interrupção nos serviços principais de negociação”
- A Coinbase afirmou nessa publicação que os principais problemas foram totalmente resolvidos
Contexto do mercado de nuvem
- A AWS responde por cerca de um terço do mercado de tecnologia de infraestrutura em nuvem
- A AWS atende milhões de empresas
1 comentários
Comentários do Hacker News
AWS US-East 1 continua sendo o calcanhar de Aquiles da internet
Dá para construir em várias regiões e zonas de disponibilidade, mas a AWS já repetiu incidentes em que problemas no US-East 1 têm impacto mais amplo, o que faz a redundância e a resiliência não serem tão altas quanto a AWS dá a entender
Todos os serviços públicos de identidade e acesso fora da China, ou seja, o que os funcionários chamam de “IAM para a partição aws”, são centralizados em us-east-1. Para ver contas, faturamento e permissões de forma consistente, esse tipo de centralização é praticamente necessário
O IAM também não é uma stack de software totalmente independente e depende de alguns serviços como DynamoDB, e esses serviços por sua vez têm dependência circular do IAM
Durante falhas em us-east-1, às vezes ainda dá para continuar usando tokens ou sessões de autenticação já existentes em outras regiões, mas pode não ser possível emitir novos tokens. Lembro que, em um trabalho anterior, dizíamos ao pessoal de plantão para não fechar a sessão SSH nem a aba do navegador com o console da AWS, porque eles poderiam ficar bloqueados até o incidente terminar
Nos últimos 3 anos, rodei uma startup quase inteira em use-1 e só tivemos uma falha regional, e mesmo assim foi parcial, então a maioria das instâncias nem foi afetada
Sinceramente, como o ambiente dos clientes também está todo em use-1, existe a vantagem de a falha ter correlação com os clientes
No reino mágico da fantasia, a carga fica bem distribuída entre vários provedores de nuvem e não existe ponto único de falha
Também teria dado certo com minha primeira namorada, meus gêmeos seriam fluentes em inglês e coreano, e eu saberia que não dá para depender só da AWS quando se faz deploy de um serviço grande
E eu conseguiria pagar o custo da saúde nos EUA. Mas na realidade passou mais um dia, e um único AWS US-East 1 conseguiu derrubar boa parte da internet
Com 2 regiões, você precisa de 2x a capacidade; com 3 regiões, 1,5x; e numa configuração multi-região as máquinas já precisam estar rodando. Não dá para contar que você vai conseguir subir instâncias ou garantir capacidade durante a falha, e ainda é preciso lidar com a complexidade extra da hospedagem multi-região
É meio engraçado ver todo mundo acreditar nisso como se fosse um credo da religião da nuvem, mesmo quando a configuração com várias regiões/zonas de disponibilidade parece tão obviamente cosmética
Esse tipo de aposta é arriscado. Porque alguém como um funcionário que consegue derrubar a AWS pode apostar
Essas apostas não são tão inofensivas quanto parecem, porque muitas vezes quem aposta também pode influenciar ou mudar o resultado
No geral, concordo com a ideia de que esse tipo de mercado preditivo pode incentivar insider trading e cenários negativos. Surge um incentivo para lucrar explorando essas situações
O resfriamento de datacenter costuma ser quase todo planejado com antecedência, e eu achava que não se instalava mais do que o que dá para resfriar
Aqui fico curioso se o que falhou foi o equipamento de resfriamento, se houve alguma causa externa para o superaquecimento, ou se a Amazon faz overbooking da capacidade de resfriamento do datacenter
Não nos explicaram a causa exata, mas parece que a tubulação entre os andares e o telhado não era redundante, e o conserto levou quase 24 horas
Resfriamento de datacenter, como todo o resto, tem ao mesmo tempo superprovisionamento e subprovisionamento
Equipamentos grandes de troca térmica costumam ser N+1 e, em instalações menores com cargas muito críticas, chegam a 2N/3N, então há superprovisionamento. Isso porque precisam ser desligados para manutenção periódica, falham mais do que componentes tradicionais de datacenter e exigem reparos mecânicos por especialistas, com peças de reposição de prazo longo
Em instalações grandes, à medida que N cresce, não é raro o resfriamento ser N+3 ou mais. Sempre há alguma coisa em manutenção, ou algum equipamento esperando peça porque sai mais barato fabricar sob medida no torno um componente que nem existe mais do que trocar a máquina inteira
Por outro lado, se toda a capacidade computacional da instalação sair de repente do consumo médio para 100%, a capacidade de resfriamento será excedida, então também existe subprovisionamento. A parte elétrica e outros caminhos também costumam operar acima da carga ideal; a essência do setor é quase uma forma de overselling
Normalmente isso não vira um grande problema. É raro a carga computacional disparar até 100% da capacidade total e, mesmo quando sobe, não fica lá por muito tempo, e ninguém projeta uma instalação com resfriamento ou energia no fio da navalha
O problema aparece quando vários eventos se cruzam. O sistema de resfriamento é projetado para suportar 200% da carga média, dando boa margem para manutenção e falhas
Na terça-feira, um técnico vai olhar um equipamento e descobre um rolamento ruim; precisa buscar a peça em outro estado e, para evitar o risco de estragar o conjunto do ventilador, mantém o equipamento desligado durante a noite
Duas unidades de resfriamento vizinhas passam a trabalhar um pouco mais forte, e uma delas tinha um motor levemente desbalanceado ou um fusível frouxo aquecendo; uma peça que vinha aguentando há anos estoura por causa do aumento no ciclo de trabalho
Agora, numa instalação N+2, duas unidades estão fora, mas ainda não é crítico porque o projeto considerava 200% da carga média
Se uma terceira unidade do lado oposto da primeira também revelar um defeito sob a carga maior, agora são três unidades fora em uma instalação N+2. Ainda assim, como o projeto era para 200% da carga média, ainda não é uma catástrofe total
Só que são 4 da manhã, o operador local não consegue consertar isso, e o fornecedor só acorda às 7 e chega às 9. Nesse meio-tempo, a carga começa a subir
Isso acontece todos os dias em algum datacenter dos EUA e provavelmente acontece pelo menos uma vez por ano em todo datacenter
O que vira notícia é a convergência com o próximo evento. Um grande cliente decide que agora é uma boa hora para começar um processamento em lote enorme. Alguma fintech roda um modelo grande antes da abertura do mercado, ou uma petroleira faz uma análise rápida de um novo campo
Sobem 10.000 VMs novas. Em condições normais, tudo bem, porque haveria capacidade de sobra
Mas o resfriamento foi planejado só para 200% da capacidade média, e esse nó não está fazendo uma carga moderada qualquer, e sim computação numérica intensiva otimizada, puxando potência máxima e gerando o máximo de calor residual
Não é só a carga em número de máquinas que aumenta, mas também o impacto no calor residual médio. Aí começa a falha em cascata e o resfriamento cai para N-4
Os ventiladores dos servidores começam a girar mais rápido e consumir mais energia, o resfriamento cai para N-5. Alarmes tocam por todos os lados
As proteções das unidades de resfriamento começam a atuar uma após a outra com o aumento da carga e da pressão do refrigerante, e o resfriamento vai para N-6, N-7 e depois 0
Fico curioso se, neste ano, na UE a Hetzner teve uptime melhor que a AWS
Acho a interface da Hetzner confusa demais para administrar
Post relacionado: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
É sempre East 1. Brincadeiras à parte, não entendo por que east-1 cai com tanta frequência em comparação com outras regiões
Em termos de arquitetura, parece que deveria ser bem parecido com as outras regiões
Deve ter mais carga que as outras regiões e, como foi construído primeiro quando havia menos experiência, imagino que também tenha mais dívida técnica e dívida de arquitetura/engenharia
Pelo que lembro, também existem serviços que dependem de east-1 como ponto único de falha, como o IAM e algumas configurações do S3
A Coinbase disse que várias zonas de disponibilidade caíram, mas o comunicado da AWS dizia que só uma única zona de disponibilidade foi afetada
Fico curioso se alguém sabe mais detalhes
Eu opero sistemas em us-east-1 e, durante o incidente, vi problemas intermitentes de conexão difíceis de explicar e que eu nunca tinha visto antes, inclusive fora da az4
Em alguns de vários ambientes, só houve uma leve degradação nos volumes EBS de uma única zona de disponibilidade, então foi claramente um problema de uma única zona de disponibilidade (use-az4)
Da última vez vi a frase “amigo de verdade não deixa amigo usar USE1”, e quando apareceu no Slack a mensagem de que USE1 e tudo que tinha sido implantado lá estava quebrado, lembrei disso
Há muitos comentários aqui repetindo a história conhecida de que us-east-1 é centralizado, é o ponto único de falha da AWS, precisa ser consertado e ninguém deveria colocar nada lá
O que aconteceu desta vez foi um problema em um datacenter dentro de uma zona de uma região multi-AZ
IAM, R53 etc. são centralizados lá, e seria bom descentralizar esses serviços e reorganizá-los entre regiões. Mas us-east-1 em si já é uma região multi-AZ com 6 zonas, e uma sétima prevista para 2026, e dentro das zonas também existem vários datacenters
Pelo que lembro, quando serviços globais como IAM caem, muitas vezes o problema não é “se fosse cross-region não teria caído”, mas sim bug de implementação ou de dependência
Desta vez não foi uma falha de serviços globais da AWS. O que parece ter sofrido impacto maior foi o MSK, e isso provavelmente tem mais a ver com Kafka do que com a AWS
Fico pensando por que não constroem essas coisas perto do mar. Imagino que isso também valha para instalações que precisam de muita capacidade de resfriamento, como usinas nucleares
Parece que daria para remover calor com uma circulação de 2 circuitos usando trocadores de calor
Nos anos 1990, cerca de metade do tráfego mundial da internet passava pelo MAE-East, e por isso a AWS colocou sua primeira região ali. us-east-1 surgiu 2 anos antes de eu-west-1 e 3 anos antes de us-west-1
Como havia muita gente que sabia construir datacenters e muitos fornecedores capazes de atendê-los, o Dulles Corridor virou um grande hub de datacenters de várias empresas
Na AWS, us-east-1 foi a primeira região, então é de longe a mais complexa e estranha, e muitos control planes de outros serviços da AWS passaram a depender dela. Por isso ela cai mais que outras regiões e, quando cai, vira notícia nacional, ao contrário de eu-south-2 na Espanha
NoVA não é um caso de fábrica, mas de datacenter; é o mesmo tipo de cluster econômico estudado por Paul Krugman no trabalho pelo qual ele ganhou o Nobel de Economia
Uma foi quando o datacenter da Hosting.com em SOMA ficou tão quente que jogaram água no telhado com mangueiras para resfriá-lo, e a outra foi quando o datacenter da Alibaba em Chai Wan ficou tão quente que tudo o que rodava lá caiu, incluindo o control plane
Então não acho que ficar perto do mar traga vantagem extra em termos de dissipação térmica de emergência. A capacidade de jogar calor para fora é finita e, esteja você na costa ou no meio de Nebraska, o sistema inteiro precisa ser projetado para atender a um certo nível de desempenho
Nos slides havia vários fatores que influenciam a escolha da localização de um datacenter, incluindo disponibilidade de espaço suficiente e de mão de obra qualificada para trabalhar ali. Ele também dizia que às vezes a política interfere na escolha do próximo local
Terreno litorâneo é muito mais caro, e se for para uma costa remota talvez o acesso à energia não seja bom
Locais costeiros também costumam estar expostos a eventos climáticos mais severos
E há imprevistos. A usina nuclear de Diablo Canyon teve problema de bloqueio da captação de água do mar para resfriamento por causa de detritos e de cardumes de águas-vivas
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
A água também precisa ser suficientemente profunda; caso contrário, ela esquenta até a temperatura da superfície. E ainda precisa competir em custo com o resfriamento evaporativo tradicional
O exemplo clássico em que isso funciona bem é Toronto. Há um lago de água doce profundo relativamente perto da costa, e o centro da cidade tem imóveis caros, o que atrapalha soluções tradicionais
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System