webapps

Em praticamente toda documentação ou literatura a respeito de Cloud Computing, o cenário híbrido é abordado. Parte dos recursos on premise, parte na nuvem. Abordagem muito comum, presente em praticamente todas as empresas que estão neste movimento. E soluções distribuídas entre os provedores de public cloud (cloud x cloud), já pensou em implementar? Distribuir a carga do seu website entre Azure e AWS, implementar roteamento baseado em performance (latência) ou até mesmo implementar failover? Sim, é possível – e simples. É nesta hora que entra um de meus serviços preferidos no Azure: o Traffic Manager.

Basicamente, a função do Traffic Manager é distribuir o tráfego entre endpoints localizados em diferentes datacenters. Sendo totalmente DNS based, ele não atua como proxy ou gateway: apenas direciona os clientes diretamente ao endpoint, não “enxergando” o trafégo entre eles.

Os tipos de roteamento possíveis são:

• Priority: roteamento de tráfego com prioridade para um endpoint primário, sendo o secundário um backup. Exemplo: o endpoint primário do meu website rodando no Azure, e o secundário no AWS. Caso o primeiro esteja down, o tráfego será atendido pelo segundo.
• Weighted: distruibuição do tráfego entre os endpoints, no estilo “round-robin”. Ou ainda é possível definir um “peso” por endpoint.
• Performance: meu preferido. Neste método posso ter meus endpoints distribuídos geograficamente. Os clientes serão roteados para o endpoint com menor latência, baseados em sua localização. Exemplo: o mesmo website deployed em regiões diferentes (Brasil e Oeste dos EUA): muito provavelmente, os clientes baseados no Brasil serão atendidos pelo website que roda em nosso país, assim como os clientes dos Estados Unidos possivelmente serão atendidos pela instância rodando naquele país:

Nota: e outros países além do Brasil e Estados Unidos? Em todos os testes que fiz até hoje, utilizando algumas ferramentas (como GeoPeeker), todas as requisições foram atendidas por instancias localizadas nos Estados Unidos (originadas da Ásia e Europa). Não testei América Latina, pois no plano gratuito da ferramenta, países como Argentina não estão disponíveis.

• Geographic: roteamento “fixo” a endpoints específicos, baseados na localização geográfica. Ainda não utilizei.

Tipos de endpoint:

• Azure: usados para serviços que estão hospedados no Azure.
• External: para todos externos ao Azure. Ou seja: para endpoints on-premises ou em outro cloud provider (como AWS ou Google Cloud)
• Nested: combinação de diferentes perfis do Traffic Manager.

Para este exemplo de integração, nos interessam dos tipos: Azure e External. Teremos uma instância do website rodando como PaaS no Azure (WebApp), e a outra rodando no AWS Elastic Beanstalk, sendo seu endpoint configurado como tipo “External”. A grande sacada do Traffic Manager é essa: se for External, não interessa se está hospeado em sua infraestrutura interna ou em outro cloud provider – ele considera o endpoint do mesmo tipo.

A documentação completa pode ser encontrada neste link.

Implementação:

Assumo que a aplicação já esteja deployed, tanto no Azure Webapps como no AWS Elastic Beanstalk. Neste exemplo, utilizei um projeto .Net que usamos no Global Azure Bootcamp (obrigado Gabriel Molter). Para fins de demonstração, adicionei hard-coded  o cloud provider em questão. O deployment foi feito separadamente em cada um dos serviços, mas poderia ser facilmente integrado no VSTS Online.

 

A configuração é extremamente simples. Basta criar um Traffic Manager profile, escolhendo nome (formando a URL <nome>.trafficmanager.net), Resource Group e Routing Method. Neste exemplo, o método de roteamento escolhido é o Priority, pois quero reproduzir um cenário onde o Azure seja meu hosting principal e o AWS ecundário, posteriormente simulando um downtime no primeiro. Note que esse método de roteamento pode ser alterado a qualquer momento.

Um detalhe sobre o TTL: como o Traffic Manager é baseado em DNS, é necessário a definição de um TTL (Time-To-Live). Isso significa que uma vez feita a consulta pelo cliente, as próximas consultas deste ao Traffic Manager serão feitas somente após a expiração do TTL. Este valor é definido em segundos (sendo 300 o padrão).

TTL maior ou menor: na minha opinião, vai depender do método de roteamento utilizado, No caso de Priority, com o objetivo de failover, sugiro um TTL menor do que o padrão (caso o ocorra algum problema com o endpoint, não faz sentido ter que esperar 5 minutos para ser redirecionado para uma instancia “saudável”). Posso utilizar o menor TTL possível, indendente de método? Pode, mas lembre-se que a cobrança do Traffic Manager se dá por número de consultas efetuadas pelos clientes.

Assim que o deployment do Traffic Manager estiver completado, basta adicionar os endpoints:

Azure:

• Type “Azure endpoint“,
• Name: “Azure” – (ou qualquer outro de sua preferência)
• Target  resource type: “App Service“, pois estou adicionando um endpoint de uma Azure Web App (PaaS). Outras opções são endpoints de VM´s no Azure ou Cloud Service:
• Target resource: basta selecionar a Web App (as opções disponíveis aqui são baseadas na escolha do campo acima)
• Priority: “1” – ou seja, será meu endpoint primário (menor valor, maior prioridade)

AWS:

• Type “External endpoint“,
• Name: “AWS” – (ou qualquer outro de sua preferência)
• FQDN: url completa do site hospedado na AWS (sem http/https ou barra no final)
• Priority: “2” – prioridade menor em relação ao site hospedado no Azure

 

Assim que adicionado o endpoint, o Traffic Manager irá fazer um health check:

Pronto, basta acessar o endereço definido na criação do serviço (http://<nome>.trafficmanager.net).

 

Resultados (baseado no método Prioridade):

Nota: a aplicação, tanto o Azure AppService, quanto o AWS Elastic Beanstalk, foram deployed na mesma região (Brasil). Estes testes são simples (sem alguma metodologia oficial), podendo haver variação.

Para testar este tipo de cenário, costumo usar o GeoPeeker.

• Estando os dois endpoints online, considerando Azure com prioridade 1, e AWS com 2, todas as requests foram direcionadas conforme o esperado, ou seja, para o Azure:

• Através do Azure Portal, parei a minha aplicação, deixando a mesma offline. Todas as requests foram redirecionadas para o AWS:

Observação: se você for executar este teste, esteja atento ao TTL configurado no serviço. Será necessário aguardar o mesmo expirar, para que o roteamento aconteça de forma correta (lembre-se, é um roteamento DNS based). Outra solução é rodar ipconfig /flushdns na sua máquina.

Outros resultados que obtive:

• Performance: todas redirecionadas para o Azure.
• Weighted: das seis requests, quatro foram para o AWS.

Apesar de abordar somente a camada de aplicação de maneira distribuída entre ambos provedores de núvem pública – o banco de dados tem uma complexidade muito maior neste cenário (assunto para outro post) – o Traffic Manager é sem dúvidas uma solução robusta e de rápida configuração. Há não muito tempo atrás, os custos para implementar algo semelhante era absurdamente alto, praticamente inviável para empresas de pequeno porte. E para quem estiver estudando para certificação, o Traffic Manager é assunto na prova 70-533.

Até a próxima! Um Tríplice Fraternal Abraço!