Hvorfor vi flyttet Mythex sine servere til ARM

Den 19. september flyttet vi Mythex sin produksjonsbackend fra x86-servere til mindre ARM-baserte AWS Graviton-servere, og flyttet også plattformdatabasen til en Graviton-instans. Utløseren var enkel: etter at vi flyttet den tunge jobben, å kjøre og bygge hver brukers app, over i isolerte sandkasser per prosjekt, lå hovedserverne våre på rundt en tredjedel av minnet i toppbelastning. Mindre ARM-maskiner passer den reelle belastningen og kuttet den månedlige serverregningen med omtrent 30 %.

Hva serverne våre faktisk gjør nå

Tidligere gjorde backend-serverne mye arbeid direkte. Rundt midten av september var vi ferdige med å flytte de dyre delene, som kjøring av hvert prosjekts kode, installering av pakker og bygging av apper, over i private skysandkasser, én per prosjekt. Det er også det som gir hvert prosjekt sitt eget isolerte miljø og sin egen levende forhåndsvisning.

Det som ble igjen på våre egne servere, er koordineringen: API-et, orkestratoren som styrer sandkassene og publiseringen, autentisering, fakturering og gatewayen. Det arbeidet er jevnt og lett. Etter flyttingen lå serverne på rundt 1,3 GB minne i toppbelastning, på maskiner med omtrent tre ganger så mye.

Hvorfor ARM

AWS sine Graviton-prosessorer er ARM-brikker designet av AWS. For samme pris får du generelt mer kapasitet enn en tilsvarende x86-instans, eller samme kapasitet for mindre. For en belastning som vår (Node.js-tjenester, Docker, Postgres) er det ingenting som binder oss til x86.

Vi flyttet:

• To appservere fra x86-instanser i mellomstørrelse til små Graviton-instanser med 2 GB RAM hver.
• Plattformdatabasen fra en liten x86-databaseinstans til dens Graviton-ekvivalent.

Den ene reelle komplikasjonen: bilder for to arkitekturer

Staging-miljøet vårt kjører fortsatt på en liten x86-server. Produksjon kjører nå ARM. Et containerbilde bygget for den ene kjører ikke på den andre.

Så hvert bilde bygges nå for begge arkitekturer under én tag, et multi-arch-bilde. Docker velger riktig variant på hver maskin automatisk, og deploy-pipelinen trenger ikke å vite hvilket miljø den pusher til. Prisen er et lengre CI-bygg. Gevinsten er at staging og produksjon kjører nøyaktig samme kode fra nøyaktig samme tag.

Planlegg tilbakerullingen før flyttingen

Å endre CPU-arkitektur under en levende tjeneste er den typen endring du vil kunne angre på minutter. Før vi byttet, gjorde vi følgende:

• beholdt den forrige servermalversjonen som et navngitt mål for tilbakerulling,
• tok et databasesnapshot rett før vi endret størrelsen på databasen, og
• skrev en runbook som dekket flyttingen og veien tilbake.

Vi trengte ikke tilbakerullingen. Vi ville gjort det på samme måte igjen.

Hva vi ville holde øye med

Mindre servere har mindre margin. To ting følger av det:

1. Hvis tung jobb noen gang flyttes tilbake til disse serverne, vil 2 GB ikke være nok. Løsningen da er en større Graviton-størrelse, ikke å gå tilbake til x86.
2. Små maskiner trenger swap. En uke senere frøs en av disse serverne på grunn av minnepress, uten å teknisk sett gå tom for minne. Se historien om den manglende swap-filen.

Det vi tok med oss

• Mål på nytt etter arkitekturendringer. Å flytte arbeid over i sandkasser endret hva serverne våre trengte, og instansstørrelsene hadde ikke fulgt med.
• ARM er en gevinst med lav risiko for vanlige webstacker når bildene dine er multi-arch.
• Skriv tilbakerullingen først. Det gjør endringen roligere, selv om du aldri bruker den.