Zakaj smo strežnike preselili na ARM

1. septembra smo produkcijski backend platforme Mythex preselili z x86 strežnikov na manjše strežnike AWS Graviton na osnovi ARM, platformsko bazo pa prav tako na instanco Graviton. Sprožilec je bil preprost: po tem, ko smo težko delo, zagon in gradnjo aplikacij vsakega uporabnika, preselili v izolirane peskovnike za projekte, so bili naši glavni strežniki na vrhuncu porabljali približno tretjino pomnilnika. Manjši ARM stroji ustrezajo dejanski obremenitvi in so mesečni strežniški račun znižali za približno 30 %.

Kaj naši strežniki zdaj dejansko počnejo

Prej so backend strežniki veliko delali neposredno. Sredi septembra smo končali selitev dragih delov, torej zagona kode vsakega projekta, nameščanja paketov in gradnje aplikacij, v zasebne oblačne peskovnike, po enega na projekt. Prav to daje vsakemu projektu lastno izolirano okolje in živ predogled.

Na naših strežnikih je ostalo usklajevanje: API, orkestrator, ki upravlja peskovnike in objavljanje, avtentikacija, obračunavanje in prehod (gateway). To delo je enakomerno in lahko. Po selitvi so strežniki na vrhuncu porabljali okoli 1,3 GB pomnilnika na strojih s približno trikrat toliko.

Zakaj ARM

Procesorji AWS Graviton so ARM čipi, ki jih je zasnoval AWS. Za enak denar običajno dobite več zmogljivosti kot pri primerljivi x86 instanci ali enako zmogljivost ceneje. Za obremenitev, kot je naša (Node.js storitve, Docker, Postgres), nič ne veže na x86.

Preselili smo:

• dva aplikacijska strežnika iz srednje velikih x86 instanc na majhne instance Graviton z 2 GB RAM-a vsaka,
• platformsko bazo z majhne x86 baze podatkov na njen ustrezni Graviton.

Edina prava zapletenost: slike za dve arhitekturi

Naše stagin okolje še vedno teče na majhnem x86 strežniku. Produkcija zdaj teče na ARM. Container slika, zgrajena za eno, na drugi ne bo delovala.

Zato je vsaka slika zdaj zgrajena za obe arhitekturi pod eno oznako, torej kot večarhitekturna (multi-arch) slika. Docker na vsakem stroju samodejno izbere pravo različico, deploy pipeline pa ni treba vedeti, v katero okolje potiska. Cena je daljši CI build, korist pa je, da staging in produkcija poganjata popolnoma isto kodo iz popolnoma iste oznake.

Načrtovanje povratka pred selitvijo

Spreminjanje arhitekture procesorja pod živo storitvijo je tip spremembe, ki jo želite lahko razveljaviti v nekaj minutah. Pred preklopom smo:

• ohranili prejšnjo različico predloge strežnika kot poimenovan cilj za povratek,
• pred spreminjanjem velikosti baze naredili posnetek baze podatkov in
• napisali runbook, ki pokriva selitev in pot nazaj.

Povratka nismo potrebovali. Naredili bi ga enako še enkrat.

Na kaj bi pazili

Manjši strežniki imajo manj rezerve. Iz tega sledita dve stvari:

1. Če se težko delo kdaj spet preseli na te strežnike, 2 GB ne bo dovolj. Rešitev je takrat večja velikost Graviton, ne vrnitev na x86.
2. Majhni stroji potrebujejo swap. Teden kasneje je eden od teh strežnikov zamrznil zaradi pritiska na pomnilnik, čeprav tehnično ni zmanjkalo pomnilnika. Zgodba o manjkajoči swap datoteki.

Kaj smo iz tega izvlekli

• Po spremembah arhitekture ponovno izmerite. Selitev dela v peskovnike je spremenila, kaj naši strežniki potrebujejo, velikosti instanc pa niso sledile.
• ARM je nizkotvegaten dobiček za tipične spletne sklade, ko so vaše slike večarhitekturne.
• Najprej napišite povratek. Tudi če ga nikoli ne uporabite, naredi spremembo mirnejšo.