Porque Mudámos os Servidores do Mythex para ARM

No dia 19 de setembro passámos o backend de produção do Mythex de servidores x86 para servidores AWS Graviton, de arquitetura ARM e mais pequenos, e passámos também a base de dados da plataforma para uma instância Graviton. O gatilho era simples: depois de termos movido o trabalho pesado — correr e construir a app de cada utilizador — para sandboxes isoladas por projeto, os nossos servidores principais atingiam picos de cerca de um terço da sua memória. Máquinas ARM mais pequenas cabem na carga real e reduziram a fatura mensal dos servidores em cerca de 30%.

O que fazem agora os nossos servidores

Antes, os servidores do backend faziam muito trabalho diretamente. Por volta de meados de setembro terminámos a mudança das partes caras — correr o código de cada projeto, instalar pacotes, construir apps — para sandboxes de cloud privada, uma por projeto. É isso que também dá a cada projeto o seu próprio ambiente isolado e a sua pré-visualização ao vivo.

O que ficou nos nossos próprios servidores é a coordenação: a API, o orquestrador que gere sandboxes e publicações, a autenticação, a faturação e o gateway. Esse trabalho é constante e leve. Depois da mudança, os servidores atingiam picos de cerca de 1,3 GB de memória em máquinas com cerca de três vezes isso.

Porquê ARM

Os processadores Graviton da AWS são chips ARM desenhados pela própria AWS. Pelo mesmo dinheiro, normalmente obtém-se mais capacidade do que numa instância x86 comparável, ou a mesma capacidade por menos — e para uma carga como a nossa (serviços Node.js, Docker, Postgres) não há nada que nos prenda ao x86.

Mudámos:

• Dois servidores de aplicação de instâncias x86 de porte médio para pequenas instâncias Graviton com 2 GB de RAM cada.
• A base de dados da plataforma de uma pequena instância x86 de base de dados para o seu equivalente Graviton.

A única complicação real: imagens para duas arquiteturas

O nosso ambiente de staging continua numa pequena máquina x86. A produção corre agora em ARM. Uma imagem de contentor construída para uma não corre na outra.

Por isso, cada imagem é agora construída para as duas arquiteturas sob uma só etiqueta — uma imagem multi-arquitetura. O Docker escolhe automaticamente a variante certa em cada máquina, e o pipeline de deploy não precisa de saber para que ambiente está a enviar. O custo é um build de CI mais longo; o benefício é que o staging e a produção correm exatamente o mesmo código a partir exatamente da mesma etiqueta.

Planear o rollback antes da mudança

Mudar a arquitetura do CPU sob um serviço em produção é o tipo de alteração que queres poder desfazer em minutos. Antes de mudar, nós:

• guardámos a versão anterior do template do servidor como alvo de rollback com nome,
• tirámos um snapshot da base de dados imediatamente antes de redimensionar a base de dados, e
• escrevemos um runbook que cobria a mudança e o caminho de volta.

Não precisámos do rollback. Faríamos da mesma forma outra vez.

O que vigiaríamos

Servidores mais pequenos têm menos margem. Duas coisas decorrem disso:

1. Se algum dia o trabalho pesado voltar para estes servidores, 2 GB não chegam. A solução nesse caso é um tamanho Graviton maior, não voltar ao x86.
2. Máquinas pequenas precisam de swap. Uma semana depois, um destes servidores congelou por pressão de memória sem tecnicamente ficar sem memória — a história do ficheiro de swap em falta.

O que tirámos disto

• Volta a medir depois de mudanças de arquitetura. Mover o trabalho para sandboxes mudou o que os nossos servidores precisavam; os tamanhos das instâncias ainda não tinham acompanhado.
• ARM é uma vitória de baixo risco para stacks web típicas quando as tuas imagens são multi-arquitetura.
• Escreve primeiro o rollback. Torna a mudança mais calma mesmo que nunca o uses.