« Ça tient en charge » n'est pas une propriété qu'on ajoute après coup. C'est le résultat de quelques décisions d'architecture prises tôt. Voici les patterns qui font la différence entre une appli qui absorbe un pic et une qui tombe au pire moment.
Pré-requis : des services sans état
Le scaling horizontal — ajouter des instances en parallèle — n'est possible que si une requête peut frapper n'importe quelle instance. Donc aucun état local : pas de session en mémoire, pas de fichier sur le disque local. Les sessions vont dans ElastiCache/Redis, les fichiers sur S3. C'est le prérequis non négociable.
Répartir sur plusieurs zones
Une région AWS contient plusieurs Availability Zones (datacenters indépendants). Déployer sur une seule AZ, c'est accepter qu'une panne de datacenter vous coupe. Le minimum sérieux : deux AZ, idéalement trois, derrière un load balancer.
health_check_type = "ELB" est crucial : l'ASG remplace une instance dès qu'elle échoue le health check applicatif, pas seulement quand l'EC2 est éteinte.
Scaler sur la bonne métrique
Le CPU est rarement le bon signal. Pour une API, la métrique qui compte est souvent le nombre de requêtes par instance ou la latence. Le target tracking ajuste la capacité pour maintenir une cible :
Anticiper, pas seulement réagir
L'auto-scaling réactif a un délai : démarrer une instance prend des minutes, parfois trop pour un pic brutal. Deux parades : le scheduled scaling (monter la capacité avant un événement connu — Black Friday, ouverture des soldes) et le predictive scaling qui apprend vos cycles. Pour un pic ponctuel et connu, le scheduled reste le plus sûr.
Tester avant le vrai pic
Une architecture scalable non testée est une hypothèse. Un test de charge (k6, Gatling) qui reproduit le trafic cible valide à la fois la montée en charge et la politique de scaling. C'est le seul moyen de découvrir le goulot — base de données saturée, limite de connexions — avant que vos clients ne le fassent pour vous.
À retenir
- Le scaling horizontal exige des services sans état (sessions et fichiers externalisés).
- Déployez sur au moins 2 AZ, health check de type ELB.
- Scalez sur la métrique métier (req/instance, latence), pas le CPU.
- Pour un pic connu, le scheduled scaling bat le réactif. Et testez avant.