Concrete | Como configurar um Magento com alta disponibilidade na AWS
Você vai montar uma loja virtual. Fez algumas pesquisas, ouviu alguns especialistas e chegou às seguintes conclusões:
– Quer começar gastando pouco, pois não tem muito dinheiro para investir;
– Quer usar ferramentas de código aberto, gastando o mínimo possível com software;
– Não quer comprar hardware, afinal estamos na era da computação nas nuvens.
Depois de mais algumas conversas, você decidiu que vai utilizar Magento como software de e-commerce e Amazon Web Services como provedor de infraestrutura como serviço. Podemos dizer que você fez uma boa escolha, e veremos neste post algumas ideias para este tipo de ambiente.
As premissas para as sugestões que daremos são:
1. Sempre que possível, contratar ferramentas como serviço, reduzindo administração;
2. Tentar criar um ambiente elástico e com alta disponibilidade;
3. Fazer tudo isso dando aos custos sua devida importância.
Agora que já temos nosso objetivo e as regras, vamos começar de um modo bem fácil: com a implementação mais simples possível de um Magento, ou seja, com um único servidor. Não vamos aqui entrar em detalhes da instalação do Magento, mas você pode conferir no wiki do projeto. Os únicos pré-requisitos para nosso setup são a utilização de Linux como SO, do PHP-FPM e do NGINX como servidor web. Como decidimos usar serviços sempre que necessário, nosso cenário 1 fica assim:
Temos uma instância EC2 com Linux, na qual instalamos o Magento. A outra instância é um RDS, serviço de banco de dados relacionais da Amazon, rodando MySQL. É uma instalação válida, mas oferece pouca segurança em relação à disponibilidade ou performance. Vamos melhorá-la.
Um recurso muito interessante da AWS é o ASG ─ Autoscaling Group. Com o ASG, você define uma instalação modelo, uma quantidade desejada de instâncias e pronto: a AWS se encarrega de manter a quantidade que você escolheu de instâncias EC2 sempre em execução. O mais legal é que você pode configurar regras baseadas em utilização de CPU ou usuários no Load Balancer, por exemplo, que fazem com que seu ASG aumente temporariamente a quantidade de instâncias para atender a demanda.
Para melhorar nosso desenho, vamos separar o Frontend do Backend, criando um grupo escalável para o Front. Para fazer isso, vamos configurar o Magento para salvar a sessão no banco de dados, de modo que ela possa ser compartilhada entre os servidores. O cenário 2 fica assim:
Ainda não é o melhor cenário, mas agora já temos as seguintes vantagens:
– A experiência do usuário será melhor, já que nos momentos de pico de carga o ASG inicializará novas instâncias para diminuir o processamento por instância de Front;
– A disponibilidade da aplicação será maior, porque em caso de problemas com algum dos servidores de Front, o ASG iniciará automaticamente uma nova instância.
Ok, mas agora queremos performance. A melhor forma de fazer isso é adicionando cache. Vamos usar cache em vários locais: cache antes de acionar o Front, cache entre o Front e o MySQL e cache externo através de um CDN. Para isso, vamos colocar nossos objetos estáticos no S3, que é um serviço barato e com 99,999999999% de durabilidade (isso quer dizer que nossos dados estarão realmente em boas mãos). Vamos também mudar os dados de sessão (que agora estão no MySQL) para um servidor Redis, que utiliza cache em memória RAM. Ficamos assim no cenário 3:
Boa, agora nosso site está voando! Mas, como diriam os ingleses, hold your horses! Já pensou se a zona de disponibilidade que estamos usando fica indisponível? Precisamos distribuir nossa aplicação geograficamente.
Vamos aproveitar para replicar, além da aplicação, nossos bancos de dados (MySQL e Redis). Vamos também adicionar um ASG para o Backend, para que sempre tenhamos uma instância do Admin do Magento em execução. Nosso cenário 4 fica assim:
Supimpa! Agora temos uma arquitetura de Magento rápida, escalável, altamente disponível e com custos justos, já que na Amazon você só paga pelo que utiliza.
Esta não é a arquitetura definitiva: ainda poderíamos adicionar mais um nível de cache com o Varnish, utilizar um serviço de buscas externo como o Solr ou mesmo o CloudSearch, utilizar plugins do próprio Magento para modificar o comportamento do site em relação à escrita de dados… enfim, a vantagem das ferramentas de código aberto é a liberdade de entender e melhorar o software.
O objetivo do post era dar apenas uma visão geral do processo de planejamento da arquitetura, e acho que conseguimos. Por hoje é só! Até a próxima. Teve alguma dúvida ou sugestão? Só deixar aqui embaixo nos comentários.