Por qué trasladamos los servidores de Mythex a ARM

El 19 de septiembre trasladamos el backend de producción de Mythex desde servidores x86 a servidores AWS Graviton, más pequeños y basados en ARM, y también trasladamos la base de datos de la plataforma a una instancia Graviton. El motivo era sencillo: después de mover el trabajo pesado (ejecutar y compilar la app de cada usuario) a entornos aislados por proyecto, nuestros servidores principales llegaban a usar alrededor de un tercio de su memoria en los momentos de máxima carga. Las máquinas ARM más pequeñas se ajustan a la carga real y redujeron la factura mensual de servidores en torno a un 30 %.

Qué hacen ahora nuestros servidores

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

Lo que se quedó en nuestros servidores es la coordinación: la API, el orquestador que gestiona los entornos y las publicaciones, la autenticación, la facturación y el gateway. Ese trabajo es constante y ligero. Tras el traslado, los servidores llegaban a unos 1,3 GB de memoria en máquinas con unas 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 dinero. Y para una carga como la nuestra (servicios Node.js, Docker, Postgres) no hay nada que nos ate a x86.

Trasladamos:

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

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

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

Así que ahora cada imagen se construye para ambas arquitecturas bajo una misma etiqueta: una imagen multiarquitectura. Docker elige automáticamente la variante correcta en cada máquina, y el pipeline 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 producción es el tipo de cambio que conviene poder deshacer en minutos. Antes de cambiar, nosotros:

• conservamos la versión anterior de la plantilla del servidor como objetivo de reversión con nombre,
• hicimos una copia de seguridad de la base de datos justo antes de redimensionarla, y
• escribimos un manual de operaciones que cubría el traslado y el camino de vuelta.

No necesitamos la reversión. Aun así, la 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 a estos servidores, 2 GB no serán suficientes. 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 sacamos de todo esto

• Vuelve a medir después de cambiar la arquitectura. Trasladar trabajo a entornos aislados 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 reversión. Hace el cambio más tranquilo, aunque nunca la uses.