Zašto smo prebacili Mythex servere na ARM

Dana 19. septembra prebacili smo produkcioni backend Mythexa sa x86 servera na manje ARM servere zasnovane na AWS Graviton procesorima, a platformsku bazu podataka takođe smo prebacili na Graviton instancu. Okidač je bio jednostavan: pošto smo teške poslove, to jest pokretanje i build svake korisničke aplikacije, preneli u izolovane sandbox-ove po projektu, naši glavni serveri su u vrhuncu koristili oko trećine svoje memorije. Manje ARM mašine odgovaraju stvarnom opterećenju i smanjile su mesečni račun za servere za otprilike 30%.

Šta naši serveri sada zapravo rade

Ranije su backend serveri radili mnogo posla direktno. Oko sredine septembra završili smo prebacivanje skupih delova, pokretanja koda svakog projekta, instaliranja paketa i build-a aplikacija, u privatne cloud sandbox-ove, po jedan za svaki projekat. Upravo to daje svakom projektu sopstveno izolovano okruženje i živi pregled.

Ono što je ostalo na našim serverima jeste koordinacija: API, orkestrator koji upravlja sandbox-ovima i objavljivanjem, autentikacija, naplata i gateway. Taj posao je stabilan i lagan. Posle prebacivanja, serveri su u vrhuncu koristili oko 1,3 GB memorije na mašinama sa otprilike tri puta toliko.

Zašto ARM

AWS-ovi Graviton procesori su ARM čipovi koje je dizajnirao AWS. 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 vezuje za x86.

Prebacili smo:

• Dva aplikaciona servera sa srednjih x86 instanci na male Graviton instance sa po 2 GB RAM-a.
• Platformsku bazu podataka sa male x86 instance baze na njen Graviton ekvivalent.

Jedna prava komplikacija: image-i za dve arhitekture

Naše staging okruženje i dalje radi na malom x86 serveru. Produkcija sada radi na ARM-u. Container image napravljen za jednu arhitekturu neće raditi na drugoj.

Zato se sada svaki image pravi za obe arhitekture pod jednim tagom, to jest multi-arch image. Docker sam bira pravu varijantu na svakoj mašini, a deploy pipeline ne mora da zna u koje okruženje gura. Cena je duži CI build; korist je da staging i produkcija pokreću potpuno isti kod iz potpuno istog taga.

Planiranje rollback-a pre prebacivanja

Promena CPU arhitekture pod živim servisom je promena koju želite da možete da poništite za nekoliko minuta. Pre prebacivanja, mi smo:

• sačuvali prethodnu verziju šablona servera kao imenovani cilj za rollback,
• napravili snimak baze neposredno pre promene veličine baze, i
• napisali runbook koji pokriva prebacivanje i povratak.

Rollback nam nije bio potreban. Ipak bismo ga uradili na isti način.

Na šta bismo obratili pažnju

Manji serveri imaju manje prostora za rezervu. Iz toga slede dve stvari:

1. Ako se teški poslovi ikada vrate na ove servere, 2 GB neće biti dovoljno. Rešenje tada je veća Graviton veličina, a ne povratak na x86.
2. Male mašine trebaju swap. Nedelju dana kasnije jedan od ovih servera se zamrznuo od pritiska na memoriju, iako tehnički nije ostao bez memorije. Priča o nedostajućem swap fajlu.

Šta smo iz ovoga izvukli

• Ponovo merite posle promena arhitekture. Prebacivanje poslova u sandbox-ove promenilo je ono što su serveri trebali, a veličine instanci nisu stigle da se prilagode.
• ARM je nisko-rizičan dobitak za uobičajene web stekove kada su vaši image-i multi-arch.
• Prvo napišite rollback. Čini promenu mirnijom, čak i ako ga nikada ne upotrebite.