Por qué trasladamos los servidores de Mythex a ARM

El 19 de septiembre trasladamos el backend de producción de Mythex de servidores x86 a servidores AWS Graviton, más pequeños y basados en ARM, y también movimos la base de datos de la plataforma a una instancia Graviton. El detonante era sencillo: tras mover el trabajo pesado (ejecutar y compilar la app de cada usuario) a sandboxes privados por proyecto, nuestros servidores principales alcanzaban en su pico alrededor de un tercio de su memoria. Las máquinas ARM más pequeñas se ajustan a la carga real y redujeron la factura mensual de servidores en aproximadamente un 30 %.

Qué hacen ahora nuestros servidores

Al principio, los servidores del backend hacían mucho trabajo directamente. Hacia mediados de septiembre terminamos de mover las partes costosas (ejecutar el código de cada proyecto, instalar paquetes, compilar apps) a sandboxes privados en la nube, uno por proyecto. Eso también es lo que da a cada proyecto su entorno aislado y su vista previa en directo.

Lo que se quedó en nuestros propios servidores es la coordinación: la API, el orquestador que gestiona sandboxes y publicaciones, la autenticación, la facturación y la puerta de enlace. Ese trabajo es constante y ligero. Tras el traslado, los servidores alcanzaban en su pico unos 1,3 GB de memoria, en máquinas con alrededor de tres veces esa capacidad.

Por qué ARM

Los procesadores Graviton de AWS son chips ARM diseñados por AWS. Por el mismo precio, normalmente obtienes más capacidad que una instancia x86 comparable, o la misma capacidad por menos, y para una carga como la nuestra (servicios Node.js, Docker, Postgres) no hay nada que nos ate a x86.

Trasladamos:

• Dos servidores de aplicación desde instancias x86 de tamaño medio a instancias Graviton pequeñas con 2 GB de RAM cada una.
• La base de datos de la plataforma desde una instancia x86 pequeña a su equivalente Graviton.

La única complicación real: imágenes para dos arquitecturas

Nuestro entorno de staging sigue funcionando en un servidor x86 pequeño. Producción ahora usa ARM. Una imagen de contenedor compilada para una no funciona en la otra.

Así que cada imagen ahora se compila para ambas arquitecturas bajo una misma etiqueta: una imagen multiarquitectura. Docker elige automáticamente la variante correcta en cada máquina, y la canalización de despliegue no necesita saber a qué entorno está enviando. El coste es una compilación de CI más larga; el beneficio es que staging y producción ejecutan exactamente el mismo código desde exactamente la misma etiqueta.

Planificar la vuelta atrás antes del traslado

Cambiar la arquitectura de la CPU bajo un servicio en vivo es el tipo de cambio que conviene poder deshacer en minutos. Antes de cambiar, hicimos lo siguiente:

• conservamos la versión anterior de la plantilla de servidor como objetivo de reversión con nombre,
• hicimos una instantánea de la base de datos justo antes de redimensionarla, y
• escribimos un runbook que cubría el traslado y el camino de vuelta.

No necesitamos la reversión. Aun así, lo haríamos igual.

Qué vigilaremos

Los servidores más pequeños tienen menos margen. De ahí se derivan dos cosas:

1. Si el trabajo pesado vuelve alguna vez a estos servidores, 2 GB no bastarán. La solución entonces será un tamaño Graviton mayor, no volver a x86.
2. Las máquinas pequeñas necesitan swap. Una semana después, uno de estos servidores se congeló por presión de memoria sin quedarse técnicamente sin memoria: la historia del archivo de swap que faltaba.

Lo que aprendimos

• Vuelve a medir tras los cambios de arquitectura. Mover el trabajo a sandboxes cambió lo que necesitaban nuestros servidores; los tamaños de instancia no se habían actualizado.
• ARM es una mejora de bajo riesgo para los stacks web habituales una vez que tus imágenes son multiarquitectura.
• Escribe primero la vuelta atrás. Hace que el cambio sea más tranquilo, aunque nunca la uses.