Waarom we de servers van Mythex naar ARM verhuisden

Op 19 september hebben we de productie-backend van Mythex verhuisd van x86-servers naar kleinere ARM-gebaseerde AWS Graviton-servers, en de platformdatabase ook naar een Graviton-instantie. De aanleiding was eenvoudig: nadat we het zware werk, het draaien en bouwen van elke gebruikersapp, naar geïsoleerde sandboxes per project hadden verplaatst, piekten onze hoofdservers op ongeveer een derde van hun geheugen. Kleinere ARM-machines passen bij de echte belasting en verlaagden de maandelijkse serverrekening met ruwweg 30%.

Wat onze servers nu doen

Eerder deden de backendservers zelf veel werk. Rond half september hebben we de dure onderdelen verplaatst, het draaien van de code van elk project, het installeren van pakketten en het bouwen van apps, naar private cloud-sandboxes, één per project. Dat geeft ook elk project zijn eigen geïsoleerde omgeving en live preview.

Wat op onze eigen servers is gebleven, is de coördinatie: de API, de orchestrator die sandboxes en publicatie beheert, authenticatie, facturatie en de gateway. Dat werk is constant en licht. Na de verhuizing piekten de servers rond 1,3 GB geheugen, op machines met ongeveer drie keer zoveel.

Waarom ARM

De Graviton-processors van AWS zijn ARM-chips die AWS zelf ontwerpt. Voor hetzelfde geld krijg je over het algemeen meer capaciteit dan bij een vergelijkbare x86-instantie, of dezelfde capaciteit voor minder, en voor een werklast als de onze (Node.js-diensten, Docker, Postgres) zit er niets vast aan x86.

We hebben verplaatst:

• Twee app-servers van middelgrote x86-instanties naar kleine Graviton-instanties met elk 2 GB RAM.
• De platformdatabase van een kleine x86-databaseinstantie naar het Graviton-equivalent.

Het ene echte addertje: images voor twee architecturen

Onze stagingomgeving draait nog op een kleine x86-server. Productie draait nu op ARM. Een containerimage die voor de ene is gebouwd, draait niet op de andere.

Daarom wordt elke image nu gebouwd voor beide architecturen onder één tag: een multi-arch-image. Docker kiest automatisch de juiste variant op elke machine, en de deploypipeline hoeft niet te weten naar welke omgeving hij pusht. De prijs is een langere CI-build; het voordeel is dat staging en productie exact dezelfde code uit exact dezelfde tag draaien.

De terugrol vooraf plannen

Het wijzigen van de CPU-architectuur onder een live dienst is het soort wijziging dat je in minuten ongedaan moet kunnen maken. Voordat we overschakelden, hebben we:

• de vorige servertemplateversie bewaard als een benoemd terugrolpunt,
• een databasesnapshot gemaakt vlak voordat we de database formaat wijzigden, en
• een runbook geschreven dat de verhuizing en de weg terug beschrijft.

We hadden de terugrol niet nodig. We zouden het weer zo doen.

Waar we op zouden letten

Kleinere servers hebben minder reserve. Daaruit volgen twee dingen:

1. Als het zware werk ooit weer op deze servers komt, is 2 GB niet genoeg. De oplossing is dan een grotere Graviton-maat, niet terug naar x86.
2. Kleine machines hebben swap nodig. Een week later vroor een van deze servers door geheugendruk, zonder technisch tekort te komen aan geheugen: het verhaal van het ontbrekende swapbestand.

Wat we eruit haalden

• Meet opnieuw na architectuurwijzigingen. Het verplaatsen van werk naar sandboxes veranderde wat onze servers nodig hadden; de instantiematen hadden dat nog niet ingehaald.
• ARM is een laagrisico-winst voor gangbare webstacks zodra je images multi-arch zijn.
• Schrijf de terugrol eerst. Het maakt de wijziging rustiger, ook als je hem nooit gebruikt.