Preciso ser sincero: este post é, na verdade, a documentação de uma solução que implementamos em um grande cliente da Microsoft com o qual tenho trabalhado recentemente. Resolvi documentar a solução (e pretendo continuar fazendo isso no futuro para outras soluções) através deste post por acreditar que esta solução possa ser útil a você em algum momento no futuro.
Situação problema e definições iniciais
A demanda que recebemos foi a seguinte: temos um site com páginas estáticas que hospedam games escritos em Unity e queremos migrar para o Azure. Tratam-se de páginas HTML (com CSS) que fazem o host dos containers Unity. Os games, evidentemente, são reproduzidos através do navegador. Muito embora a aplicação fosse simples, ela recebia um alto volume de acessos, o que nos indicou a necessidade de criar uma solução escalável. Havia ainda o requerimento de que o baixo custo em relação a infraestrutura fosse mantido (ou ainda reduzido) e a performance fosse mantida (ou incrementada). A aplicação precisava responder em um domínio personalizado.
Os desafios são claros, certo? Veja:
- Unity utiliza algumas configurações específicas no ambiente para que seja possível rodar as aplicações, certo?
- Qual a melhor abordagem para entregar uma aplicação que precisa ter um baixo custo mas que, ao mesmo tempo, precisa ser altamente escalável, performática e resiliente?
- Uma estrutura com baixo custo que pudesse responder em um domínio personalizado? Interessante.
Sempre que recebemos uma demanda de migração, buscamos fazer uma análise bem criteriosa das necessidades versus os recursos disponíveis na plataforma que poderiam endereçar esta migração. Com esta aplicação não foi diferente. Fizemos o seguinte racional:
- Trata-se de uma aplicação web. Logo, o recurso Web App pode fazer sentido, uma vez que, se comparadas com máquinas virtuais, possuem um valor bem mais acessível e baixo custo é um requerimento crítico aqui.
- A aplicação recebe um alto volume de acessos. Isso quer dizer que, se for preciso escalar, a estrutura que hospeda esta aplicação tem que estar pronta pra isso. Novamente, Web App se apresenta como uma boa opção.
- Um aspecto interessante e super importante para essa aplicação: temos apenas arquivos estáticos (HTML, CSS e arquivos Unity). Sabemos que um recurso útil e amplamente utilizado nas plataformas de nuvem para dar agilidade (leia-se performance) à aplicações web é entregar arquivos estáticos através de algum mecanismo de Content Delivery Network (as famosas CDN). Será que faz sentido utilizar uma camada de CDN a frente do Web App que hospeda a aplicação? Nos pareceu inicialmente que sim e felizmente, podemos contar com serviço gerenciado do Azure para este fim – 0 Azure CDN.
- Tanto utilizando Azure CDN quanto utilizando Web Apps poderíamos ter domínios personalizados, portanto, isto não seria um problema.
- Mas nos restava saber se, de alguma maneira, conseguiríamos fazer as personalizações necessárias na Web App para que a aplicação pudesse rodar de maneira satisfatória neste ambiente. Caso contrário, precisaríamos de uma VM (ou container) para rodar a aplicação.
Em termos arquiteturais nossa primeira conclusão foi: criaremos um Web App (com tier básico para reduzir o custo da infraestrutura, para suportar nomes personalizados e escala) e colocaremos uma camada de CDN na frente para que os arquivos sejam entregues por ela com um TTL alto (vez que a aplicação recebe poucas mexidas).
Como implementamos?
Com a decisão inicial de infra tomada, partimos para a implementação e testes iniciais.
Passo 1 – Testar a aplicação
A primeira coisa que fizemos então foi testar o funcionamento da aplicação de fato e possíveis ajustes de ambiente para que isso fosse possível. Criamos então a Web App e configuramos o processo de deployment automatizado (recurso nativo dos Web Apps), uma vez que o fonte da aplicação se encontrava em um repositório GitHub. Conforme imaginávamos, a aplicação não funcionou de primeira. Ao chamá-la através do navegador, recebíamos o seguinte erro:
Após algum tempo pesquisando na documentação do Unity, descobrimos que para alguns containers web (como IIS, por exemplo) é preciso fazer o set manual dos mimes utilizados pela aplicação. Como estamos em um ambiente de Web App baseado em Windows (e portanto estamos falando de IIS), devemos fazer uma declaração manual destes mimes. Fizemos isso através de um arquivo web.config localizado na raíz da aplicação. O conteúdo do mesmo pode ser visualizado na listagem 1.
Basicamente o que estamos fazendo aqui é adicionar as extensões de arquivos utilizados pelo Unity bem como seus mimeTypes. Super simples. com essa declaração explícita, paramos de receber o erro apresentado anteriormente em tempo de execução e a aplicação passou a funcionar de maneira satisfatória.
Você pode visualizar o processo de criação de uma Web App seguindo o link a seguir.
https://docs.microsoft.com/en-us/azure/app-service-web/app-service-web-app-azure-portal
Para entender como funciona o processo de configuração de integração contínua entre uma Web App e um repositório Git, você pode seguir o link a seguir.
https://docs.microsoft.com/en-us/azure/app-service-web/app-service-continuous-deployment
Passo 2 – Configurando o CDN
Com a aplicação funcionando adequadamente no Azure Web Apps, partimos para configurar o processo de CDN. Para isso, criamos uma nova conta de Azure CDN (você pode visualizar um tutorial que ensina a fazer isso seguindo o link abaixo). Em nosso caso, o plano que melhor se aplicava era o P1 Premium da Verizon.
https://docs.microsoft.com/en-us/azure/cdn/cdn-create-new-endpoint
Depois disso adicionamos um novo endpoint com a capacidade de suportar HTTP e HTTPS e “dissemos” ao Azure que era para ele entregar todo o conteúdo abaixo do diretório raiz do Web App recém criado(lembre-se, nossa aplicação está hospedada em um Web App). Após isso, decidimos colocar um custom domain no próprio CDN (o que nos isenta da responsabilidade de fazer isso no Web App, certo?).
Analisando o cenário de maneira um pouco mais aprofundada, chegamos a conclusão de poderíamos reduzir o tier do Web App (para gratuito) que hospeda a aplicação Unity (o que baixaria ainda mais o valor da infra da mesma). Poderíamos fazer isso por um motivo muito simples: como o Web App não processa conteúdos dinâmicos (ao contrário, temos apenas objetos estáticos), podemos fazer com que o Azure CDN entregue os arquivos estáticos diretamente ao cliente sem nos preocupar com a escala, com o backup e com a resiliência (ambas as características já são entregues pelo CDN do Azure). Além disso, não precisamos mais dos domínios personalizados dos Web Apps.
Assim procedemos. Nos surpreendemos com a eficiência na entrega da aplicação com os testes de carga. O cliente ficou super satisfeito e já temos a aplicação rodando em ambiente produtivo atualmente. De fato, quem está entregando a aplicação é o Azure CDN. Web App em tier gratuito apenas faz o host dos arquivos.
Para visualizar um tutorial de como atrelar um domínio personalizado a um endpoint de CDN, siga o link a seguir.
https://docs.microsoft.com/en-us/azure/cdn/cdn-map-content-to-custom-domain
Conclusão
Conseguimos viabilizar a migração de uma aplicação (game) com alto volume de acessos com suporte a escala automática, performance e principalmente, com baixo custo, utilizando apenas dois recursos de plataforma (PaaS) do Azure. Na Amazon, esta mesma aplicação precisava rodar em um pequeno cluster de VMs (por conta da escala automática). Mais recursos alocados do que ela realmente precisava.
Uma dica importante aqui: sempre vale a pena despender algum tempo analisando se a aplicação que se pretende migrar tem aplicabilidade no contexto de Plataforma como Serviço. Digo isso porque os ganhos são notórios: terceirização da gestão, eficiência, performance e principalmente, de maneira geral, custo mais efetivo. Este game que migramos foi mais um destes casos.
Facebook
Twitter
Instagram
LinkedIn
RSS