Zašto smo servere Mythexa prebacili na ARM
- rujna prebacili smo produkcijski backend Mythexa s x86 servera na manje ARM servere temeljene na AWS Graviton procesorima, a bazu platforme također na Graviton instancu. Okidač je bio jednostavan: nakon što smo težak posao, pokretanje i izgradnju aplikacije svakog korisnika, premjestili u izolirane sandboxove po projektu, naši glavni serveri vršno su koristili oko trećinu svoje memorije. Manji ARM strojevi odgovaraju stvarnom opterećenju i smanjili su mjesečni račun za servere za otprilike 30%.
Što naši serveri sada rade
Ranije su backend serveri sami obavljali mnogo posla. Oko sredine rujna završili smo premještanje skupih dijelova, pokretanja koda svakog projekta, instaliranja paketa i izgradnje aplikacija, u privatne cloud sandboxove, po jedan za svaki projekt. Upravo zato svaki projekt ima vlastito izolirano okruženje i live pregled.
Na našim serverima ostala je koordinacija: API, orkestrator koji upravlja sandboxovima i objavom, autentikacija, naplata i gateway. Taj posao je stalan i lagan. Nakon premještanja serveri su vršno koristili oko 1,3 GB memorije na strojevima s otprilike tri puta toliko.
Zašto ARM
AWS-ovi Graviton procesori su ARM čipovi koje je dizajnirao AWS. Za isti novac općenito dobivate više kapaciteta nego kod usporedive x86 instance, ili isti kapacitet za manje, a za opterećenje poput našeg (Node.js servisi, Docker, Postgres) ništa nas ne veže za x86.
Prebacili smo:
- Dva aplikacijska servera s instanci srednje veličine na x86 male Graviton instance s 2 GB RAM-a svaka.
- Bazu platforme s male x86 baze na njezin Graviton ekvivalent.
Jedna stvarna komplikacija: slike za dvije arhitekture
Naš staging i dalje radi na malom x86 serveru. Produkcija sada radi na ARM-u. Kontejnerska slika izgrađena za jednu ne radi na drugoj.
Zato se sada svaka slika gradi za obje arhitekture pod jednom oznakom, kao višearhitekturna slika. Docker sam bira ispravnu varijantu na svakom stroju, a deploy pipeline ne mora znati u koje okruženje objavljuje. Cijena je duži CI build; korist je u tome što staging i produkcija pokreću potpuno isti kod s iste oznake.
Planiranje povratka prije premještanja
Promjena CPU arhitekture pod servisom koji radi jedna je od onih promjena koje želite moći poništiti u nekoliko minuta. Prije prebacivanja:
- sačuvali smo prethodnu verziju predloška servera kao imenovanu metu za povrat,
- napravili smo snimku baze neposredno prije promjene veličine baze, i
- napisali smo runbook koji pokriva premještanje i put natrag.
Nismo ga trebali. Ponovno bismo ga napravili na isti način.
Što bismo pratili
Manji serveri imaju manje rezerve. Iz toga slijede dvije stvari:
- Ako se težak posao ikad vrati na ove servere, 2 GB neće biti dovoljno. Tada je rješenje veći Graviton, a ne povratak na x86.
- Mali strojevi trebaju swap. Tjedan kasnije jedan od ovih servera zamrznuo se zbog pritiska na memoriju, a da tehnički nikad nije ostao bez nje: priča o nedostajućoj swap datoteci.
Što smo iz toga izvukli
- Ponovno izmjerite nakon promjena arhitekture. Premještanje posla u sandboxove promijenilo je što su naši serveri trebali, a veličine instanci nisu to pratile.
- ARM je siguran dobitak za tipične web stogove kad su vaše slike višearhitekturne.
- Prvo napišite povrat. Čini promjenu mirnijom, čak i ako ga nikad ne upotrijebite.