Outra interrupção no Amazon Web Services (AWS) afetou vários sites de grande porte na última semana. O que pode ser feito para evitar indisponibilidades dessa natureza? Uma solução, segundo vários especialistas, é conceber uma arquitetura visando tolerância a falhas e não apenas escalabilidade.
De acordo com o AWS Service Health Dashboard (um painel de controle para monitoramento de disponibilidade), vários serviços de nuvem da Amazon -EC2, EMR, RDS, Elastic Beanstalk - providos pela região de disponibilidade do Leste dos EUA, ficaram indisponíveis de 29 a 30 de junho, por cerca de 20 horas. A queda afetou empresas e seus serviços na web, incluindo NetFlix, Instagram, Pinterest e Heroku. Segundo relatório da Amazon, o principal culpado foi um incidente elétrico disparado por uma grande tempestade na sexta-feira à noite, que matou 13 pessoas, deixando 3 milhões sem energia.
Além de flutuações na rede elétrica, um grande pico de tensão atingiu dois datacenters forçando-os a chavearem para um gerador de energia. Mas um deles falhou neste processo. A falha levou à falta de energia no referido datacenter quando os no-breaks que sustentavam os servidores se esgotaram. O fornecimento de energia elétrica foi logo restaurado, mas reestabelecer os serviços aos seus níveis totalmente operacionais levou muito mais tempo.
Mike Kavis, Vice-Presidente de Arquitetura na Inmar, explicou o motivo pelo qual o reestabelecimento demorou tanto:
As fontes de energia de reserva entraram em ação, mas nem todos os recursos computacionais conseguiram se recuperar bem da falha. Como impacto, um subconjunto de servidores virtuais foram postos offline por certo tempo, até que os serviços AWS pudessem restaurá-los. A maneira como um cliente lida com esses casos determina se suas aplicações caem ou resistem a problemas. Muitos sites caíram.
Analisar tais eventos é importante para entender o que é necessário para evitar indisponibilidades. Kavis afirmou em um post após o incidente que sua empresa passou por cinco indisponibilidades dos serviços AWS desde 2009, mas que seus serviços nunca ficaram indisponíveis. A explicação: o uso de múltiplas zonas e regiões.
A Amazon tem um SLA (Acordo de Nível de Serviço) de 99.95% para cada zona dentro de cada região. A empresa nunca apresentou uma indisponibilidade em múltiplas zonas dentro de uma região, nem em múltiplas regiões ao mesmo tempo. Assim, essencialmente, a Amazon tem fornecido 100% de disponibilidade e cabe a nós projetar sistemas de modo a tirarem proveito de múltiplas zonas e regiões.
Sabemos que todos os servidores e todos os serviços em nossa plataforma irão falhar em algum momento, então arquitetamos maneiras de continuar o processamento de transações em recursos redundantes em múltiplas zonas. Em outras palavras, sabemos que zonas dentro de regiões irão falhar e preparamos nossa plataforma para não ficar dependentes de uma única zona.
Mas apenas usar múltiplas zonas não é suficiente, afirma Kavis:
Um padrão que se repete nessas interrupções é que o RDS do AWS, um serviço para automatizar os processos de administração de banco de dados, parece sempre ficar indisponível quando a Amazon tem problemas.
O fato de que gerenciamos manualmente nossas bases MySQL tem sido uma das muitas razões pelas quais temos ficado operantes durante tais interrupções. Se houvesse dependências do RDS, talvez não tivéssemos tido tanta sorte. Isso significa que os clientes dos serviços AWS não deveriam usar o RDS? Não. Ainda se pode utilizar o serviço para certas funcionalidades que não requeiram um Acordo de Nível de Serviço extremamente alto, nem precisem de conectividade em tempo real com sistemas de pontos de vendas.
Kavis observou que algumas das empresas atingidas pela interrupção nos serviços AWS da última semana possuem "algumas das arquiteturas mais impressionantes e avançadas já vistas em ambientes de larga escala". Mas elas trocaram disponibilidade por escalabilidade:
Um site gratuito de mídia social que não tem SLAs para cumprir talvez escolha investir mais tempo em escalabilidade para lidar com milhões de usuários concorrentes, arriscando ficar indisponível por uma ou duas horas. Talvez seja um melhor investimento, nesse caso, preparar-se para lidar com picos de tráfego do que se concentrarem nos raros eventos de interrupções dos serviços AWS.
A conclusão a que se pode chegar é que, se for exigido estar sempre disponível, é preciso que a arquitetura contemple não apenas escalabilidade, mas também a tolerância a falhas.