Escalar aplicação web na AWS: os 4 requisitos antes de subir

Uma aplicação web só escala na AWS se quatro pontos estiverem resolvidos: onde fica a sessão do usuário, onde ficam os assets, se ela roda em container e onde ficam os arquivos que o usuário envia. O último é o que mais trava, e tem solução na própria nuvem.

Gravei esta aula em 31 de março de 2023. Os serviços citados continuam existindo, mas confira as telas e as opções na documentação oficial da AWS antes de configurar: Amazon ElastiCache, Amazon ECS e Amazon EFS.

O cenário: uma aplicação .NET em uma máquina

Parto de uma aplicação web em .NET Core rodando em Linux. Poderia ser Node, Java ou Rails, não muda o raciocínio. Deixo o banco de fora: ele se resolve com o RDS em Multi-AZ ou com o Aurora.

A aplicação tem três características que, à primeira vista, parecem impedir a ida para a nuvem. Ela autentica o usuário, guarda a autenticação em memória, recebe o upload de fotos que ficam na pasta /fotos e serve arquivos da pasta /assets.

Ao subir na AWS, a aplicação roda em duas EC2 atrás de um balanceador de carga. É aí que cada característica vira um problema, ou não.

Requisito 1: tire a sessão da memória da máquina

Se a autenticação fica na memória e há duas máquinas, o usuário se autentica na máquina 1 e a próxima requisição cai na máquina 2. Ali a informação não existe e a autenticação é derrubada.

É o mais fácil dos quatro. Use o Amazon ElastiCache, integrado a uma biblioteca da tecnologia que você usa, e mande os dados de autenticação para lá. As duas máquinas passam a consultar o mesmo lugar.

Requisito 2: deixe os assets onde estão

Os assets na máquina não impedem a aplicação de escalar. O deploy entrega o mesmo pacote para a máquina 1 e para a máquina 2, e os assets ficam iguais nas duas.

Depois você pode colocar um CDN na frente, para deixar essa informação em cache, ou redesenhar para levá-los ao S3. Mas isso é melhoria, não pré-requisito.

Requisito 3: coloque a aplicação em container

Do jeito que está, a aplicação roda na nuvem. O que o container resolve é o mapeamento e o teste: o que roda na sua máquina fica compatível com o que roda na AWS, porque você já descreveu os requisitos para rodar a aplicação e gerou uma imagem dela.

A vantagem prática é poder usar o Amazon ECS: a imagem fica guardada no ECR e o ECS monta um cluster para a aplicação. Você ganha uma forma mais homogênea e melhor gerenciada de rodar e de escalar. O desafio existe, mas não é grande: a contenerização é só entender os requisitos da sua aplicação. Para o passo a passo, leia primeiro container em produção no ECS e o que é Docker.

Requisito 4: arquivos enviados pelo usuário fora do disco da EC2

Este é o maior gargalo. O usuário se autentica na máquina 1, sobe a foto de perfil e ela é gravada em /fotos no disco dessa EC2. Na requisição seguinte ele cai na máquina 2, a pasta /fotos dela não tem a foto e o carregamento falha. Cada EC2 tem o seu disco.

O que costumam dizer é para reescrever o upload com o SDK da AWS e gravar no S3. Funciona, e é até a melhor forma. Mas nem sempre é a mais prática: o upload é só uma das operações, a leitura e outras também precisam mudar, e isso pode impedir a aplicação de ir para a nuvem. Quem diz que, por isso, ela não escala está errado. Esse requisito se resolve na nuvem.

O problema técnico é o disco estar dentro da máquina. A solução é um disco externo e elástico, presente na zona A e na zona B, com os dados replicados automaticamente entre as zonas e gerenciados pela AWS. Esse disco é o Amazon EFS.

Você monta o /fotos nele. Quando o usuário sobe a foto pela máquina da zona A, ela já está disponível quando a requisição cai na zona B. Ao adicionar mais uma instância ao cluster, o mapeamento do disco é feito automaticamente. Se quiser a comparação entre S3 e disco elástico, leia Docker com alta disponibilidade na AWS.

O que mudou na aplicação

No fim, a aplicação que parecia inviável de levar para a nuvem foi do jeito que estava, com operações relativamente simples: a autenticação foi para o ElastiCache, os assets ficaram onde estavam, ela virou container e a pasta de fotos foi para o disco elástico.

O requisito mais importante, na minha opinião, é a contenerização. Dominando o processo, ela não é difícil, e vale conhecer o que impede uma aplicação de escalar antes de aceitar que ela não vai para a nuvem. Para ver essas ideias aplicadas em outro caso, leia como sair da VPS e migrar para a AWS.

Checklist

• Confirme onde a aplicação guarda a autenticação do usuário.
• Se for em memória, mande esses dados para o ElastiCache.
• Verifique que os assets vão no pacote do deploy; CDN ou S3 ficam para depois.
• Mapeie o que a aplicação precisa para rodar e gere a imagem em container.
• Use o ECS para rodar a aplicação como cluster.
• Liste as pastas onde a aplicação grava arquivos do usuário.
• Mova essas pastas para o disco elástico (EFS), em vez do disco da EC2.
• Só então adicione mais instâncias ao cluster.

Se a sua aplicação grava arquivos em disco e você não tem certeza do que impede ela de escalar, vale conversar antes de reescrever qualquer coisa.