Por que movemos os servidores do Mythex para ARM

Em 19 de setembro, movemos o backend de produção do Mythex de servidores x86 para servidores AWS Graviton, baseados em ARM, menores, e também movemos o banco de dados da plataforma para uma instância Graviton. O motivo era simples: depois que passamos o trabalho pesado, rodar e construir o app de cada usuário, para sandboxes isolados por projeto, nossos servidores principais chegavam a usar cerca de um terço da memória. Máquinas ARM menores cabem na carga real e reduziram a conta mensal de servidores em cerca de 30%.

O que os nossos servidores fazem agora

Antes, os servidores de backend faziam muito trabalho diretamente. Por volta de meados de setembro, terminamos de mover as partes caras (rodar o código de cada projeto, instalar pacotes, construir apps) para sandboxes privados na nuvem, um por projeto. É isso que também dá a cada projeto um ambiente isolado e uma pré-visualização ao vivo.

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

Por que ARM

Os processadores Graviton da AWS são chips ARM projetados pela AWS. Pelo mesmo preço, em geral você obtém mais capacidade do que uma instância x86 comparável, ou a mesma capacidade por menos. E para uma carga como a nossa (serviços Node.js, Docker, Postgres) nada nos prende ao x86.

Movemos:

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

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

Nosso ambiente de testes ainda roda em um pequeno servidor x86. A produção agora roda em ARM. Uma imagem de contêiner construída para uma delas não roda na outra.

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

Planejar a reversão antes da mudança

Mudar a arquitetura da CPU sob um serviço ao vivo é o tipo de mudança que você quer poder desfazer em minutos. Antes de trocar, nós:

• mantivemos a versão anterior do modelo de servidor como alvo de reversão nomeado,
• tiramos um snapshot do banco logo antes de redimensioná-lo, e
• escrevemos um runbook cobrindo a mudança e o caminho de volta.

Não precisamos da reversão. Ainda faríamos do mesmo jeito.

O que observaríamos

Servidores menores têm menos folga. Duas coisas decorrem disso:

1. Se o trabalho pesado voltar a rodar nesses servidores, 2 GB não serão suficientes. A solução então é um tamanho Graviton maior, e não voltar ao x86.
2. Máquinas pequenas precisam de swap. Uma semana depois, um desses servidores travou por pressão de memória sem tecnicamente esgotar a memória: a história do arquivo de swap que faltava.

O que tiramos disso

• Meça de novo depois de mudar a arquitetura. Mover o trabalho para os sandboxes mudou o que os nossos servidores precisavam; os tamanhos das instâncias ainda não tinham acompanhado.
• ARM é um ganho de baixo risco para stacks web comuns quando as suas imagens são multi-arquitetura.
• Escreva a reversão primeiro. Ela deixa a mudança mais tranquila mesmo que você nunca precise usá-la.