Mise à l’échelle et déploiement : répartition de charge, clusters de services backend, blue/green et canary

1. De quoi parle ce cours et pourquoi c’est important

Imaginez que vous avez laissé GiftGenius à l’étape où il vit seul sur Vercel : une instance de MCP‑gateway (qui expose MCP vers l’extérieur et appelle vos services REST), un backend pour les agents, et « ça fonctionne tant bien que mal ». C’est encore acceptable pour un pet‑project et les 100 premiers utilisateurs.

Mais dès qu’OpenAI ajoute votre App au Store et qu’elle se retrouve soudain en sélection d’accueil juste avant Noël, « un seul gateway sur le port 3000 » devient une très mauvaise histoire : file d’appels d’outils, timeouts, erreurs 500, chute de la note dans le Store et emails du marketing du style « pourquoi tout était à terre au pic des ventes ? ».

Notre objectif dans cette leçon est d’apprendre à penser à GiftGenius (et à toute ChatGPT App) comme à un système composé de multiples instances identiques derrière un répartiteur de charge. Et aussi de maîtriser des stratégies de déploiement prudentes et un schéma clair « comment revenir en arrière si quelque chose se passe mal ».

2. Mise à l’échelle horizontale et conception stateless

Commençons par l’idée de base : si votre MCP Gateway ou votre service backend interne conserve un état important en mémoire du processus, il est pratiquement impossible de le mettre correctement à l’échelle horizontalement.

Mise à l’échelle verticale vs horizontale

Commençons par définir la terminologie.

Mise à l’échelle verticale — vous « musclez » un seul serveur : plus de CPU, plus de RAM. C’est rapide, parfois peu coûteux au début, mais il y a une limite dure et cela fait d’une seule instance un single point of failure : si ce monstre tombe, tout tombe.

Mise à l’échelle horizontale — vous lancez plusieurs exemplaires d’un service derrière un équilibrage. Chaque instance est relativement petite, ne garde rien de critique en mémoire, et l’état est externalisé (Postgres, Redis, object storage). Vous pouvez ajouter et retirer des instances selon la charge.

Pour MCP Gateway et les services backend (Gift REST API, Commerce REST API, Analytics Service / REST API, etc.), la mise à l’échelle horizontale est en fait indispensable : ChatGPT peut soudain vous envoyer beaucoup plus de trafic (saison, promo dans le Store, un TikTok viral), et vous devez simplement ajouter des instances, pas « prier pour que le seul serveur tienne ».

Qu’est‑ce qu’un service stateless dans le contexte de MCP Gateway et des backends

Pour que la mise à l’échelle horizontale fonctionne, le service doit être aussi stateless que possible.

Stateless, dans notre contexte, signifie :

• le service ne garde pas en mémoire un état utilisateur unique et de longue durée dont dépend la logique métier ;
• tout état important est stocké dans une base externe, une file, un cache, un stockage type S3 ;
• si une instance tombe, une autre peut continuer à servir l’utilisateur en « récupérant » le contexte dans le stockage externe.

Pour GiftGenius, cela signifie :

• l’historique des sélections de cadeaux, ses likes/dislikes et son panier se trouvent, par exemple, dans Postgres ;
• les files de tâches longues (génération massive de sélections, envoi d’emails de sélection) sont dans un broker de type Redis/Cloud Queue ;
• si vous avez un service séparé pour des workflows d’agents complexes, il stocke ses checkpoints et sa mémoire longue durée dans son propre store, pas dans la RAM d’un processus.

Une instance de MCP Gateway ou de tout service backend devient du « bétail, pas un animal de compagnie » : on peut la tuer et la recréer sans pitié, sans perdre les données métier.

Mini‑exemple : déplacer l’état de la mémoire vers un stockage externe

Supposons que vous ayez un jour écrit un MCP‑tool très simple add_to_cart, qui, via le gateway, appelle une logique interne conservant le panier en mémoire du processus (oui, on le fait parfois dans des démos — et c’est OK tant que vous comprenez que ce n’est pas acceptable en prod) :

// MAUVAIS : panier stocké en mémoire du processus du service backend
const inMemoryCarts = new Map<string, string[]>();

export async function addToCart(userId: string, sku: string) {
  const cart = inMemoryCarts.get(userId) ?? [];
  cart.push(sku);
  inMemoryCarts.set(userId, cart);
  return cart;
}

La mise à l’échelle horizontale est ici impossible : une requête arrive sur l’instance A, une autre sur l’instance B, et l’utilisateur se retrouve avec deux paniers différents.

La bonne approche consiste à externaliser le panier dans une base ou un cache. Schématiquement (très simplifié) :

// BIEN : panier dans un stockage externe
import { db } from "./db";

export async function addToCart(userId: string, sku: string) {
  await db.cartItems.insert({ userId, sku }); // simplifié
  const cart = await db.cartItems.findMany({ where: { userId } });
  return cart;
}

Il n’importe plus quelle instance du service backend traite la requête arrivée via le gateway : le panier est unique pour tous.

3. Répartition de charge : comment le trafic arrive dans les clusters de services backend

Dès que vous avez plus d’une instance d’un service, il faut quelqu’un pour répartir les requêtes entre elles. C’est comme l’ordonnanceur d’une pizzeria populaire : beaucoup de livreurs, beaucoup de clients, et sans logique — c’est le chaos.

L4 vs L7, et pourquoi L7 nous intéresse surtout

Un répartiteur peut opérer à différents niveaux :

• L4 (TCP/UDP) achemine simplement les octets du client vers un des backends, sans vraiment comprendre le protocole ;
• L7 (HTTP) comprend qu’il s’agit d’une requête HTTP, sait regarder le chemin, les en‑têtes, les cookies, parfois même le corps.

Pour une architecture d’App ChatGPT avec MCP Gateway et des services REST, on a presque toujours besoin d’un répartiteur L7 : tout communique en HTTP/SSE, et on veut pouvoir router par chemin, domaine, en‑têtes (par exemple pour les canary releases) et faire des health‑checks.

Health‑checks et retrait des instances « malades » de la rotation

Le répartiteur doit vérifier périodiquement que les instances sont vivantes. Le moyen le plus simple est d’avoir un endpoint GET /health ou /readyz qui renvoie 200 OK si tout va bien.

Dans un service Node/TypeScript qui fonctionne comme MCP Gateway ou backend, un health‑check peut ressembler à ceci :

// apps/gateway/src/http/health.ts
import { type Request, type Response } from "express";

export function healthHandler(req: Request, res: Response) {
  res.json({
    status: "ok",
    version: process.env.RELEASE_ID ?? "dev",
  });
}

Le répartiteur interroge /health toutes les N secondes. Si les réponses deviennent 5xx ou expirent, cette instance est sortie de la rotation et le nouveau trafic ne lui est plus envoyé.

Particularités pour le streaming / SSE

MCP Gateway travaille assez souvent via SSE (Server‑Sent Events), surtout si vous utilisez le streaming de résultats partiels. Le répartiteur doit :

• prendre en charge des connexions HTTP de longue durée ;
• pouvoir compter ces connexions lors du choix de l’instance (certains LB prennent en compte le nombre de connexions actives, pas seulement le RPS).

C’est important, car un seul appel d’outil « bavard » qui stream pendant 2 minutes reste une connexion active. S’il y en a trop sur une instance, il faut temporairement la « décharger » — envoyer les nouvelles connexions ailleurs.

4. Clusters de services backend : séparer par tâches, pas tout mettre en vrac

L’étape logique suivante consiste à ne plus penser à un « gros service backend » unique et à diviser le système en plusieurs clusters en fonction de la nature de la charge et de la criticité.

Exemple d’architecture de GiftGenius par clusters

Tout ce que nous avons rassemblé dans le module 16 recommande le schéma suivant pour GiftGenius :

Au fond, c’est l’application du pattern bulkheads (cloisons) : si le cluster B se met soudain à « brûler du CPU en tokens » lors de la génération de textes complexes, le cluster C de paiement continue de fonctionner, car il a son propre pool de ressources et sa propre mise à l’échelle.

Ce que cela donne via le Gateway

Le MCP Gateway, décrit dans la première leçon du module, voit tout le trafic MCP entrant et le route vers les clusters backend. Par exemple :

• appels d’outils list_gifts, suggest_gifts → cluster A (Gift REST API) ;
• appels d’outils generate_greeting_card ou workflows d’agents complexes → cluster B (service REST des agents ou workers) ;
• outils create_order, confirm_payment → cluster C (Commerce REST API).

Derrière cela, il peut y avoir un répartiteur commun ou plusieurs (par exemple, un L7‑LB dédié devant commerce pour isoler encore plus).

On peut esquisser le schéma global :

flowchart LR
    ChatGPT((ChatGPT))
    GW[MCP Gateway]
    LBA[LB Gift API Cluster A]
    LBB[LB Agents/Workers Cluster B]
    LBC[LB Commerce API Cluster C]

    A1[Gift REST API A-1]
    A2[Gift REST API A-2]
    B1[Agents Service B-1]
    B2[Agents Service B-2]
    C1[Commerce REST API C-1]
    C2[Commerce REST API C-2]

    ChatGPT --> GW
    GW -->|tools: gifts| LBA
    GW -->|agents workflows| LBB
    GW -->|commerce| LBC

    LBA --> A1
    LBA --> A2
    LBB --> B1
    LBB --> B2
    LBC --> C1
    LBC --> C2

Le schéma est légèrement idéalisé, mais reflète le principe essentiel : différents types de charge — différents clusters backend derrière un même MCP Gateway.

5. Stratégies de déploiement : pourquoi blue/green et canary

Passons maintenant à la manière de mettre tout cela à jour sans que les utilisateurs ne le remarquent, et afin que vous dormiez tranquille la nuit.

Anti‑exemple : déployer « par‑dessus » la production

La stratégie la plus simple et la plus dangereuse : vous prenez le cluster en cours (par exemple, le cluster Gift REST API A), vous lancez la nouvelle image par‑dessus l’ancienne, vous remplacez les conteneurs ou redémarrez les processus.

Problèmes potentiels :

• tant qu’une partie des instances est nouvelle et l’autre ancienne, le système peut se comporter de manière imprévisible (surtout si le schéma de BD a changé) ;
• si quelque chose tourne mal, le rollback consiste en un nouveau déploiement « comme avant », ce qui peut prendre des minutes ;
• au moment du déploiement, vous pouvez avoir un court downtime lorsque aucune instance n’est encore levée.

Dans Kubernetes et les PaaS, cela est un peu atténué par les mises à jour rolling, mais l’idée reste la même : sans stratégie claire, vous avez une grande « zone grise » où différentes versions du code traitent le trafic simultanément.

Déploiement Blue/Green : deux environnements et bascule instantanée

Blue/Green — approche dans laquelle coexistent deux environnements quasi identiques : Blue (production actuelle) et Green (nouvelle version).

Schématiquement, le processus ressemble à ceci :

1. Vous déployez la nouvelle version (v2) dans l’environnement Green : même ensemble gateway + clusters backend, mais sans trafic réel pour l’instant.
2. Vous exécutez sur Green tous les tests nécessaires : tests automatiques, smoke tests, vérifications manuelles via le Dev Mode de ChatGPT.
3. Au moment du release, vous basculez le répartiteur/routage pour que 100 % du trafic aille vers Green.
4. Blue continue de vivre à côté comme « piste de secours ». En cas de problème, vous rebasculez en quelques secondes.

Pour GiftGenius, cela peut ressembler à ceci : vous avez mcp-gateway-blue.example.com et mcp-gateway-green.example.com. L’App ChatGPT en prod « pointe » vers l’endpoint MCP officiel (gateway) et, lors du release, vous modifiez la conf DNS/LB pour que le nom de domaine mcp-gateway.example.com pointe vers green.

Avantages :

• bascule instantanée « aller‑retour » ;
• tout problème peut être traité après rollback ;
• pas d’état « moitié cluster en nouveau code, moitié en ancien ».

Inconvénients :

Pendant le release, il faut maintenir deux environnements complets, donc payer ×2 en ressources. On applique donc cette stratégie surtout aux services backend critiques — par exemple, le cluster commerce C et le MCP Gateway lui‑même, où il est hors de question de casser le checkout ou le point d’entrée.

Canary releases : un « canari » dans la mine de charbon

Un canary release est une option plus économique : vous ne levez pas deux productions complètes, vous déployez la nouvelle version progressivement sur une petite part du trafic et vous l’observez de près.

Scénario type :

1. Vous déployez la version v2 du cluster Gift REST API A dans le même pool ou dans un petit pool canari séparé.
2. Vous configurez le répartiteur ou le MCP Gateway pour que, disons, 1 % des appels d’outils liés aux cadeaux aille vers v2, et 99 % — vers v1.
3. Vous regardez les métriques : error rate, latence, métriques métier spécifiques (conversion, checkouts réussis).
4. Si tout va bien — vous augmentez progressivement la part : 1 % → 5 % → 10 % → 50 % → 100 %. Si ça se passe mal — rollback immédiat.

Dans le contexte des ChatGPT Apps, le canary est utile non seulement pour le code, mais aussi pour expérimenter les prompts : une nouvelle version du system prompt pour le service d’agents peut changer radicalement le comportement ; mieux vaut la tester d’abord sur un petit échantillon d’utilisateurs.

Gateway ou le LB peuvent décider quel appel est « canari » selon divers critères :

• au hasard (par exemple, 1 % de toutes les requêtes) ;
• par userId (une partie des utilisateurs entre dans l’expérience de façon persistante) ;
• par un en‑tête ou cookie spécial (pour les tests internes).

Petit exemple de logique de routage en pseudo‑TypeScript (pour illustrer l’idée dans le gateway) :

// Pseudo‑code dans le Gateway : simple random canary 5%
function routeToGiftBackendCluster(ctx: { userId?: string | null }) {
  const rnd = Math.random();
  if (rnd < 0.05) {
    return "gift-api-v2"; // canary
  }
  return "gift-api-v1";   // stable
}

En réalité, vous ne le ferez évidemment pas via Math.random() dans le code runtime, mais vous externaliserez les règles dans une conf/feature flags. La logique reste la même : une partie du trafic va vers les versions canari du service backend, le reste — vers la version stable.

6. Le rollback comme partie obligatoire de la stratégie

J’ai appris il y a longtemps une bonne règle : le rollback doit être plus rapide que le correctif.

Cela signifie que si, après un release, les erreurs pleuvent et que les utilisateurs écrivent « tout casse », il ne faut pas héroïquement corriger le bug en prod. Il faut appuyer sur le gros bouton rouge « rollback ».

Dans des plateformes comme Vercel (sur lesquelles nous avons déjà déployé la partie Next.js de GiftGenius), c’est très naturel : chaque déploiement est un artefact immuable, et Vercel permet de revenir rapidement au précédent.

Pour MCP Gateway et les clusters backend déployés dans Kubernetes ou un autre orchestrateur, ce rôle est rempli par kubectl rollout undo : vous revenez au précédent jeu de pods et d’images.

L’essentiel — journaliser et afficher la version qui sert actuellement le trafic. Par exemple, on peut :

• ajouter version à /health et à d’autres endpoints de diagnostic (nous l’avons déjà fait ci‑dessus) ;
• propager l’identifiant de release dans les en‑têtes des logs (par exemple, X-Release-Id).

Mini‑exemple : route Next.js d’API qui renvoie la version du build pour inspection dans l’App ChatGPT à l’intérieur d’un widget :

// apps/web/app/api/version/route.ts
export async function GET() {
  return Response.json({
    version: process.env.RELEASE_ID ?? "dev",
    builtAt: process.env.BUILT_AT ?? "unknown",
  });
}

Un tel endpoint est utile aussi pour le debug : vous pouvez interroger l’instance de prod pour savoir quelle version tourne exactement, sans vous demander « le dernier build est‑il vraiment déployé ? ».

7. Capacity planning : combien d’instances pour GiftGenius

Nous avons déjà évoqué comment déployer en sécurité (blue/green, canary) et revenir rapidement en arrière en cas de problème. Reste une question pratique : combien d’instances et de quels clusters faut‑il en prod pour encaisser un trafic réel sans exploser les coûts ?

Sans se perdre dans les formules, un peu de calcul s’impose. La mise à l’échelle doit être liée à la charge et à l’économie : combien de requêtes par jour/seconde, combien d’appels LLM lourds, combien cela coûte par jour.

Pour simplifier, raisonnez par ordres de grandeur :

• avec 10k requêtes par jour sur GiftGenius (environ 0,1 RPS en moyenne), vous vivrez facilement avec une à deux instances de MCP Gateway et une paire d’instances Gift REST API/workers Agents ;
• avec 100k requêtes par jour (1–2 RPS en moyenne, plus en pic), il faut déjà 3–5 instances de gateway + du cluster Gift REST API, un cluster B séparé pour les agents lourds et un cluster commerce dédié ;
• avec 1M requêtes par jour (des dizaines de RPS, charges de pointe pendant les fêtes), il vous faudra des clusters, des ressources dédiées pour les agents LLM, un cache agressif et une couche edge (leçon dédiée).

Ce ne sont pas des chiffres stricts, mais une manière de vous pousser à estimer l’ordre de grandeur de la charge et à réfléchir en avance : où sont les goulots, comment vous mettrez à l’échelle, et combien cela coûtera.

Pour GiftGenius, il est particulièrement important de se préparer aux fêtes : Nouvel An, Noël, Saint‑Valentin, Black Friday. La charge peut être multipliée, et vous voulez que le système tienne le choc.

8. Mini‑exemple pratique : évolution du déploiement de GiftGenius

Pour rassembler le tout, traçons une petite évolution du déploiement de GiftGenius.
Nous allons appliquer successivement tout ce que nous avons vu : conception stateless du gateway et des services backend, répartition de charge, clusters séparés et stratégies de release (blue/green, canary).

Niveau de base : un gateway + un backend sur Vercel/Kubernetes

À un moment du cours, vous l’avez déjà fait : une application Next.js avec Apps SDK sur Vercel, à l’intérieur de laquelle vivent l’endpoint MCP et une logique backend simple (Gift/Commerce) dans un seul service. Le tout est assez monolithique.

Avantages évidents : simple, économique, peu d’endroits où se tromper.

Inconvénient : cela ne passe pas à l’échelle pour du trafic sérieux et supporte mal les mises à jour.

Niveau 2 : MCP Gateway séparé + plusieurs clusters backend

Étape suivante :

• vous extrayez MCP Gateway dans un service séparé (Node/Go/NGINX+Lua, peu importe) ;
• vous lancez plusieurs instances de Gift REST API (cluster A) et plusieurs workers/services pour les agents (cluster B) ;
• vous isolez commerce dans un service séparé (cluster C), éventuellement — avec une base/infrastructure dédiée.

Ici, on active déjà un équilibrage L7 classique, des health‑checks et, si possible, une mise à l’échelle horizontale.

Niveau 3 : stratégies de déploiement

À ce niveau, vous ajoutez :

• Blue/Green pour le cluster commerce C (et, si vous le souhaitez, pour MCP Gateway), afin que le checkout et l’authentification restent maximement stables ;
• des releases Canary pour les clusters Gift REST API et le service d’agents, pour expérimenter sereinement de nouvelles versions de tools et d’agents sans risquer de casser toute la prod.

Schématiquement :

flowchart LR
    ChatGPT((ChatGPT))
    GWBlue[Gateway Blue]
    GWGreen[Gateway Green]
    LB[Traffic Switch]

    subgraph Prod
      LB --> GWBlue
      LB -.canary,% .-> GWGreen
    end

    ChatGPT --> LB

En réalité, cela peut être un peu plus complexe (Blue/Green seulement pour commerce, canary seulement pour les clusters gift), mais l’idée est là : vous savez toujours quelle version va où, tout en présentant à ChatGPT un unique point d’entrée MCP (gateway).

9. Petits extraits de code pour le versionnage et le diagnostic

Nous avons déjà vu le health‑endpoint et /api/version. Ajoutons un exemple pour journaliser la version et le cluster dans le handler d’un MCP‑tool côté gateway, afin de « consolider » facilement les métriques.

Imaginons l’outil suggest_gifts, implémenté comme un endpoint REST dans Gift REST API et appelé via le gateway :

import { type McpToolHandler } from "@modelcontextprotocol/sdk";

export const suggestGifts: McpToolHandler<{
  occasion: string;
  budget: number;
}> = async ({ input, meta }) => {
  const releaseId = process.env.RELEASE_ID ?? "dev";
  const clusterId = process.env.CLUSTER_ID ?? "gift-api-A";

  console.log("[suggest_gifts]", {
    releaseId,
    clusterId,
    userId: meta.userId,
    occasion: input.occasion,
  });

  // ici, le MCP Gateway appelle Gift REST API selon une table de routage,
  // et l’outil reste une fine surcouche autour de l’appel REST
  return {
    content: [{ type: "text", text: "Gift ideas..." }],
  };
};

Ici, nous :

• lisons RELEASE_ID et CLUSTER_ID depuis les variables d’environnement ;
• les écrivons dans des logs structurés ;
• pouvons ensuite les utiliser pour l’analyse : « sur quelle version/quel cluster avons‑nous actuellement le plus d’erreurs ? ».

Côté ChatGPT App, tout cela est transparent, mais pour vous en tant que développeur, c’est un énorme plus, surtout avec canary/blue‑green.

10. Erreurs typiques lors de la mise à l’échelle et du déploiement d’une ChatGPT App

Erreur n°1 : stocker l’état de session/utilisateur en mémoire du gateway ou du processus backend.
Cette approche tue la mise à l’échelle horizontale : dès que vous avez une deuxième instance, l’état se « dédouble » entre elles. Particulièrement dangereux : garder en mémoire le panier, les résultats de recherche ou la progression d’un workflow. Tout cela doit vivre dans un stockage externe — BD, cache ou store spécialisé pour l’état d’agent.

Erreur n°2 : penser qu’« un seul serveur puissant » suffit.
La mise à l’échelle verticale est confortable au démarrage, mais fonctionne mal en vraie croissance : limite physique de la machine, un processus devient un single point of failure, et ChatGPT peut amener un pic de trafic imprévisible. Pour MCP Gateway et les clusters backend, il faut presque toujours un design stateless et plusieurs instances derrière un répartiteur.

Erreur n°3 : déployer de nouvelles versions « par‑dessus » la production sans stratégie claire.
Si vous mettez simplement à jour les conteneurs/processus dans le cluster de prod, vous vous retrouvez avec un état intermédiaire où une partie du trafic va vers l’ancienne version et une autre vers la nouvelle, et en cas d’erreur, le rollback devient « redéployer encore ». Bien plus fiable : maintenir deux environnements (blue/green) ou au moins une version canary du service backend recevant une petite part du trafic.

Erreur n°4 : absence de plan de rollback rapide.
Mauvais scénario : le release est passé, les métriques sont rouges, les utilisateurs se plaignent, et vous commencez seulement à réfléchir au rollback. Bon scénario : possibilité préparée à l’avance de rollback instantané (bascule blue/green, rollout undo, Vercel rollback), identifiants de version clairs dans les logs et les health‑endpoints, et règle stricte « rollback d’abord, analyse ensuite ».

Erreur n°5 : un seul cluster « pour tout » sans séparation par type de charge.
Si la génération de textes de félicitations (agents LLM) et le checkout vivent dans un seul cluster, tout problème côté modèles (latences, timeouts, explosion des tokens) peut aussi faire tomber le paiement. La séparation en clusters selon les tâches (Gift REST API / outils légers, service Agents lourd, Commerce REST API) avec des limites/ressources dédiées à chacun est une étape clé vers la résilience.

Erreur n°6 : aucun lien entre l’architecture et l’économie.
On s’emballe vite : « montons encore quelques nœuds », en oubliant que chaque appel LLM et chaque instance coûtent de l’argent. Sans un minimum de capacity planning (évaluation des charges et des coûts), on peut soit sous‑dimensionner et faire tomber la prod, soit sur‑dimensionner et perdre sa marge. Il est utile de relier le nombre de requêtes, le pourcentage d’opérations LLM lourdes et le coût d’hébergement aux métriques business de l’application.