Hvorfor vi flyttede Mythex' servere til ARM

Den 19. september flyttede vi Mythex' produktionsbackend fra x86-servere til mindre ARM-baserede AWS Graviton-servere og flyttede også platformsdatabasen til en Graviton-instans. Udløseren var enkel: efter at vi havde flyttet det tunge arbejde — kørsel og build af hver brugers app — ind i isolerede sandkasser pr. projekt, lå vores hovedservere på toppen omkring en tredjedel af deres hukommelse. Mindre ARM-maskiner passer til den reelle belastning og sænkede den månedlige serverregning med omkring 30 %.

Hvad vores servere laver nu

Tidligere lavede backend-serverne en masse arbejde direkte. Omkring midten af september var vi færdige med at flytte de dyre dele — kørsel af hvert projekts kode, installation af pakker, build af apps — over i private cloud-sandkasser, én pr. projekt. Det er også det, der giver hvert projekt sit eget isolerede miljø og live preview.

Det, der blev på vores egne servere, er koordineringen: API'et, orkestratoren, der styrer sandkasser og publicering, autentificering, fakturering og gatewayen. Det arbejde er stabilt og let. Efter flytningen lå serverne på toppen omkring 1,3 GB hukommelse på maskiner med cirka tre gange så meget.

Hvorfor ARM

AWS' Graviton-processorer er ARM-chips designet af AWS. For de samme penge får du typisk mere kapacitet end en tilsvarende x86-instans, eller den samme kapacitet for mindre — og for en belastning som vores (Node.js-services, Docker, Postgres) er der intet, der binder os til x86.

Vi flyttede:

• To app-servere fra mellemstore x86-instanser til små Graviton-instanser med 2 GB RAM hver.
• Platformsdatabasen fra en lille x86-databaseinstans til dens Graviton-ækvivalent.

Den ene reelle komplikation: images til to arkitekturer

Vores staging-miljø kører stadig på en lille x86-server. Produktion kører nu ARM. Et container-image bygget til den ene kører ikke på den anden.

Så hvert image bygges nu til begge arkitekturer under ét tag — et multi-arch-image. Docker vælger automatisk den rigtige variant på hver maskine, og udrulningspipelinen behøver ikke vide, hvilket miljø den skubber til. Prisen er et længere CI-build; gevinsten er, at staging og produktion kører præcis den samme kode fra præcis det samme tag.

Planlæg tilbagerulningen, før flytningen

At skifte CPU-arkitektur under en kørende service er den slags ændring, du vil kunne fortryde på minutter. Før vi skiftede, gjorde vi følgende:

• beholdt den forrige servertemplate-version som et navngivet tilbagerulningsmål,
• tog et databasesnapshot lige før vi ændrede størrelsen på databasen, og
• skrev en runbook, der dækkede flytningen og vejen tilbage.

Vi havde ikke brug for tilbagerulningen. Vi ville gøre det samme igen.

Hvad vi ville holde øje med

Mindre servere har mindre råderum. Det har to konsekvenser:

1. Hvis tungt arbejde nogensinde flyttes tilbage til disse servere, er 2 GB ikke nok. Løsningen er så en større Graviton-størrelse, ikke at vende tilbage til x86.
2. Små maskiner har brug for swap. En uge senere frøs en af disse servere på grund af hukommelsespres uden teknisk set at løbe tør for hukommelse — historien om den manglende swap-fil.

Det vi tog med

• Mål igen efter arkitekturændringer. At flytte arbejde ind i sandkasser ændrede, hvad vores servere havde brug for; instansstørrelserne havde ikke fulgt med.
• ARM er en lavrisiko gevinst for typiske webstacks, når dine images er multi-arch.
• Skriv tilbagerulningen først. Det gør ændringen roligere, også selvom du aldrig bruger den.