Outage da Amazon no Brasil separa o joio do trigo

Hoje, 18 de dezembro de 2013, uma das availability zones (AZ, ou datacenter) da Amazon Web Services (AWS) no Brasil ficou fora do ar. Na realidade, no momento da escrita deste post o problema persistia. Os principais serviços de processamento (EC2, RDS, ELB) ficaram indisponíveis no datacenter de São Paulo. Segundo a AWS, problemas de conectividade, conforme mostra a imagem a seguir, extraída as 09:00 AM (horário de Brasília) do service health dashboard.

AWS health dashboard

Pessoas me ligaram perguntando o que havia acontecido, mensagens foram postadas em foruns, todos desesperados porque seus sistemas estavam fora do ar. Isto mostra que a oferta da Amazon no Brasil não é confiável? Não, muito antes pelo contrário. Para todos eu expliquei a mesma coisa: A AWS trabalha com, no mínimo, 2 datacenters (as Availability Zones) em cada região, cada uma com rede de energia e dados independentes, justamente porque estas coisas podem acontecer. Os sistemas dos usuários da AWS terem ficado fora do ar mostra que suas infraestruturas não foram pensadas para a nuvem.

E é aí que separamos o joio do trigo. Ou seja, é aí que vemos quem simplesmente transferiu sua infraestrutura para a nuvem da Amazon e quem fez, efetivamente, uma migração para a AWS. Uma arquitetura montada para a nuvem deve prever que falhas ocorrerão e ser capaz de se recuperar sozinha, automaticamente, nestes casos. Apenas é necessário saber o que e como fazer. Existem ferramentas e serviços da própria AWS, tais como o Elastic Load Balancer (ELB) e o auto scaling, que servem para que sejam montadas arquiteturas resilientes, altamente disponíveis. Na figura abaixo apresento uma arquitetura de uma aplicação web simples, mas que suporta tranquilamente outage de uma AZ, ou seja, garante a alta disponibilidade da aplicação.

Arquitetura AWS com alta disponibilidade

Todo o tráfego entra para o ELB, o balanceador de carga. Este encaminha o tráfego para a(s) instância(s) EC2 que estiver(em) no ar e saudáveis (de tempos em tempos o ELB faz uma espécie de ping para ver se a instância responde e só manda tráfego real se ela estiver respondendo). Estas instâncias fazem parte de um auto scaling group, que é configurado para, por exemplo, ter sempre no mínimo 1 instância abaixo do ELB e que pode subir instâncias em qualquer uma das AZs da região. Caso a instância não esteja respondendo ao ELB, o auto scaling “mata” esta instância e sobe outra, possivelmente em uma AZ diferente, e que provavelmente estará funcionando. E, com isso, a aplicação não ficará fora do ar.

Do lado do banco de dados, o serviço de relational database service (RDS) da Amazon permite que se trabalhe com multi-AZ (exceto o SQL Server), o que faz com que o banco de dados rode no modelo master-slave, sendo que o master está em uma AZ e o slave, sincronizado em tempo real, em outra AZ. O slave fica em stand-by e, caso o master caia, ele assume como master.

Tudo isso tem um custo? Sim, mas certamente é menor do que o sistema ficar fora do ar.

Curiosamente, nenhum dos nossos clientes telefonou dizendo que sua infraestrutura estava inacessível ou fora do ar :-).