O objetivo do projeto foi implantar a plataforma Wordpress na nuvem AWS de forma escalável e tolerante a falhas, utilizando os principais serviços gerenciados da AWS. Para isso a aplicação foi distribuída em múltiplas instâncias EC2 por meio de um ASG (Auto Scaling Group), com balanceamento de carga fornecido por um ALB (Application Load Balancer). O armazenamento de arquivos foi centralizado e compartilhado por meio de um EFS (Elastic File System), enquanto os dados da aplicação foram armazenados em um banco relacional altamente disponível com o Amazon RDS (Relational Database Service).
O objetivo desta sessão é apresentar um resumo básico dos recursos/serviços utilizados e o papel que cada um deles desempenha no funcionamento da aplicação, para conferir o passo a passo da implementação e as configurações do ambiente clique aqui.
Ao invés de concentrar todos os recursos em uma única AZ (Availability Zone), a VPC foi distribuida entre duas AZs diferentes. O principal objetivo disso é disponibilidade e resiliência, se uma AZ cair, outra continua operando. A VPC multi-az foi criada com 6 subnets (2 públicas e 4 privadas), Route Tables, NAT Gateway e Internet Gateway.
Para atender as demandas de disponibiidade, as subnets também foram distribuidas em duas AZs diferentes (az-1 e az-2). Com relação às subnets privadas, afim de isolar banco de dados de instâncias, há difereciação entre subnets para dados (data-az1 e data-az2) e subnets para aplicações (app-az1 e app-az2).
O NAT Gateway foi criado para permitir que as intancias nas subnets destiandas a aplicação (app) acessassem a internet sem exposição direta, desse modo as intancias podem receber atualizações, downloads e etc sem compromoter a segurança do ambiente. Foram configurados dois NAT Gateways, um em cada subnet pública, para que as subnetes em ambas as AZs tivessem essa conexão controlada à internet.
O Internet Gateway permite que recursos nas subnets públicas se conectem à Internet e também que os recursos na Internet iniciem uma conexão com eles usando o endereço IPv4 público.
Assegura disponibilidade gerenciando o número de instâncias de acordo com a demanda e parâmetros definidos durante sua criação. Foi criado com escalamento baseado em CPU, ou seja, garante que as solicitações dos usuários sejam processadas rapidamente, utilizando a capacidade de cada máquina de forma eficiente.
Distribui tráfego HTTP para instâncias da aplicação. Foi criado com listener na Portas 80 (HTTP) e com target groups apontando para instâncias EC2, criadas pelo ASG, nas subnets privadas.
Banco de dados relacional gerenciado pela própria AWS. Foi criado com MySQL e em uma das subnets privadas destinada aos dados. O RDS pode ser usado para armazenar dados estruturados (tabelas, colunas, linhas) como: postagens, usuários ou informações transacionais.
Proporciona armazenamento compartilhado e escalável para múltiplas instâncias, como um "HD na nuvem". O EFS pode ser usado para armazenar arquivos e pastas, como: imagens, PDFs ou vídeos enviados pelo WordPress. Foi configurado com dois Mount Targets, cada um em uma az, e com o EFS Infrequent Access para otimizar os custos. A montagem ocorre dentro das instâncias EC2 via NFS.
Foi feito uma integração com o Discord via webhook para faciltar o monitoramento da montagem do EFS e da conexão com o RDS dentro das instâncias. Para isso foi criada uma função que envia a um servidor privado no Discord mensagens descrevendo o status dos serviços.
O arquivo docker-compose contendo o serviço wordpress, baseado em uma imagem Wordpress + PHP + Apache, foi fundamental para o funcionamneto da aplicação. Ele centralizou todo o código, dependências e caminhos necessários, além de facilitar o controle e a manutenção.
Todos esses serviços foram configurados e inicializados durante a realização do boot da instância. Isso foi possível por meio de um script userdata.
Em conformidade com as boas práticas de FinOps, todo o ambiente foi planejado para operar com o máximo de eficiência de custos na nuvem. As principais técnicas utilizadas para atingir esse objetivo foram:
- Monitorento diário via Cost Explorer
- Uso de tags para controle e monitoramento de gastos
- Uso de free tier nos recursos que havia possibilidade
- Uso de um banco de dados RDS single az
- Uso de apenas um NAT Gateway
- Infrastructure as Code com Terraform ou CloudFormation
- Variáveis de ambientes e dados sensíveis gerenciados via Secrets Manager
- Previsão de custos usando AWS Pricing Calculator