Kāpēc mēs pārcēlām Mythex serverus uz ARM

1. septembrī mēs pārcēlām Mythex ražošanas backend no x86 serveriem uz mazākiem ARM serveriem AWS Graviton, un platformas datubāzi arī pārcēlām uz Graviton instanci. Iemesls bija vienkāršs: pēc tam, kad smagāko darbu, katra lietotnes lietotāja palaišanu un būvēšanu, pārcēlām uz izolētām projektu smilškastēm, mūsu galvenie serveri sasniedza aptuveni trešdaļu no savas atmiņas. Mazāki ARM serveri labāk atbilst reālajai slodzei un samazina mēneša serveru rēķinu aptuveni par 30%.

Ko mūsu serveri dara tagad

Agrāk backend serveri daudz darba veica tieši. Ap septembra vidu pabeidzām smago daļu pārcelšanu: katra projekta koda palaišanu, pakotņu instalēšanu, lietotņu būvēšanu, uz privātām mākoņa smilškastēm, vienu katram projektam. Tas arī dod katram projektam izolētu vidi un tiešraides priekšskatījumu.

Atlikušais uz mūsu pašu serveriem ir koordinācija: API, orķestrators, kas pārvalda smilškastes un publicēšanu, autentifikācija, norēķini un vārtejas. Šis darbs ir stabils un viegls. Pēc pārcelšanas serveri sasniedza apmēram 1,3 GB atmiņas maksimumu mašīnās ar aptuveni trīskāršu ietilpību.

Kāpēc ARM

AWS Graviton procesori ir ARM mikroshēmas, ko dizainējis AWS. Par tādu pašu naudu parasti dabū vairāk jaudas nekā salīdzināma x86 instance, vai to pašu jaudu lētāk, un mūsu slodzei (Node.js servisi, Docker, Postgres) nav nekā, kas piesaistītu mūs x86.

Mēs pārcēlām:

• Divus lietotņu serverus no vidējām x86 instancēm uz mazām Graviton instancēm ar 2 GB RAM katrā.
• Platformas datubāzi no maza x86 datubāzes instances uz tās Graviton ekvivalentu.

Viena īsta sarežģījuma: attēli divām arhitektūrām

Mūsu stagings vēl darbojas uz maza x86 servera. Ražošana tagad darbojas ARM. Konteinera attēls, kas būvēts vienai, uz otras nedarbosies.

Tāpēc katrs attēls tagad tiek būvēts abām arhitektūrām zem viena taga, multi-arch attēls. Docker katrā mašīnā automātiski izvēlas pareizo variantu, un izvietošanas cauruļvadam nav jāzina, uz kuru vidi tas nosūta. Izmaksa ir garāka CI būve; ieguvums ir tas, ka stagings un ražošana darbina tieši to pašu kodu no tā paša taga.

Atgriešanās plāns pirms pārcelšanas

Arhitektūras maiņa dzīvā pakalpojumā ir tāda lieta, ko vajag varēt atsaukt minūtēs. Pirms pārslēgšanas mēs:

• saglabājām iepriekšējo servera šablona versiju kā nosaukto atgriešanās mērķi,
• uzņēmām datubāzes momentuzņēmumu tieši pirms datubāzes izmēra maiņas, un
• uzrakstījām runbook, kas aptver pārcelšanu un atgriešanos.

Atgriešanās mums nebija vajadzīga. Mēs to tomēr darītu tieši tāpat.

Ko vērot

Mazākiem serveriem ir mazāk rezerves. No tā izriet divas lietas:

1. Ja smagais darbs kādreiz atkal pārvietojas uz šiem serveriem, 2 GB nebūs pietiekami. Tad risinājums ir lielāks Graviton izmērs, nevis atgriešanās pie x86.
2. Maziem serveriem vajag swap. Nedēļu vēlāk viens no šiem serveriem sasala atmiņas spiediena dēļ, neizsmēlis atmiņu tehniski: stāsts par trūkstošo swap failu.

Ko no tā guvām

• Pārmēri pēc arhitektūras izmaiņām. Darba pārcelšana uz smilškastēm mainīja to, ko mūsu serveriem vajag; instanču izmēri vēl nebija pielāgojušies.
• ARM ir zema riska ieguvums tipiskiem tīmekļa stekiem, kad tavi attēli ir multi-arch.
• Vispirms uzraksti atgriešanos. Tas padara izmaiņu mierīgāku, pat ja tu to nekad neizmanto.