Pse e zhvendosëm serverët e Mythex te ARM

Më 19 shtator e zhvendosëm backend-in e prodhimit të Mythex nga serverët x86 te serverët më të vegjël ARM bazuar në AWS Graviton, dhe zhvendosëm edhe bazën e platformës te një instancë Graviton. Shkaku ishte i thjeshtë: pasi zhvendosëm punën e rëndë — ekzekutimin dhe ndërtimin e aplikacionit të çdo përdoruesi — në sandbox-e cloud të izoluara për projekt, serverët tanë kryesorë arrinin pikun me rreth një të tretën e memories së tyre. Makinat më të vogla ARM përshtaten me ngarkesën reale dhe ulën faturën mujore të serverëve me rreth 30%.

Çfarë bëjnë serverët tanë tani

Më parë, serverët backend bënin shumë punë drejtpërdrejt. Rreth mesit të shtatorit e përfunduam zhvendosjen e pjesëve të shtrenjta — ekzekutimin e kodit të çdo projekti, instalimin e paketave, ndërtimin e aplikacioneve — në sandbox-e cloud private, një për projekt. Kjo është edhe ajo që i jep çdo projekti mjedisin e vet të izoluar dhe preview-në live.

Çka mbeti në serverët tanë është koordinimi: API-ja, orkestratori që menaxhon sandbox-et dhe publikimin, autentikimi, faturimi dhe gateway-i. Ky punë është e qëndrueshme dhe e lehtë. Pas zhvendosjes, serverët arrinin pikun në rreth 1.3 GB memorie në makina me rreth tre herë më shumë.

Pse ARM

Procesorët Graviton të AWS janë çipa ARM të projektuar nga AWS. Për të njëjtën kosto, zakonisht merrni më shumë kapacitet sesa një instancë x86 e krahasueshme, ose të njëjtin kapacitet më lirë — dhe për një ngarkesë si e jona (shërbime Node.js, Docker, Postgres) nuk ka asgjë që na lidh me x86.

Zhvendosëm:

• Dy serverë aplikacioni nga instanca x86 të mesme te instanca të vogla Graviton me 2 GB RAM secila.
• Bazën e platformës nga një instancë e vogël bazash x86 te ekuivalenti i saj Graviton.

Komplikimi i vetëm real: image për dy arkitektura

Staging-u ynë ende ekzekutohet në një server të vogël x86. Prodhimi tani është ARM. Një image kontejneri i ndërtuar për njërën nuk ekzekutohet në tjetrën.

Kështu çdo image ndërtohet tani për të dyja arkitekturat nën një tag të vetëm — një image multi-arch. Docker zgjedh automatikisht variantin e duhur në secilën makinë, dhe pipeline-i i deploy-it nuk ka nevojë të dijë në cilin mjedis po shtyn. Kostoja është një ndërtim CI më i gjatë; përfitimi është që staging dhe prodhimi ekzekutojnë saktësisht të njëjtin kod nga saktësisht i njëjti tag.

Planifikimi i rikthimit para zhvendosjes

Ndryshimi i arkitekturës së CPU nën një shërbim aktiv është lloji i ndryshimit që dëshironi ta zhbëni në minuta. Para se të kaloheshim, ne:

• ruajtëm versionin e mëparshëm të template-it të serverit si objektiv rikthimi të emërtuar,
• morëm një snapshot të bazës së të dhënave menjëherë përpara se të ndryshonim madhësinë e bazës, dhe
• shkruam një runbook që mbulon zhvendosjen dhe rrugën e kthimit.

Nuk na nevojitej rikthimi. Do ta bënim prapë në të njëjtën mënyrë.

Çfarë do të shikonim

Serverët më të vegjël kanë më pak hapësirë. Nga kjo rrjedhin dy gjëra:

1. Nëse puna e rëndë ndonjëherë kthehet në këta serverë, 2 GB nuk do të mjaftojnë. Zgjidhja atëherë është një madhësi më e madhe Graviton, jo kthimi te x86.
2. Makinat e vogla kanë nevojë për swap. Një javë më vonë, një nga këta servera ngriu nga presioni i memories pa mbaruar teknikisht memorien — historia e skedarit të mungueshëm swap.

Çfarë nxorëm nga kjo

• Matni sërish pas ndryshimeve të arkitekturës. Zhvendosja e punës në sandbox-e ndryshoi atë që kishin nevojë serverët tanë; madhësitë e instancave nuk ishin përshtatur ende.
• ARM është një fitore me rrezik të ulët për stack-et tipike web kur imazhet tuaja janë multi-arch.
• Shkruani rikthimin para së gjithash. Ai e bën ndryshimin më të qetë, edhe nëse nuk e përdorni kurrë.