Perché abbiamo spostato i server di Mythex su ARM

Il 19 settembre abbiamo spostato il backend di produzione di Mythex da server x86 a server AWS Graviton basati su ARM, più piccoli, e anche il database della piattaforma su un'istanza Graviton. Il motivo era semplice: dopo aver spostato il lavoro pesante, cioè l'esecuzione e la build di ogni app utente, in sandbox isolate per progetto, i nostri server principali arrivavano al picco di circa un terzo della loro memoria. Macchine ARM più piccole si adattano al carico reale e hanno ridotto la bolletta mensile dei server di circa il 30%.

Cosa fanno oggi i nostri server

In passato i server backend facevano molto lavoro direttamente. Verso metà settembre abbiamo finito di spostare le parti costose, cioè eseguire il codice di ogni progetto, installare pacchetti e costruire le app, in sandbox cloud private, una per progetto. È anche ciò che dà a ogni progetto un ambiente isolato e un'anteprima dal vivo.

Ciò che è rimasto sui nostri server è il coordinamento: l'API, l'orchestratore che gestisce sandbox e pubblicazioni, l'autenticazione, la fatturazione e il gateway. È un lavoro costante e leggero. Dopo lo spostamento, i server arrivavano al picco di circa 1,3 GB di memoria su macchine con circa tre volte tanto.

Perché ARM

I processori Graviton di AWS sono chip ARM progettati da AWS. A parità di costo, di solito ottieni più capacità di un'istanza x86 comparabile, oppure la stessa capacità a meno, e per un carico come il nostro (servizi Node.js, Docker, Postgres) non c'è nulla che ci leghi all'x86.

Abbiamo spostato:

• Due server applicativi da istanze x86 di taglia media a piccole istanze Graviton con 2 GB di RAM ciascuna.
• Il database della piattaforma da una piccola istanza di database x86 al suo equivalente Graviton.

L'unica vera complicazione: immagini per due architetture

Il nostro ambiente di staging gira ancora su un piccolo server x86. La produzione ora gira su ARM. Un'immagine container costruita per una non gira sull'altra.

Quindi ogni immagine ora viene costruita per entrambe le architetture sotto un unico tag: un'immagine multi-architettura. Docker sceglie automaticamente la variante giusta su ogni macchina, e la pipeline di deploy non deve sapere in quale ambiente sta inviando. Il costo è una build CI più lunga; il vantaggio è che staging e produzione eseguono esattamente lo stesso codice dallo stesso tag.

Pianificare il rollback prima dello spostamento

Cambiare l'architettura della CPU sotto un servizio attivo è il tipo di cambiamento che vuoi poter annullare in pochi minuti. Prima del passaggio, abbiamo:

• conservato la versione precedente del modello di server come obiettivo di rollback con nome,
• preso uno snapshot del database immediatamente prima di ridimensionarlo, e
• scritto un runbook che copriva lo spostamento e la via del ritorno.

Non abbiamo avuto bisogno del rollback. Lo faremmo comunque nello stesso modo.

Cosa osserveremo

I server più piccoli hanno meno margine. Da ciò seguono due cose:

1. Se il lavoro pesante tornasse su questi server, 2 GB non basterebbero. La soluzione sarebbe allora una taglia Graviton più grande, non tornare all'x86.
2. Le macchine piccole hanno bisogno di swap. Una settimana dopo, uno di questi server si è bloccato per la pressione sulla memoria senza aver tecnicamente esaurito la memoria: la storia del file di swap mancante.

Cosa ci siamo portati a casa

• Misura di nuovo dopo i cambiamenti di architettura. Spostare il lavoro nelle sandbox ha cambiato ciò di cui i nostri server avevano bisogno; le taglie delle istanze non si erano ancora adeguate.
• ARM è una vittoria a basso rischio per i normali stack web una volta che le tue immagini sono multi-architettura.
• Scrivi prima il rollback. Rende il cambiamento più tranquillo anche se non lo usi mai.