tadata
← Retour à l'accueil

Conception Système & Scalabilité : les patterns qui fonctionnent

#architecture#scalability#system-design#distributed-systems

La scalabilité ne consiste pas à gérer des millions de requêtes au jour un. C'est concevoir des systèmes qui peuvent croître sans nécessiter une réécriture. Les meilleures architectures font du scaling un changement de configuration, pas un projet d'ingénierie.

Scaling Horizontal vs Vertical

DimensionHorizontal (Scale Out)Vertical (Scale Up)
MécanismeAjouter des instancesAugmenter les ressources
Limite hautePratiquement illimitéePlafond matériel
Courbe de coûtLinéaire (par nœud)Exponentielle (matériel premium)
ComplexitéPlus haute (état distribué)Plus basse (machine unique)
Temps d'arrêtZéro (mises à jour progressives)Souvent nécessaire (redimensionnement)
Cohérence des donnéesNécessite coordinationPlus simple (instance unique)
Rayon d'impact panneUn nœudSystème entier
Quand utiliserServices sans état, couche webBases de données, workloads en mémoire
tadata
PEAK DEMAND 1,800 → 12 instances INSTANCE-STEPS (COST) 67 UNDER-PROVISIONED 0 steps OVER-PROVISIONED 1 step 0 1,620 3,240 1 2 3 4 5 6 7 8 9 10 10 min Instances 2 3 6 10 12 12 8 8 3 3 Utilisation % 60 60 60 60 60 57 60 30 53 47 demand capacity = instances × capacity target × capacity under-provisioned held by cooldown Wanted instances = ⌈demand ÷ (capacity per instance × target)⌉ = ⌈demand ÷ (250 × 0.6)⌉, kept between min 2 and max 12;utilisation = demand ÷ (instances × capacity). Scale-out happens at once, scale-in waits 2 steps after the last change.
PEAK DEMAND 1,800 → 12 instances INSTANCE-STEPS (COST) 67 UNDER-PROVISIONED 0 steps OVER-PROVISIONED 1 step 0 1,620 3,240 1 2 3 4 5 6 7 8 9 10 10 min Instances 2 3 6 10 12 12 8 8 3 3 Utilisation % 60 60 60 60 60 57 60 30 53 47 demand capacity = instances × capacity target × capacity under-provisioned held by cooldown Wanted instances = ⌈demand ÷ (capacity per instance × target)⌉ = ⌈demand ÷ (250 × 0.6)⌉, kept between min 2 and max 12;utilisation = demand ÷ (instances × capacity). Scale-out happens at once, scale-in waits 2 steps after the last change.
Un groupe Auto Scaling lors d'un pic matinal (req/s par pas de 10 minutes) : le scale-out suit la demande, le scale-in attend la fin du cooldown, le maximum de 12 est atteint au pic. Les pas sous-provisionnés se traduisent en latence ; relevez le maximum ou ajoutez du scaling prédictif.

Extrait de la fiche « SAA-C03 Resilient 1: Compute, ELB, Auto Scaling » · Demander la fiche complète

tadata
Hop added latency (ms) 0 20 40 60 1 Browser cache memory / disk 0.5 ms fresh copy? no request at all 2 CDN edge PoP edge.cdn.example (Paris) 8 ms TLS ends here; WAF, bot rules, cache lookup 3 Origin shield shield.cdn.example (Frankfurt) 18 ms WARN second cache tier, protects the origin 4 Load balancer lb.shop.internal 30 ms new TLS or plain HTTP inside the VPC (virtual private cloud) 5 Application server 10.0.2.15:8080 55 ms renders the page, sets Cache-Control
Hop added latency (ms) 0 20 40 60 1 Browser cache memory / disk 0.5 ms fresh copy? no request at all 2 CDN edge PoP edge.cdn.example (Paris) 8 ms TLS ends here; WAF, bot rules, cache lookup 3 Origin shield shield.cdn.example (Frankfurt) 18 ms WARN second cache tier, protects the origin 4 Load balancer lb.shop.internal 30 ms new TLS or plain HTTP inside the VPC (virtual private cloud) 5 Application server 10.0.2.15:8080 55 ms renders the page, sets Cache-Control
Une requête à travers un CDN (latences indicatives). La réponse DNS pour shop.example.com pointe vers l'edge le plus proche, pas vers l'origine ; un cache hit s'arrête au saut 2 ; un miss passe par l'origin shield puis l'origine, dont la véritable IP ne doit accepter que le trafic venant du CDN, sinon les attaquants contournent le WAF (web application firewall) en s'y connectant directement

Extrait de la fiche « How the Web Works for Security People (part 2) » · Demander la fiche complète

Comparaison des stratégies de load balancing

StratégieAlgorithmeIdéal pourCompromis
Round RobinDistribution séquentielleInstances homogènesIgnore les différences de charge
Least ConnectionsVers le moins occupéDurées de requête variablesLégèrement plus de surcharge
PondéréProportionnel à la capacitéInstances de tailles mixtesConfiguration manuelle requise
IP HashConstant par clientSessions persistantesRisque de distribution inégale
Temps de réponse minVers le plus rapideApps sensibles à la latenceNécessite monitoring
tadata
Users (HTTPS) ALB listener 443, ACMcertificate, WAF EC2 AZ a target group web, port 8080 EC2 AZ b healthy EC2 AZ c unhealthy → replaced by ASG auto-scale 3–12 RDS Multi-AZ + ElastiCache sessions Balancing • Algorithm: round robin or least outstanding requests • Health check: HTTP GET /health 200, every 30 s, 5 OK / 2 fail • Sessions: sticky cookie AWSALB (duration) or app cookie
Users (HTTPS) ALB listener 443, ACMcertificate, WAF EC2 AZ a target group web, port 8080 EC2 AZ b healthy EC2 AZ c unhealthy → replaced by ASG auto-scale 3–12 RDS Multi-AZ + ElastiCache sessions Balancing • Algorithm: round robin or least outstanding requests • Health check: HTTP GET /health 200, every 30 s, 5 OK / 2 fail • Sessions: sticky cookie AWSALB (duration) or app cookie
Instances dans des sous-réseaux privés, nœuds ALB dans des sous-réseaux publics des mêmes AZ. Stockez les sessions dans ElastiCache ou DynamoDB pour que n'importe quelle instance puisse servir n'importe quel utilisateur et que l'affinité de session devienne optionnelle.

Extrait de la fiche « SAA-C03 Resilient 1: Compute, ELB, Auto Scaling » · Demander la fiche complète

Checklist de planification de capacité

PhaseActionOutil / Méthode
MesurerBaseline du débit actuel (RPS, P99)Tests de charge (k6, Locust)
ModéliserProjections de croissance (3, 6, 12 mois)Métriques métier + historique
IdentifierTrouver le goulot (CPU, mémoire, I/O, réseau)Profiling, APM
TesterTest de charge à 2x le pic projetéTests en staging
PlanifierDéfinir les seuils de déclenchement du scalingMétriques HPA, alarmes CloudWatch
BudgeterEstimer le coût à l'échelle projetéeCalculateurs de prix cloud, FinOps
ReviserRevue mensuelle capacité vs réelDashboard + revue des alertes

Principes clés

Concevoir pour 10x, construire pour 3x. L'architecture doit supporter 10x conceptuellement. Implémentez l'infrastructure pour 3x. Cela évite le sur-engineering tout en gardant un chemin de croissance clair.

Le sans-état est le fondement. Chaque pattern de scaling devient plus facile quand les services sont sans état. Déplacez les sessions vers Redis, les uploads vers le stockage objet, les données persistantes vers des bases gérées.

L'invalidation du cache est la partie difficile. Ajouter un cache est facile. Savoir quand l'invalider est le vrai défi. Préférez des TTL courts à une logique d'invalidation complexe.

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.