Pourquoi nous avons migré nos serveurs vers ARM

Le 19 septembre, nous avons migré le backend de production de Mythex des serveurs x86 vers des serveurs AWS Graviton, de conception ARM et plus petits, et nous avons aussi déplacé la base de données de la plateforme sur une instance Graviton. Le déclencheur était simple : après avoir déplacé le travail lourd — exécuter et construire l'application de chaque utilisateur — dans des bacs à sable isolés par projet, nos serveurs principaux atteignaient environ un tiers de leur mémoire en pointe. Des machines ARM plus petites correspondent à la charge réelle et réduisent la facture mensuelle des serveurs d'environ 30 %.

Ce que font réellement nos serveurs aujourd'hui

Auparavant, les serveurs backend faisaient beaucoup de travail directement. Vers la mi-septembre, nous avons terminé de déplacer les parties coûteuses — exécuter le code de chaque projet, installer les paquets, construire les applications — dans des bacs à sable cloud privés, un par projet. C'est aussi ce qui donne à chaque projet son environnement isolé et son aperçu en direct.

Ce qui reste sur nos propres serveurs, c'est la coordination : l'API, l'orchestrateur qui gère les bacs à sable et la publication, l'authentification, la facturation et la passerelle. Ce travail est constant et léger. Après le déplacement, les serveurs culminaient autour de 1,3 Go de mémoire, sur des machines qui en ont environ trois fois plus.

Pourquoi ARM

Les processeurs Graviton d'AWS sont des puces ARM conçues par AWS. À prix égal, on obtient généralement plus de capacité qu'avec une instance x86 comparable, ou la même capacité pour moins cher — et, pour une charge comme la nôtre (services Node.js, Docker, Postgres), rien ne nous lie à x86.

Nous avons migré :

• Deux serveurs d'application, de instances x86 de taille moyenne vers de petites instances Graviton de 2 Go de RAM chacune.
• La base de données de la plateforme, d'une petite instance de base de données x86 vers son équivalent Graviton.

La seule vraie complication : des images pour deux architectures

Notre environnement de préproduction tourne toujours sur un petit serveur x86. La production tourne maintenant sur ARM. Une image de conteneur construite pour l'une ne fonctionne pas sur l'autre.

Chaque image est donc maintenant construite pour les deux architectures sous une même étiquette — une image multi-architecture. Docker choisit automatiquement la bonne variante sur chaque machine, et le pipeline de déploiement n'a pas besoin de savoir vers quel environnement il pousse. Le coût est une compilation CI plus longue ; le bénéfice est que la préproduction et la production exécutent exactement le même code à partir de la même étiquette.

Planifier le retour en arrière avant la migration

Changer l'architecture du processeur sous un service en production est le genre de changement qu'on veut pouvoir annuler en quelques minutes. Avant de basculer, nous avons :

• conservé la version précédente du modèle de serveur comme cible de retour nommée,
• pris un instantané de la base de données juste avant de redimensionner la base, et
• rédigé un guide d'exploitation couvrant la migration et le chemin de retour.

Nous n'avons pas eu besoin du retour en arrière. Nous le referions de la même façon.

Ce que nous surveillerions

Les serveurs plus petits ont moins de marge. Deux conséquences :

1. Si du travail lourd revient un jour sur ces serveurs, 2 Go ne suffiront pas. La solution sera alors une taille Graviton plus grande, et non un retour à x86.
2. Les petites machines ont besoin d'un swap. Une semaine plus tard, l'un de ces serveurs s'est figé sous la pression mémoire sans techniquement manquer de mémoire — l'histoire du fichier d'échange manquant.

Ce que nous en avons retenu

• Mesurez à nouveau après un changement d'architecture. Déplacer le travail vers des bacs à sable a modifié ce dont nos serveurs avaient besoin ; la taille des instances n'avait pas suivi.
• ARM est un gain à faible risque pour les piles web habituelles une fois que vos images sont multi-architectures.
• Rédigez le retour en arrière d'abord. Cela rend le changement plus serein, même si vous ne l'utilisez jamais.