Fala pessoal, tudo bem?

Este artigo fará parte de uma série de artigos que vamos fazer sobre alta disponibilidade e recuperação de desastres na AWS. Bom, vamos ao que interessa.

A Amazon se tornou notícia há algumas semanas atrás, quando uma das suas regiões apresentou falhas e causou indisponibilidade dos seus serviços de computação em nuvem. Grandes players como Trello, Wix e outras grandes empresas da internet sofreram com essa falha, que durou aproximadamente 3 horas. Inclusive um dos meus clientes, uma startup aqui de Santa Catarina, sofreu com essa interrupção de serviços também, mas nem tanto. Nós, da Easy.IT, adotamos uma estratégia de recuperação de falhas, que permitiu ele pôr no ar o seu sistema em menos de 30 minutos. Mas antes de te falar sobre essa estratégia que tenho aplicado nesse cliente, temos que entender alguns conceitos bem importantes sobre computação em nuvem.

A nuvem não é altamente disponível.

Ela pode ser, mas pra isso você tem que pagar para isso. Ou seja, se você quer alta disponibilidade na nuvem, compre alta disponibilidade. É como ir a uma lanchonete, salvo às promoções, você paga pelo que você consome, você não ganha nenhum brinde por isso. Mudar de provedor não vai resolver o seu problema, se você continuar pensando da maneira errada. Tenha uma coisa bem em mente, seja na nuvem ou na sua infraestrutura local, evite um único ponto de falha. Sempre procure adotar estratégias de alta disponibilidade e recuperação de falhas.

Entenda como está estruturado o seu provedor de nuvem.

No nosso caso, a AWS é estruturada em regiões e zonas de disponibilidade. Uma região é um local físico do mundo. E zonas de disponibilidade são um ou mais datacenters discretos, cada um com alimentação redundante, redes e conectividade, hospedadas em instalações diferentes. Cada região possui uma ou mais zonas de disponibilidade. Então, por exemplo, quando você cria um servidor virtual na Amazon, através do serviço do Amazon EC2, você está hospedando esse servidor em apenas um dos datacenters daquela região e não em todos os datacenters.

Vamos exemplificar isso. Suponhamos que você escolheu a região do Brasil para hospedar o seu servidor, e no Brasil eu tenho as zonas de disponibilidade a, b e c. No momento da criação do seu servidor virtual, você tem que escolher uma dessas zonas pra hospedar o seu servidor. A imagem abaixo mostra exatamente onde você escolhe essa opção no assistente de criação de instâncias do Amazon EC2.

Conforme a imagem acima, todo servidor virtual deve estar associado a uma rede virtual. Nesta rede virtual, há várias sub-redes associadas a ela, e cada sub-rede dessa representa uma zona de disponibilidade. Acredito que agora, as ideias estão começando a clarear, não é mesmo? Vamos ver algumas estratégias então que podemos adotar num primeiro momento.

1ª Estratégia: Redundância regional

Você precisa de redundância na região em que você está trabalhando, ou seja, você precisa de um segundo servidor ou mais servidores. E a partir desta ideia, você pode desenvolver várias estratégias de redundância. Dê uma olhada na imagem abaixo.

A imagem acima apresenta uma estratégia de redundância em uma única região. Eu tenho instâncias, ou uma instância em cada zona de disponibilidade em uma determinada região. Então se uma zona de disponibilidade sair fora do ar, eu ainda tenho uma outra zona de disponibilidade ativa mantendo o meu serviço no ar. Vocês podem perceber, que eu tenho um serviço de balanceamento de carga acima das minhas instâncias. Como o próprio nome sugere, esse serviço distribui o tráfego que chega da internet entre as minhas instâncias, otimizando ainda mais o desempenho delas.

Mas como o serviço de balanceamento de carga sabe quando a minha instância está no ar ou não? Através de regras de verificação que você mesmo pode definir, como testes de ping em intervalos frequentes, testes de verificação contra um determinado diretório ou página do seu webiste e até mesmo através de um script personalizado criado por você para avaliar a saúde do seu servidor.

E para otimizar ainda mais sua estratégia de redundância regional você pode utilizar suas instâncias dentro de um grupo de auto escalonamento. O nome deste serviço na AWS se chama Auto Scalling. O Auto Scallig te ajuda a manter a disponibilidade do seu aplicativo ou dos seus serviços, e te permite aumentar ou reduzir a capacidade da suas instâncias do Amazon EC2 para cima ou para baixo de forma automática, de acordo com as condições que você definir.

Vamos exemplificar isso. Na imagem anterior, nós vimos sobre utilizar instâncias em zonas de disponibilidade diferentes debaixo de um balanceador de carga. Agora vamos imaginar, que estamos na época da Black Friday e por enquanto você tem lá suas duas instâncias configuradas para receber esse tráfego. Mas o que acontece é que o pico de tráfego que as suas instâncias recebem, é bem mais do que elas podem aguentar. Isso pode ocasionar lentidão das suas instâncias e até mesmo uma paralisação dos serviços que estão em execução.

E agora? Como é que vão ficar as minhas vendas? Quanto de dinheiro eu vou perder por causa de uma arquitetura mal estruturada? Aí então é que entra o Auto Scalling. De acordo com as condições que você definir, seja por consumo de utilização de CPU, quantidade de entrada e saída de tráfego nas suas instâncias, ou outra forma que você definir, serão adicionadas mais instâncias ao seu grupo de instâncias para que elas possam absorver essa carga de trabalho. E assim que esse pico de alta utilização passar, que também isso será definido em regras que você irá configurar, essas instâncias adicionais serão removidas. O desenho da sua arquitetura vai ficar bem parecido com a imagem abaixo.

Como você pode ver na imagem acima, eu posso utilizar um grupo de auto escalonamento por padrão para receber o tráfego do dia a dia. E quando eu precisar de mais instâncias para receber um pico de tráfego intenso, eu posso configurar uma regra para que ele adicione mais instâncias conforme necessário.

Mas você pode se perguntar, as instâncias que serão adicionadas, serão idênticas as quais eu configurei? E se a minha região falhar, eu vou perder o acesso às minhas instâncias?

Bem, isso eu vou responder na próxima parte do nosso artigo.

No vídeo abaixo, eu demostro pra você como configurar um balanceador de carga entre duas instâncias da Amazon EC2 em zonas de disponibilidade diferentes.

[youtube https://www.youtube.com/watch?v=fS5fMngtlZE]

Gostaria de disponibilizar para você também um e-book que fala sobre 7 dicas para hospedar o seu software na nuvem. Basta baixar ele clicando aqui.

E você utiliza AWS e quer uma ajuda com seu projeto? Agende já a sua consultoria gratuita clicando aqui.

jacksonlima