De ce am mutat serverele Mythex pe ARM

Pe 19 septembrie am mutat backend-ul de producție al Mythex de pe servere x86 pe servere AWS Graviton mai mici, bazate pe ARM, și am mutat și baza de date a platformei pe o instanță Graviton. Declanșatorul a fost simplu: după ce am mutat munca grea — rularea și construirea fiecărei aplicații a utilizatorilor — în sandbox-uri izolate pe proiect, serverele noastre principale ajungeau la un vârf de aproximativ o treime din memorie. Mașinile ARM mai mici se potrivesc sarcinii reale și reduc factura lunară pentru servere cu aproximativ 30%.

Ce fac acum serverele noastre

Mai devreme, serverele backend făceau multă muncă direct. În jurul mijlocului lui septembrie am terminat de mutat părțile costisitoare — rularea codului fiecărui proiect, instalarea pachetelor, construirea aplicațiilor — în sandbox-uri cloud private, câte unul pentru fiecare proiect. Tot acesta este și ce dă fiecărui proiect propriul mediu izolat și preview-ul live.

Ce a rămas pe serverele noastre este coordonarea: API-ul, orchestratorul care gestionează sandbox-urile și publicarea, autentificarea, facturarea și gateway-ul. Această muncă este constantă și ușoară. După mutare, serverele ajungeau la un vârf de aproximativ 1,3 GB de memorie, pe mașini cu de trei ori mai mult.

De ce ARM

Procesoarele Graviton ale AWS sunt cipuri ARM proiectate de AWS. Pentru același preț, de obicei obții mai multă capacitate decât o instanță x86 comparabilă, sau aceeași capacitate mai ieftin — iar pentru o sarcină ca a noastră (servicii Node.js, Docker, Postgres) nu avem nimic care să ne lege de x86.

Am mutat:

• Două servere de aplicații de la instanțe x86 de dimensiune medie la instanțe Graviton mici, cu câte 2 GB RAM fiecare.
• Baza de date a platformei de la o instanță mică de baze de date x86 la echivalentul ei Graviton.

Singura complicație reală: imagini pentru două arhitecturi

Mediul nostru de staging rulează încă pe un server x86 mic. Producția rulează acum pe ARM. O imagine de container construită pentru una nu rulează pe cealaltă.

Așadar, fiecare imagine este acum construită pentru ambele arhitecturi sub un singur tag — o imagine multi-arch. Docker alege automat varianta potrivită pe fiecare mașină, iar pipeline-ul de deploy nu trebuie să știe în ce mediu împinge imaginea. Costul este un build CI mai lung; beneficiul este că staging-ul și producția rulează exact același cod, din exact același tag.

Planificarea rollback-ului înainte de mutare

Schimbarea arhitecturii procesorului sub un serviciu live este genul de schimbare pe care vrei să o poți anula în câteva minute. Înainte să trecem, am:

• păstrat versiunea anterioară a șablonului de server ca țintă de rollback cu nume,
• făcut un snapshot al bazei de date chiar înainte să redimensionăm baza, și
• scris un runbook care acoperă mutarea și drumul înapoi.

Nu ne-a trebuit rollback-ul. Tot așa l-am face din nou.

Ce am urmări

Serverele mai mici au mai puțin spațiu de manevră. Din asta decurg două lucruri:

1. Dacă munca grea se mută vreodată înapoi pe aceste servere, 2 GB nu vor fi suficienți. Soluția atunci este o dimensiune Graviton mai mare, nu întoarcerea la x86.
2. Mașinile mici au nevoie de swap. O săptămână mai târziu, unul dintre aceste servere a înghețat din cauza presiunii pe memorie, fără să fi rămas tehnic fără memorie — povestea fișierului de swap lipsă.

Ce am învățat

• Re-măsoară după schimbările de arhitectură. Mutarea muncii în sandbox-uri a schimbat ce aveau nevoie serverele noastre; dimensiunile instanțelor nu se mai potriveau.
• ARM este un câștig cu risc redus pentru stack-urile web obișnuite, odată ce imaginile tale sunt multi-arch.
• Scrie rollback-ul primul. Face schimbarea mai liniștită, chiar dacă nu îl folosești niciodată.