[Ed. Esta notícia foi adaptada e enriquecida pelo tradutor e pela equipe editorial do InfoQ Brasil]
A Amazon publicou relatório detalhado sobre a falha de serviço que atingiu uma zona de disponibilidade na Região EUA Leste, e diversos sites publicaram análises, comentários e lições a serem aprendidas com o ocorrido.
Para simplificar a leitura e o entendimento do texto a seguir, concentramos aqui a expansão das siglas utilizadas:
- AWS: Amazon Web Services
- EC2: Elastic Compute Cloud
- RDS: Relational Database Service
- EBS: Elastic Block Storage
- AZ: Availability Zone
Em uma linha do tempo da falha do Amazon EC2, Eric Kidd, do blog Random Hacks, expôs uma série de eventos importantes relacionados à interrupção do serviço AWS (da forma que foram percebidos externamente). Tudo começou em 21 de abril, quando a Heroku começou a investigar o grande número de erros que estavam sendo relatados no seu serviço. A interrupção durou quase quatro dias, até 24 de abril, quando a Amazon informou que todos os bancos de dados RDS tinham voltado a funcionar. Durante o período, os serviços da Heroku ficaram sem funcionar, ou funcionando intermitentemente, para alguns clientes.
O que na verdade aconteceu? A Amazon escreveu um relatório detalhado sobre a interrupção, oito dias após seu início. Como relatou a Amazon, tudo começou às 5h47min (horário de Brasília) de 21 de abril. Neste momento, "foi realizada uma mudança na rede, como parte de atividades normais de expansão do AWS, em uma única zona de disponibilidade da região EUA Leste". O objetivo foi "aumentar a capacidade da rede primária".
Esse procedimento exigia que o tráfego da rede fosse repassado para outro roteador da rede primária – mas por engano foi desviado para um roteador de outra rede, que tinha capacidade inferior. Esse roteador não conseguiu lidar com a carga adicional, por isso muitas unidades de armazenamento EBS foram completamente isoladas de outras pertencentes ao mesmo cluster da zona de disponibilidade afetada."
O tráfego foi rapidamente redirecionado para outro roteador mais apropriado, mas quando isso aconteceu muitas unidades EBS tentaram obter espaço no servidor para espelhar seus dados. A disputa por espaço livre logo esgotou o espaço no cluster, fazendo com que cerca de 13% dos volumes da zona de disponibilidade afetada ficassem "travados" ("stuck" foi o termo utilizado no relatório da Amazon).
Por causa disso, o cluster não conseguiu mais atender a novas requisições de "Criar volume" que chegavam ao plano de controle (control plane; responsável por gerenciar os clusters) através da API. Como essas solicitações têm um timeout longo, ocorreu starvation no pool de threads dedicado a servir requisições externas relacionadas a volumes. E como o plano de controle alcança várias zonas de disponibilidade na mesma região, o problema se propagou para outras zonas.
Dessa forma, mais unidades ficavam sem conseguir espaço livre para replicar seu conteúdo e também travavam, ampliando o problema durante as primeiras horas depois da falha. A equipe do AWS cortou a comunicação entre o cluster afetado e o plano de controle, para evitar que outros clusters da região também ficassem travados. Também foi feita uma correção que deixou os volumes afetados menos "famintos" por espaço para espelhamento.
A Amazon informou que a interrupção se restringiu a uma única zona de disponibilidade. Disse ainda que o cluster EBS afetado foi estabilizado por volta de 17:00 do mesmo dia (os horários foram ajustados para o horário de Brasília), e que clientes já conseguiam criar novas instâncias de EC2 baseadas em EBS, mas que ainda encontravam um grande número de erros. A prioridade naquele momento, segundo a Amazon, era "aumentar a capacidade de armazenamento, para que os volumes travados encontrassem espaço para criar suas novas réplicas."
A equipe do AWS começou, então, a adicionar capacidade de armazenamento, para evitar novos problemas de concorrência, e 97,8% dos volumes do cluster afetado foram completamente replicados nas 24 horas seguintes, deixando 2,2% dos volumes ainda travados. A comunicação entre o cluster e o plano de controle teve que ser restaurada, mas muitas operações tinham se acumulado na fila, exigindo mais 24 horas para concluí-las. Após outras 24h, se conseguiu restabelecer o funcionamento dos últimos 2,2% dos volumes travados. Restavam, portanto, "0,07% dos volumes da zona de disponibilidade afetada, que não puderam ser restaurados para os clientes em estado consistente."
Portanto, alguns dados foram perdidos. O relatório da Amazon não especifica a quantos gigabytes esses 0,07% correspondem. Alguns serviços RDS foram impactados pelo cluster problemático, e foram restaurados durante o fim de semana. Entretanto, 0,4% das instâncias de banco de dados "single A-Z" (baseadas em uma única zona de disponibilidade) não puderam ser recuperadas, porque dependiam de dados que foram perdidos.
A Amazon disse que vai incorporar aos seus sistemas algumas lições aprendidas (incluindo aumentar a capacidade de armazenamento), para evitar acontecimentos semelhantes no futuro:
Faremos várias mudanças para evitar que um cluster volte a entrar em uma tempestade de reespelhamento. Se o cluster degradado tivesse mais folga na capacidade de armazenamento, teria absorvido mais rapidamente o grande número de requisições de reespelhamento, o que evitaria o problema. Agora sabemos qual é a capacidade necessária para grandes eventos de recuperação. Além disso, nosso planejamento de capacidade e de alerta será modificado, para atingir a margem de segurança necessária em situações de falha em grande escala. Já aumentamos significativamente a capacidade adicional e esperamos disponibilizar, dentro de poucas semanas, a nova capacidade necessária.
A empresa também informou que tornará mais fácil para os clientes o uso de diferentes zonas de disponibilidade, de modo a evitar falhas. Mas recomenda o uso simultâneo de regiões diferentes, que é a melhor forma de oferecer serviço ininterrupto, pois as regiões são completamente separadas e independentes entre si.
A empresa vai oferecer a todos os clientes afetados um "crédito de 10 dias, equivalente a 100% do uso dos volumes EBS, instâncias EC2 e bancos de dados RDS que estavam executando na zona de disponibilidade afetada". O relatório termina com um pedido de desculpas a todos os clientes do AWS.
A imprensa foi inundada com notícias relacionadas ao primeiro apagão da nuvem. Jason Bloomberg sintetizou algumas lições:
- Não existe 100% de confiabilidade. Nada em TI é 100% – nenhum código é 100% livre de bugs, nenhum sistema é 100% à prova de falhas, e nenhum esquema de segurança é 100% garantido. Só porque uma falta de sorte atingiu a Amazon dessa vez, isso não significa que as nuvens públicas sejam menos confiáveis do que eram antes da crise. Seja investindo no mercado de ações, ou construindo uma infraestrutura de TI de alta disponibilidade, a melhor forma de diminuir o risco é diversificar.
- É improvável que esta crise em particular se repita. Podemos dar como certo que a Amazon tem ótimos especialistas em computação em nuvem, e que já construíram uma arquitetura que pode resistir à maioria dos desafios. Esta crise teve um conjunto de causas incomum e complexo, mas os especialistas estão trabalhando intensamente para erradicar essas causas, de forma que este conjunto de circunstâncias específico não aconteça novamente.
- Incógnitas não conhecidas são, por definição, imprevisíveis. Mesmo que nuca se repita a sequência específica de eventos que levaram à atual crise, é relativamente provável que outros problemas totalmente imprevisíveis surjam. Mas tais problemas podem muito bem acontecer em nuvens privadas, híbridas ou comunitárias, assim como podem ocorrer novamente na nuvem pública. Em outras palavras, sair das nuvens públicas para se refugiar em nuvens privadas, supostamente mais seguras, é um exercício de futilidade.
- A lição que fica para a Amazon tem mais a ver com visibilidade do que com confiabilidade. A parte mais fraca dos serviços em nuvem oferecidos pela Amazon é a falta de visibilidade para os clientes. O estilo "não importa quem está atrás da cortina" é parte do modo como a Amazon suporta a abstração da nuvem. Mas nesse momento isso está se voltando contra a empresa e seus clientes. Para aproveitar melhor seu sucesso, a Amazon deve abrir um pouco o quimono, e oferecer a seus clientes um nível de visibilidade da infraestrutura interna maior do que ofereceu até aqui.
A RightScale também apresentou em seu blog uma análise da interrupção no Amazon EC2, com lições aprendidas e observações incisivas sobre a falta de comunicação apropriada por parte da empresa durante a falha:
- Não espere 40 minutos para divulgar a primeira mensagem de status.
- Não diga "uma pequena porcentagem de instâncias/volumes/..."; forneça as porcentagens reais. É importante, para quem contrata muitos servidores/volumes, saber se os problemas ocorreram em 1% ou em 25% deles, pois serão tomadas providências diferentes em cada caso.
- Não fale na "zona de disponibilidade afetada" ou "várias zonas de disponibilidade"; dê nome às zonas e se refira a elas por nome (sabemos que a zona '1a' de cada conta se refere a uma zona física diferente; por isso dê a cada zona um segundo nome para que se possa identificá-la).
- Ofereça informação de status individualizada. Use email (ou outros meios) para informar qual é o status das nossas instâncias e volumes. Não se trata de coisas que se pode obter sozinho, como carga da CPU, mas informações como "os seguintes volumes (por id) estão se recuperando no momento, e devem estar disponíveis em uma hora; tais volumes vão requerer intervenção manual posteriormente etc." Isso permite que os usuários planejem e escolham onde aplicar seus esforços durante o período de falha.
- Faça previsões. Vimos volumes da "zona de disponibilidade afetada" serem removidos muitas horas depois do evento inicial. Certamente vocês sabiam que o problema ainda estava se espalhando e podiam ter alertado a todos, dizendo algo como: "recomendamos que movam todos os servidores e volumes que ainda estão operando na zona de disponibilidade afetada, para uma zona ou região diferente, pois o problema ainda está se espalhando."
- Forneça uma visão geral. Cada atualização de status deveria listar quais funções ainda estão com problema e quais foram corrigidas. Não faça com que todos tenham que reler suas mensagens para deduzir qual é o situação atual de cada função.
- É mesmo tão difícil escrever uma atualização no blog com desculpas e alguma informação, ainda que preliminar? As contas de Twitter do AWS, que normalmente enviam múltiplos tweets por dia, ficaram em silêncio. Certamente havia alguma coisa a ser dita cerca de 24 horas depois do evento. Não seria melhor orientar as pessoas sobre o que pensar, em vez de deixar que tirem suas próprias conclusões?
O blog High Scalability compilou uma longa lista dos artigos mais importantes relacionados ao problema da Amazon e a experiência de algumas empresas, além de links para fóruns sobre o assunto, de quem foi a culpa (se da Amazon ou dos clientes), e lições aprendidas.
Este evento grave, que afetou o maior provedor mundial de serviços de cloud computing e os seus clientes, certamente nos fará pensar duas vezes antes de migrar para a nuvem. Também dá uma importante lição à indústria sobre o quanto podem ser frágeis nossos sistemas, mesmo os melhor projetados. Além disso, mostra mais uma vez – se é que isso era necessário – que a luta por tolerância a falhas e alta disponibilidade ainda não acabou, e nunca vai acabar.