Saturation mémoire après mise en production
Une montée continue de la mémoire jusqu’à l’out of memory, deux causes distinctes, et une production basculée sur une version canary pour résoudre un risque en en acceptant un autre.
Environ deux semaines de production dégradée ou surdimensionnée
Ce que montrait le monitoring après la mise en production
Après la bascule du nouveau SI, la consommation mémoire de la vitrine Next.js montait sans jamais redescendre, jusqu’à l’out of memory. Le processus redémarrait, la mémoire repartait de zéro, et la montée reprenait. Dans le monitoring AWS, cela donnait une courbe en dents de scie parfaitement régulière.
Un effet aggravant se lisait côté back. Next.js maintenait trop de connexions ouvertes vers l’API : il fallait quarante à cinquante workers PHP pour servir une cinquantaine d’utilisateurs connectés. Le rapport entre la charge réelle et les ressources mobilisées n’avait pas de sens.
Pourquoi ajouter des ressources ne réglait rien
La première réponse, en production dégradée, a été de surdimensionner. Elle a fonctionné comme on pouvait s’y attendre : elle a repoussé l’échéance sans rien résoudre. Plus de mémoire signifiait simplement un intervalle plus long entre deux redémarrages.
C’est ce qui a orienté le diagnostic. Une fuite qui grossit avec les ressources qu’on lui donne n’est pas un problème de dimensionnement, c’est un comportement du programme. Nous avons donc arrêté de chercher le bon gabarit d’instance et commencé à chercher ce qui, dans le cycle de vie de l’application, ne libérait jamais.
Les deux causes qu’il a fallu séparer
La première tenait au cache de Next.js. Avant de démarrer une tâche, le framework parcourait l’intégralité de son cache. Ce comportement est invisible sur un petit cache. Sur un cache à plusieurs millions de clés, il devient ruineux, au point de déclencher lui-même des boucles d’out of memory. J’ai travaillé sur la correction de ce comportement. Elle est restée interne : un contributeur avait publié le même correctif en amont cinq à six heures plus tôt. Le diagnostic était donc juste, et confirmé de façon indépendante, mais il n’y a rien à revendiquer côté projet Next.js.
La seconde était un bug de Next.js lui-même, sur lequel nous n’avions pas de prise. Séparer les deux causes a été la partie utile du diagnostic. Tant que deux causes produisent la même courbe, un correctif partiel ne se voit pas dans le monitoring : c’est ce qui rend ce type d’enquête long, et ce qui pousse à conclure trop tôt qu’une piste est mauvaise.
Pourquoi la production tourne sur une version canary
Le seul contournement disponible pour le second point était une version canary de Next.js. Faire tourner une production sur une préversion n’est pas une décision confortable : c’est accepter un risque connu, celui d’une base non stabilisée, pour en résoudre un autre, celui d’un service qui tombe.
L’arbitrage a été rendu dans ce sens. La production tourne toujours sur cette canary. C’est une dette technique assumée, pas un état de fait oublié, et elle a eu des conséquences directes : c’est cette bascule qui a fait apparaître les défaillances décrites dans l’étude de cas sur le remplacement des Server Actions par un BFF.
Ce que la stabilisation a changé
Côté back, le passage à FrankenPHP a nettement réduit la pression sur les workers PHP. Côté front, la correction du parcours de cache et la canary ont mis fin aux boucles d’out of memory.
La période a duré environ deux semaines de production dégradée ou surdimensionnée, avec une surveillance permanente. Après stabilisation, la facture cloud a été divisée par trois.
Ce que je retiens de ce diagnostic
Un symptôme qui recule quand on ajoute des ressources n’est pas un problème de capacité : c’est une information sur la nature du bug, et la traiter comme un problème de capacité coûte du temps et de l’argent. Deuxième point : tant que deux causes produisent la même courbe, aucun correctif ne se valide. Il faut les isoler avant de corriger, même quand la production est en feu et que l’instinct pousse à tout tenter en même temps.