Passer à l’échelle sans exploser la facture

Le point de départ

On part de l'archi e-commerce : EC2 pour le site, RDS pour la base, S3 + CloudFront pour les images. Pour scaler, on ne grossit pas une seule machine à l'infini — on en met plusieurs derrière un load balancer, et on décharge la base.

Grossir puis redescendre

La clé du coût maîtrisé, c'est l'élasticité : ajouter des instances quand le trafic monte, les retirer quand il redescend. On ne paie la capacité de pointe que pendant la pointe.

# auto-scaling : grossir au trafic, redescendre ensuite
resource "aws_autoscaling_policy" "cpu" {
  name        = "scale-on-cpu"
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0   # vise 60% de CPU : au-dela, on ajoute une instance
  }
}

Décharger la base

La base est presque toujours le premier goulot. Avant d'ajouter des serveurs web, on met en cache ce qui est lu en boucle — souvent 80% des requêtes portent sur 20% des données.

// soulager la base : mettre en cache ce qui est lu en boucle
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);      // pas de requete DB
const rows = await db.query("SELECT ...");   // fallback base
await redis.set(key, JSON.stringify(rows), "EX", 60);
return rows;

Garder le coût lié au trafic

Quelle politique de scaling choisir

« Auto-scaling » n'est pas un seul bouton. Il y a plusieurs manières de déclencher l'ajout d'instances, et le choix change le comportement pendant un pic. Sur mon archi e-commerce, je pars presque toujours du target tracking : je fixe une cible — par exemple 50 % de CPU moyen, ou un nombre de requêtes par instance — et EC2 Auto Scaling crée et gère lui-même les alarmes CloudWatch pour tenir cette cible. AWS le recommande explicitement pour scaler sur le CPU moyen ou le nombre de requêtes par cible.

Anticiper le pic prévisible : predictive scaling

Le target tracking est réactif : il attend que le CPU monte pour agir, et une nouvelle instance met une ou deux minutes à démarrer. Pour un pic que je vois venir — soldes du lundi matin, campagne à 18 h — j'ajoute du predictive scaling. Il analyse jusqu'à 14 jours d'historique, en déduit une prévision horaire sur 48 h, et provisionne avant que la charge n'arrive. Deux choses à retenir : il démarre en mode « forecast only » (il prévoit sans scaler, le temps que tu valides), et il ne fait que scaler out — pour redescendre, tu gardes tes politiques dynamiques. Predictive gère le prévisible, target tracking encaisse l'imprévu par-dessus.

L'économie du taux de hit

Un cache n'a de valeur que par son taux de hit : la part des requêtes servies depuis le cache plutôt que depuis l'origine. Ce chiffre n'est pas cosmétique, il pilote directement la facture. À 80 % de hit, seule une requête sur cinq atteint la base ou l'EC2 ; à 95 %, c'est une sur vingt. Passer de 80 à 95 %, ce n'est pas « 15 % de mieux » : c'est diviser par quatre la charge qui arrive derrière — donc potentiellement une read replica en moins ou deux instances EC2 en moins pendant le pic.

Concrètement il y a deux caches à surveiller. Sur ElastiCache/Redis, la documentation AWS sur les métriques à suivre recommande d'alarmer sur les evictions et la mémoire : quand Redis évince des clés faute de place, ton taux de hit chute et la base réencaisse tout. Devant le statique, CloudFront a son propre levier : augmenter le cache hit ratio en allongeant le max-age, en limitant les query strings et cookies pris dans la clé de cache, et en activant Origin Shield comme couche supplémentaire devant l'origine.

Sources & ressources