Zašto smo Mythex servere preselili na ARM

Dana 19. septembra preselili smo produkcijski backend Mythexa sa x86 servera na manje AWS Graviton servere zasnovane na ARM-u, a bazu platforme takođe na Graviton instancu. Okidač je bio jednostavan: nakon što smo teške poslove, pokretanje i build aplikacije svakog korisnika, preselili u izolovane sandboxe po projektu, naši glavni serveri su u vrhuncu koristili oko trećine memorije. Manje ARM mašine odgovaraju stvarnom opterećenju i smanjile su mjesečni račun za servere za oko 30 %.

Šta naši serveri sada zapravo rade

Ranije su backend serveri radili mnogo posla direktno. Otprilike sredinom septembra završili smo preseljenje skupih dijelova, pokretanja koda svakog projekta, instaliranja paketa i builda aplikacija, u privatne cloud sandboxe, jedan po projektu. To je i ono što svakom projektu daje izolovano okruženje i živi preview.

Ono što je ostalo na našim serverima je koordinacija: API, orkestrator koji upravlja sandboxima i objavljivanjem, autentikacija, naplata i gateway. Taj posao je stabilan i lagan. Nakon preseljenja, serveri su u vrhuncu koristili oko 1,3 GB memorije na mašinama s oko tri puta toliko.

Zašto ARM

Graviton procesori su AWS-ovi ARM čipovi. Za isti novac obično dobijate više kapaciteta nego kod uporedive x86 instance, ili isti kapacitet za manje, a za opterećenje kao što je naše (Node.js servisi, Docker, Postgres) ništa nas ne veže za x86.

Preselili smo:

• Dva aplikativna servera sa srednjih x86 instanci na male Graviton instance s po 2 GB RAM-a.
• Bazu platforme sa male x86 instance baze na njen Graviton ekvivalent.

Jedna prava komplikacija: slike za dvije arhitekture

Naš stejdžing i dalje radi na maloj x86 mašini. Produkcija sada radi na ARM-u. Kontejner slika napravljena za jednu neće raditi na drugoj.

Zato se svaka slika sada gradi za obje arhitekture pod jednim tagom, multi-arch slika. Docker sam bira ispravnu varijantu na svakoj mašini, a deploy pipeline ne mora znati u koje okruženje gura. Cijena je duži CI build; korist je što stejdžing i produkcija rade potpuno isti kod s potpuno istog taga.

Planiranje rollbacka prije preseljenja

Promjena CPU arhitekture pod živim servisom je nešto što želite moći poništiti za nekoliko minuta. Prije prebacivanja:

• sačuvali smo prethodnu verziju šablona servera kao imenovanu metu za rollback,
• napravili smo snimak baze neposredno prije promjene veličine baze, i
• napisali smo runbook koji pokriva preseljenje i povratak.

Rollback nam nije trebao. Ponovo bismo ga uradili na isti način.

Šta smo pratili

Manji serveri imaju manje rezerve. Iz toga slijede dvije stvari:

1. Ako teški poslovi ikada ponovo prijeđu na ove servere, 2 GB neće biti dovoljno. Tada je rješenje veća Graviton veličina, a ne povratak na x86.
2. Male mašine trebaju swap. Sedmicu kasnije jedan od ovih servera se zamrznuo zbog pritiska na memoriju, bez da je tehnički ostao bez memorije. Priča o nedostajućoj swap datoteci.

Šta smo iz toga izvukli

• Ponovo mjerite nakon promjena arhitekture. Preseljenje poslova u sandboxe promijenilo je ono što su serveri trebali; veličine instanci nisu to stigle da prate.
• ARM je siguran dobitak za tipične web stackove kada su vaše slike multi-arch.
• Prvo napišite rollback. Čini promjenu mirnijom, čak i ako ga nikada ne upotrijebite.