Varför vi flyttade Mythex servrar till ARM

Den 19 september flyttade vi Mythex produktionsbackend från x86-servrar till mindre ARM-baserade AWS Graviton-servrar, och flyttade plattformens databas till en Graviton-instans också. Anledningen var enkel: efter att vi flyttat det tunga arbetet, att köra och bygga varje användares app, till isolerade sandlådor per projekt, låg våra huvudservrar på en topp om ungefär en tredjedel av sitt minne. Mindre ARM-maskiner passar den verkliga belastningen och minskade den månatliga serverkostnaden med ungefär 30 %.

Vad våra servrar faktiskt gör nu

Tidigare gjorde backend-servrarna mycket arbete direkt. Vid mitten av september hade vi flyttat de dyra delarna, att köra varje projekts kod, installera paket och bygga appar, till privata molnsandlådor, en per projekt. Det är också det som ger varje projekt en egen isolerad miljö och live-förhandsvisning.

Det som stannade på våra egna servrar är samordningen: API:et, orkestratorn som hanterar sandlådor och publicering, autentisering, fakturering och gatewayen. Det arbetet är jämnt och lätt. Efter flytten låg servrarna på en topp runt 1,3 GB minne, på maskiner med ungefär tre gånger så mycket.

Varför ARM

AWS Graviton-processorerna är ARM-chip som AWS själv designat. För samma pengar får du generellt mer kapacitet än en jämförbar x86-instans, eller samma kapacitet för mindre, och för en arbetsbelastning som vår (Node.js-tjänster, Docker, Postgres) finns inget som binder oss till x86.

Vi flyttade:

• Två appservrar från x86-instanser i mellanstorlek till små Graviton-instanser med 2 GB RAM vardera.
• Plattformens databas från en liten x86-databasinstans till dess Graviton-motsvarighet.

Den enda verkliga komplikationen: images för två arkitekturer

Vår staging-miljö körs fortfarande på en liten x86-server. Produktionen kör nu ARM. En container-image byggd för den ena fungerar inte på den andra.

Därför byggs nu varje image för båda arkitekturerna under en tagg, en multi-arch-image. Docker väljer rätt variant på varje maskin automatiskt, och deploy-pipelinen behöver inte veta vilken miljö den pushar till. Kostnaden är ett längre CI-bygge; vinsten är att staging och produktion kör exakt samma kod från exakt samma tagg.

Att planera återgången innan flytten

Att byta CPU-arkitektur under en levande tjänst är just den sortens förändring du vill kunna ångra på några minuter. Innan vi bytte gjorde vi följande:

• behöll den föregående servermallens version som ett namngivet återställningsmål,
• tog en databas-snapshot direkt före databasen ändrade storlek, och
• skrev en runbook som täckte flytten och vägen tillbaka.

Vi behövde inte återställningen. Vi skulle ändå göra det på samma sätt.

Vad vi skulle bevaka

Mindre servrar har mindre marginal. Två saker följer av det:

1. Om tungt arbete någonsin flyttar tillbaka till dessa servrar räcker inte 2 GB. Lösningen då är en större Graviton-storlek, inte att gå tillbaka till x86.
2. Små maskiner behöver swap. En vecka senare frös en av dessa servrar av minnestryck utan att tekniskt sett ta slut på minne. Historien om swap-filen som saknades.

Det vi tog med oss

• Mät om efter arkitekturändringar. Att flytta arbete till sandlådor ändrade vad våra servrar behövde; instansstorlekarna hann inte ikapp.
• ARM är en lågriskvinst för typiska webbstackar när dina images är multi-arch.
• Skriv återställningen först. Den gör ändringen lugnare även om du aldrig använder den.