Como sair da VPS e migrar para a AWS com alta disponibilidade

No fim deste texto você vai ter a ordem de uma migração real de VPS para a AWS com alta disponibilidade: o banco no Amazon RDS Multi-AZ, arquivos e filas no Amazon S3 e no Amazon SQS, e a aplicação em containers no Amazon ECS, em duas zonas de disponibilidade. Foi o caminho do Ricardo, aluno da Formação, com os erros que ele cometeu no meio.

O Ricardo é sócio da empresa e líder técnico de desenvolvimento e operação. A regra da migração dele: o que era servidor caseiro vira serviço gerenciado, e o que continua com você passa a rodar duplicado.

O ponto de partida: um servidor para cada problema

A stack da empresa sempre foi .NET com PostgreSQL. Começou numa hospedagem compartilhada, foi para VPS, e em 2022 o servidor mais antigo na VPS tinha seis anos.

Cada necessidade nova virou um servidor novo: um Nginx como proxy reverso com certificado do Let's Encrypt na entrada, a aplicação num servidor, o banco isolado em outra VPS, um MinIO tentando imitar o S3, um RabbitMQ para as filas e o "Severino", o servidor onde ia parar tudo que não cabia em nenhum outro. Nas palavras dele, a cada seis meses aparecia um servidor novo na empresa.

Cada um com sistema, backup e configuração diferentes, tudo pelo terminal, para uma equipe pequena que vinha de desenvolvimento. Eles estavam montando em casa o que a AWS já entrega pronto. E cada solução caseira cobrou seu preço:

• Entrada sem alta disponibilidade. O certificado wildcard pago custava, na época, de dois a três mil reais, e eles nem sabiam se aquilo ia funcionar. O Let's Encrypt levou uma ou duas semanas para ficar seguro, e eles não sabiam distribuir o certificado entre várias máquinas. O servidor de entrada ficou mais de dois anos sozinho. Nas poucas vezes em que caiu, a porta do sistema fechou para os clientes.
• MinIO travado. Ele não conectou direito com a aplicação ASP.NET Core usando SSL. Foi quase uma semana com os arquivos travados, entre eles os retornos bancários, e cliente reclamando, até voltarem para pastas compartilhadas num servidor Linux, duplicadas para beta e produção.
• RabbitMQ sem domínio da ferramenta. Para poder reenviar, salvavam uma cópia de cada mensagem no banco de dados. Essa cópia salvou a equipe algumas vezes.

O que fez a migração sair do papel

Em 2022 o fornecedor da VPS mudou de data center. Começaram perdas de acesso aos servidores e quedas de uma ou duas horas. O suporte respondia "instabilidade, a equipe está verificando", sem prazo, e o Ricardo ficava sem resposta para dar ao cliente dele. Numa mesma semana, o sistema caiu três vezes no horário de pico da manhã. Numa quinta-feira, ficou fora mais da metade do horário comercial.

A equipe se reuniu e decidiu migrar, no meio da implantação de um cliente novo. Ele já estudava na Formação havia mais de um ano e tinha o roteiro esboçado. A lição que eu tiro disso: se você não tira o tempo para fazer a migração, uma hora é obrigado a fazer, no momento de perrengue.

O destino foi este:

E a ordem em que ele chegou lá:

1Migrar o banco para o Amazon RDS Multi-AZ

O banco vai primeiro. Para o Ricardo, foi de longe a parte mais tranquila, mesmo sendo a mais crítica da empresa: um backup normal do PostgreSQL, restaurado no Amazon RDS, e a aplicação reapontada para o endereço novo. Esse passo ele já tinha dado no fim do ano anterior, antes das quedas.

Duas coisas ajudaram:

• Uma máquina de apoio para mover os backups de um servidor para outro, bem mais rápido do que baixar o backup no computador e subir de novo. A empresa já levava o backup de produção para o beta para validar atualizações.
• Os scripts da Formação, que deram o roteiro de migração do banco.

Como já tinha feito o curso de alta disponibilidade, ele subiu o RDS já em Multi-AZ: o banco tem uma réplica em outra zona de disponibilidade (um data center separado dentro da mesma região), com failover automático. Segundo ele, desde então o banco nunca caiu.

2Trocar arquivos, filas e certificado por serviço gerenciado

Com o banco resolvido, cada servidor caseiro deu lugar a um serviço gerenciado:

• Amazon S3 no lugar do MinIO.
• Amazon SQS no lugar do RabbitMQ.
• AWS Certificate Manager (ACM) no lugar do Let's Encrypt no Nginx.

O SDK no .NET foi simples, e acabou a preocupação com backup e administração desses servidores. O HTTPS, que na VPS custou uma ou duas semanas, ele chamou de "ridiculamente fácil": o certificado é gerado no ACM e anexado na porta HTTPS do load balancer. A escala e a distribuição do certificado entre várias máquinas, que ele nunca conseguiu fazer na VPS, já vêm prontas.

3Subir a aplicação em containers no Amazon ECS

Por último, o servidor de aplicação. Ele saiu da VPS com a aplicação já em Docker e subiu no Amazon ECS. Escolheu o ECS por ser gerenciado e porque o material que já tinha supria a necessidade. O curso de Docker que ele tinha feito, de uma hora e meia a duas horas, virou o manual: ele montou o roteiro e foi seguindo, tirando dúvidas no grupo do Telegram da Formação.

Na configuração do ECS ele usou subnets em mais de uma AZ e pelo menos duas tasks rodando sempre. O resultado:

1. O Amazon Route 53 resolve o domínio.
2. O load balancer recebe o HTTPS com o certificado do ACM.
3. Atrás dele, pelo menos duas instâncias EC2 em duas AZs de São Paulo rodam as tasks do ECS.
4. Todas apontam para o mesmo RDS Multi-AZ.
5. A aplicação usa S3 e SQS, também gerenciados.
6. O conteúdo estático sai do S3 pelo Amazon CloudFront, com custo que ele chamou de irrisório.

O que não está duplicado é gerenciado.

4Rodar em paralelo e testar o deploy sob carga

As duas plataformas rodaram em paralelo durante a migração. Na semana seguinte, um usuário disse que o sistema tinha caído: estava na plataforma antiga. Ela foi desligada depois, num fim de semana.

O deploy também mudou. Na VPS, atualização crítica ia para o almoço ou a madrugada, com aviso aos clientes de que o sistema ficaria fora alguns minutos. Agora o conteúdo estático é publicado no S3 em vez de ir para o Nginx, e a aplicação vai como imagem nova para o ECS. Na troca, o ECS sobe tasks novas, redireciona o tráfego para elas e só então tira as antigas do load balancer.

Para confiar nisso, ele rodou um teste de carga de 10 minutos e mandou atualizar o sistema no meio. Não caiu.

5Medir antes de reservar

A conclusão dele é que a AWS ia sair mais barata que a VPS. Pela estimativa dele, a camada de aplicação, que custava em torno de R$ 1.200 a R$ 1.500 na VPS, devia cair para no máximo R$ 200 a R$ 250. São números da realidade dele em 2022, não tabela de preço: confira os valores atuais na página oficial da AWS.

Na aplicação ele fez diferente. Subiu com a capacidade que sabia que atendia, olhou o Amazon CloudWatch no primeiro dia, viu que o processamento não chegava perto de 40% e rodou instâncias sob demanda menores para medir antes de reservar. A regra que ficou:

• Reserva para o que roda o tempo todo e é previsível. Ele fez reservas conversíveis de um ano, por ser o primeiro ano dele em produção na AWS.
• Sob demanda para o que roda um ou dois dias e fica desligado o resto do mês, como o serviço que importa dados que os clientes trazem de concorrentes.

Checklist

• Liste cada servidor da VPS e o que ele faz. Cada solução caseira é candidata a serviço gerenciado.
• Migre o banco primeiro: backup do PostgreSQL, restauração no Amazon RDS Multi-AZ, aplicação reapontada.
• Troque arquivos por S3, filas por SQS e o certificado caseiro pelo ACM no load balancer.
• Coloque a aplicação em Docker e suba no Amazon ECS, com pelo menos duas tasks em duas AZs.
• Rode a plataforma antiga em paralelo durante a migração e só depois desligue.
• Teste o deploy debaixo de carga antes de confiar nele.
• Meça no CloudWatch antes de reservar instância.

O Ricardo migrou porque o fornecedor tirou o sistema do ar, e deu certo porque o roteiro já estava pronto. Monte o seu antes de precisar dele.