Pourquoi nous avons migré les serveurs de Mythex vers ARM

Le 19 septembre, nous avons migré le backend de production de Mythex des serveurs x86 vers des serveurs AWS Graviton, plus petits et basés sur ARM, et nous avons aussi migré la base de données de la plateforme vers 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 en pointe environ un tiers de leur mémoire. Des machines ARM plus petites correspondent à la charge réelle et réduisent la facture mensuelle des serveurs d'environ 30 %.

Ce que font nos serveurs aujourd'hui

Auparavant, les serveurs backend faisaient beaucoup de travail directement. Vers la mi-septembre, nous avons fini 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 un environnement isolé et un aperçu en direct.

Ce qui est resté 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 stable et léger. Après la migration, les serveurs culminaient autour de 1,3 Go de mémoire, sur des machines disposant d'environ trois fois cette capacité.

Pourquoi ARM

Les processeurs Graviton d'AWS sont des puces ARM conçues par AWS. Pour le même prix, on obtient généralement plus de capacité qu'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 à l'x86.

Nous avons migré :

• Deux serveurs d'application depuis des instances x86 de taille moyenne vers de petites instances Graviton de 2 Go de RAM chacune.
• La base de données de la plateforme depuis une petite instance de base 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 désormais sur ARM. Une image de conteneur construite pour l'une ne fonctionne pas sur l'autre.

Chaque image est donc désormais construite pour les deux architectures sous un même tag — 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 construction CI plus longue ; le bénéfice est que la préproduction et la production exécutent exactement le même code, depuis exactement le même tag.

Préparer le retour 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 arrière nommée,
• pris un instantané de la base de données juste avant de la redimensionner, et
• rédigé un guide d'exploitation couvrant la migration et le chemin inverse.

Nous n'avons pas eu besoin du retour 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 en découlent :

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, pas un retour à l'x86.
2. Les petites machines ont besoin de 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 de swap manquant.

Ce que nous en avons retenu

• Mesurez à nouveau après un changement d'architecture. Déplacer le travail dans des bacs à sable a modifié ce dont nos serveurs avaient besoin ; les tailles d'instance n'avaient pas suivi.
• ARM est un gain à faible risque pour les piles web courantes, une fois vos images multi-architectures.
• Écrivez le retour arrière en premier. Cela rend le changement plus serein, même si vous ne l'utilisez jamais.