Comment faire évoluer une app Node.js sur plusieurs CPUs ?

Question

Accepted Answer

Un processus Node unique utilise uniquement **un seul cœur CPU** (son JS s'exécute sur un seul thread). Pour utiliser tous les cœurs d'une machine, vous exécutez **plusieurs processus Node** — via le module `cluster`, un gestionnaire de processus comme PM2, ou l'orchestration de conteneurs — et équilibrez les charges des requêtes entre eux.

## Le problème

```text
A server with 8 CPU cores running ONE Node process → uses ~1 core, wastes 7.
Need multiple processes to utilize all cores and handle more concurrent load.
```

## Le module cluster — forker des processus worker

```js
import cluster from "cluster";
import { cpus } from "os";
import http from "http";

if (cluster.isPrimary) {
  const numCPUs = cpus().length;
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork(); // spawn one worker process per CPU core
  }
  cluster.on("exit", (worker) => {
    console.log(`worker ${worker.process.pid} died — restarting`);
    cluster.fork(); // restart a crashed worker (resilience)
  });
} else {
  // each worker runs the actual server; the OS load-balances connections across them
  http.createServer((req, res) => res.end("handled by " + process.pid)).listen(3000);
}
```

Le processus primaire crée un worker par cœur ; tous les workers partagent le même port, et les connexions entrantes sont distribuées entre eux — multipliant le débit. Les workers qui plantent peuvent être redémarrés automatiquement pour la résilience.

## En pratique : utiliser PM2 (cluster mode)

```bash
pm2 start app.js -i max   # run one instance per CPU core, with auto-restart & monitoring
```

Les apps de production utilisent généralement **PM2** (ou similaire) plutôt que d'écrire manuellement du code cluster — il gère le forking, l'équilibrage de charge, les rechargements sans temps d'arrêt, la surveillance et les redémarrages.

## Ou évoluer avec conteneurs/orchestration

```text
Run ONE Node process per container, and run MANY containers (Kubernetes, ECS),
with a load balancer in front. This is the modern cloud approach — simpler
per-process model, scaling handled by the orchestrator across machines.
```

## L'avertissement critique : l'absence d'état

```text
Multiple processes don't share memory. So:
⚠️ Don't store sessions/state in process memory → use Redis/a shared store
⚠️ In-memory caches aren't shared across workers → use Redis for shared cache
⚠️ WebSocket connections live on one worker → use a Redis adapter to coordinate
```

Pour que l'évolution multi-processus fonctionne, votre app doit être **sans état** — tout état partagé (sessions, cache, coordination en temps réel) doit résider dans un magasin externe comme Redis, pas en mémoire de processus.

## Pourquoi c'est important

Utiliser tous les cœurs CPU est essentiel pour obtenir les performances complètes d'un serveur Node — un processus unique laisse inactif la plupart d'une machine multi-cœur.

Connaître les options (module cluster, PM2 cluster mode, ou un processus par conteneur avec orchestration) et, crucialmente, l'exigence **d'absence d'état** (sessions/cache/temps réel soutenues par Redis externe, puisque les processus ne partagent pas la mémoire) est fondamental pour faire évoluer Node en production.

Cette évolution horizontale, combinée à l'absence d'état, est la façon dont les apps Node gèrent le trafic élevé de manière fiable.