Plateforme de tests de charge Bedrock — ×10 de capacité, −90 % de coût

TL;DR

J’ai reconstruit la plateforme de tests de charge de Bedrock Streaming sur une architecture hybride Amazon EC2 + Amazon ECS, intégrée à Gatling Enterprise Cloud.

Résultat : ~10× plus de capacité pour ~90 % de coût en moins — en traitant le FinOps comme une décision d’architecture, pas comme un sujet finance.

Contexte

Chez Bedrock, les tests de charge ne sont pas optionnels. Avec plus de 20 millions d’utilisateurs hebdomadaires et des dizaines d’équipes qui déploient en continu, la validation des performances fait partie intégrante du cycle de delivery.

Avant mon intervention, les tests vivaient dans deux mondes :

• Des scripts lancés localement par les équipes (parfois via Postman)
• Une plateforme centralisée basée sur Gatling Cloud, mise en place par l’équipe DevOps

L’intention était bonne : fournir une solution managée et scalable. Le problème venait du modèle de provisioning.

Gatling Cloud provisionne des machines éphémères, facturées à la minute, avec des gabarits relativement petits. Il n’y avait aucune corrélation réelle entre “nombre d’utilisateurs simulés” et “nombre de machines nécessaires”. Pour simuler plus d’utilisateurs, il fallait démarrer plus de machines.

Deux limites techniques aggravaient le problème :

1. Les limites de performance des petites instances
2. La limite Linux des ports éphémères par IP (~64 000), qui devient un plafond dur quand on veut simuler énormément de connexions concurrentes depuis une même machine

Pour simuler du trafic réaliste à l’échelle Bedrock, les équipes devaient lancer beaucoup de machines par test. Les coûts augmentaient linéairement avec l’ambition des tests.

Et plus les équipes testaient sérieusement, plus la facture explosait.

Contraintes

Plusieurs contraintes fortes :

• Infrastructure 100 % AWS-native
• 50+ équipes en self-service
• Conservation de Gatling (choix antérieur à mon arrivée)
• Rendre les tests suffisamment peu chers pour que les équipes n’hésitent jamais à en lancer
• Objectifs de très forte concurrence (centaines de milliers à millions d’utilisateurs)
• Pas question de lancer une migration d’outil ou de changer les habitudes des équipes

Ce devait être une optimisation architecture, invisible pour les utilisateurs.

Déclencheur

Aucun incident.

Aucune demande du management.

Juste une trajectoire évidente : plus d’équipes → plus de tests → facture ingérable.

J’ai poussé le sujet de manière proactive avec un argument simple :

Si on ne change rien, on va devoir demander aux équipes de tester moins.

Ce qui est exactement l’inverse de ce qu’on veut sur une plateforme de streaming.

Décision — Pourquoi EC2 + ECS

Gatling Cloud reposait déjà sur ECS + EC2.

Le changement n’a pas été technologique, mais conceptuel :

Arrêter de louer plein de petites machines chez Gatling. Héberger quelques très grosses machines chez nous.

J’ai conçu un modèle hybride :

• Un control plane sur ECS
• De grosses instances EC2 servant de load generators, enregistrées auprès de Gatling Cloud

Au lieu que Gatling provisionne les workers, on fournissait nos propres workers.

Moins de machines. Beaucoup plus puissantes. Beaucoup moins chères.

Ce que j’ai construit

Architecture

Trigger CI / manuel
        │
        ▼
   ECS Control Plane
        │
        ▼
Grosses EC2 Load Generators
        │
        ▼
     Gatling Cloud
        │
        ▼
 Services Bedrock

Le principe clé

Gatling permet d’attacher des load generators externes. J’ai créé un pool de grosses machines EC2 dans notre VPC qui se connectaient à Gatling comme workers.

On est passé :

• d’un modèle provision par test
• à un modèle pool de capacité permanent

Pourquoi ça change tout

Avant :

Plus d’utilisateurs simulés → plus de machines Gatling → coût linéaire

Après :

Plus d’utilisateurs simulés → utilisation du headroom des grosses machines → coût marginal quasi nul

Le rôle d’ECS

ECS hébergeait le control plane qui :

• Gérait l’enregistrement des machines auprès de Gatling
• Gérait leur cycle de vie
• Conservait exactement le même workflow pour les équipes

Pour les équipes : rien ne change. Pour la facture : tout change.

Réalisme réseau

Ces machines étaient dans le réseau Bedrock, avec plusieurs IPs et ENIs, ce qui permettait de contourner les limites de ports par IP qui bloquaient l’ancien modèle.

Le bond de capacité

Avant : plafonnement autour de ~500 000 utilisateurs concurrents Après : capacité à dépasser 2 000 000 utilisateurs concurrents

Non pas parce que Gatling a changé. Parce que l’infrastructure a changé.

Temps d’implémentation

Environ un mois.

Aucune migration côté équipes.

Résultat

Les chiffres

• ~10× plus de capacité
• ~90 % de réduction des coûts

Visible directement sur les factures AWS et Gatling.

Au lieu de payer des dizaines de petites machines éphémères par test, on payait quelques grosses machines en continu.

Effet culturel

Les équipes ont arrêté de se poser la question du coût de leurs tests.

Elles ont pu tester plus, tester plus fort, tester plus longtemps.

Exactement ce qu’on veut en performance engineering.

FinOps comme décision d’architecture

Ce projet illustre parfaitement une conviction forte :

Latence, erreurs et euros par utilisateur doivent vivre sur le même dashboard.

Le problème de coût n’a pas été résolu par de la négociation ou de la sensibilisation. Il a été résolu par un choix d’architecture.

Ce que je ferais différemment

Pas grand-chose.

La solution était volontairement simple et pragmatique, car les contraintes d’outil et de workflow étaient figées.

Avec plus de temps, j’aurais ajouté plus d’observabilité et d’historique autour des runs et de la consommation de ressources, mais la décision d’architecture reste exactement celle que je reprendrais.

---

← Toutes les études de cas