Per què hem mogut els servidors de Mythex a ARM

El 19 de setembre vam moure el backend de producció de Mythex de servidors x86 a servidors AWS Graviton, basats en ARM i més petits, i també vam moure la base de dades de la plataforma a una instància Graviton. El detonant era senzill: després de traslladar la feina pesada (executar i compilar l'app de cada usuari) als sandboxes privats de cada projecte, els nostres servidors principals arribaven a un pic d'aproximadament un terç de la seva memòria. Les màquines ARM més petites s'ajusten a la càrrega real i van reduir la factura mensual dels servidors en aproximadament un 30 %.

Què fan ara els nostres servidors

Fa temps, els servidors del backend feien molta feina directament. Cap a mitjans de setembre vam acabar de traslladar les parts cares (executar el codi de cada projecte, instal·lar paquets, compilar apps) a sandboxes privats al núvol, un per projecte. Això també és el que dona a cada projecte el seu entorn aïllat i la seva previsualització en directe.

El que ha quedat als nostres propis servidors és la coordinació: l'API, l'orquestrador que gestiona els sandboxes i les publicacions, l'autenticació, la facturació i la passarel·la. Aquesta feina és constant i lleugera. Després del trasllat, els servidors arribaven a un pic d'uns 1,3 GB de memòria en màquines amb aproximadament tres vegades aquesta capacitat.

Per què ARM

Els processadors Graviton d'AWS són xips ARM dissenyats per AWS. Pels mateixos diners, normalment obtens més capacitat que una instància x86 comparable, o la mateixa capacitat per menys, i per a una càrrega com la nostra (serveis Node.js, Docker, Postgres) res no ens lliga a x86.

Vam moure:

• Dos servidors d'aplicació d'instàncies x86 de mida mitjana a petites instàncies Graviton amb 2 GB de RAM cadascuna.
• La base de dades de la plataforma d'una petita instància de base de dades x86 a la seva equivalent Graviton.

L'única complicació real: imatges per a dues arquitectures

El nostre entorn de staging encara funciona en un servidor x86 petit. La producció ara funciona en ARM. Una imatge de contenidor compilada per a una no s'executarà a l'altra.

Per això, cada imatge ara es compila per a les dues arquitectures sota una mateixa etiqueta: una imatge multi-arquitectura. Docker tria automàticament la variant adequada a cada màquina, i la canonada de desplegament no necessita saber a quin entorn puja. El cost és una compilació de CI més llarga; el benefici és que staging i producció executen exactament el mateix codi des d'exactament la mateixa etiqueta.

Planificar la reversió abans del trasllat

Canviar l'arquitectura de la CPU sota un servei en viu és el tipus de canvi que vols poder desfer en minuts. Abans de fer el canvi:

• vam conservar la versió anterior de la plantilla de servidor com a objectiu de reversió amb nom,
• vam fer una instantània de la base de dades just abans de redimensionar-la, i
• vam escriure un manual que cobria el trasllat i el camí de tornada.

No vam necessitar la reversió. La faríem igual de la mateixa manera.

Què vigilaríem

Els servidors més petits tenen menys marge. D'això en surten dues coses:

1. Si la feina pesada tornés a estar en aquests servidors, 2 GB no serien suficients. La solució seria llavors una mida Graviton més gran, no tornar a x86.
2. Les màquines petites necessiten swap. Una setmana més tard, un d'aquests servidors es va bloquejar per pressió de memòria sense haver-se quedat tècnicament sense memòria: la història del fitxer de swap que faltava.

Què ens hem endut

• Torna a mesurar després de canvis d'arquitectura. Traslladar la feina als sandboxes va canviar el que necessitaven els nostres servidors; les mides d'instància encara no s'havien posat al dia.
• ARM és un guany de risc baix per als stacks web habituals quan les imatges són multi-arquitectura.
• Escriu la reversió primer. Fa el canvi més tranquil fins i tot si mai no la fas servir.