Mise à l'échelle de l'infrastructure : horizontale ou verticale, équilibrage de charge et mise à l'échelle automatique

Netflix dessert 260 millions d'abonnés dans 190 pays en mettant à l'échelle dynamiquement des milliers d'instances en fonction de la demande en temps réel. Même si la plupart des entreprises ne fonctionnent pas à l'échelle de Netflix, les principes de mise à l'échelle sont les mêmes : adapter automatiquement la capacité de l'infrastructure à la demande de trafic, sans intervention manuelle et sans payer pour les ressources inutilisées. Les choix que vous faites entre la mise à l'échelle horizontale et verticale, les équilibreurs de charge L4 et L7 et la mise à l'échelle automatique réactive et prédictive déterminent si votre plate-forme se développe gracieusement ou se heurte à un mur.

Points clés à retenir

• Démarrez verticalement (machines plus grandes) pour plus de simplicité, puis passez à l'horizontale (plus de machines) lorsque vous avez besoin d'une haute disponibilité ou dépassez les limites d'une seule machine.
• Les équilibreurs de charge L7 fournissent un routage basé sur le contenu essentiel pour les applications modernes, tandis que les équilibreurs L4 offrent un débit brut pour une distribution TCP simple.
• Les politiques de mise à l'échelle automatique doivent combiner des déclencheurs basés sur des métriques (CPU, mémoire) avec une mise à l'échelle prédictive pour les modèles de trafic connus
• La mise à l'échelle de la base de données suit des règles différentes de celles de la mise à l'échelle des applications : réplicas en lecture pour les charges lourdes en lecture, partitionnement pour les charges lourdes en écriture.

---

Mise à l'échelle horizontale ou verticale

La décision fondamentale en matière de mise à l'échelle est de savoir s'il faut agrandir les machines existantes (verticales) ou en ajouter davantage (horizontalement). Chaque approche comporte des compromis distincts.

Quand effectuer une mise à l'échelle verticale

La mise à l'échelle verticale est le bon premier choix pour plusieurs raisons. Il ne nécessite aucune modification d'application, aucune configuration d'équilibreur de charge et aucune gestion d'état distribuée. Pour les bases de données en particulier, la mise à l'échelle verticale évite la complexité du partitionnement, du décalage de réplication et des transactions distribuées.

Mettez à l'échelle verticalement lorsque :

• Votre application n'est pas encore stateless (sessions stockées en mémoire, écritures sur le système de fichiers)
• Vous exécutez une seule base de données et n'avez pas atteint les limites de connexion ou de CPU
• La taille de l'instance suivante est moins chère que le temps d'ingénierie nécessaire pour passer à l'horizontale
• Vous devez évoluer immédiatement sans modifications architecturales

Arrêtez la mise à l'échelle verticale lorsque :

• Vous avez besoin d'une haute disponibilité (instance unique = point de défaillance unique)
• La plus grande instance disponible ne suffit pas
• Vous payez pour une capacité de pointe qui reste inactive 90 % du temps
• Vous avez besoin d'une répartition géographique pour la latence

Quand effectuer une mise à l'échelle horizontale

La mise à l'échelle horizontale nécessite que votre application soit sans état : toute demande peut être traitée par n'importe quelle instance. Cela signifie :

• Sessions stockées dans Redis ou dans une base de données, pas en mémoire
• Téléchargements de fichiers stockés dans le stockage d'objets (S3), pas sur le disque local
• Pas de configuration spécifique à l'instance ni de mise en cache locale sans réplication
• Gestion gracieuse de la résiliation de l'instance (vérifications de santé, drainage de connexion)

Échelle horizontale lorsque :

• La haute disponibilité est une exigence (votre entreprise ne peut pas tolérer des minutes d'indisponibilité)
• Le trafic est variable et la mise à l'échelle automatique peut réduire les coûts en réduisant pendant les périodes calmes
• Vous devez déployer sans temps d'arrêt (déploiements continus sur plusieurs instances)
• Les exigences de performances dépassent la capacité d'une seule machine

---

Analyse approfondie de l'équilibrage de charge

Un équilibreur de charge répartit le trafic entrant sur plusieurs serveurs backend. Le type d'équilibreur de charge détermine quelles décisions de routage sont possibles.

Équilibrage de charge L4 (couche de transport)

Les équilibreurs de charge L4 fonctionnent au niveau TCP/UDP. Ils acheminent les connexions en fonction de l'adresse IP et du port sans inspecter le contenu des paquets. Ils sont rapides, simples et gèrent n’importe quel protocole basé sur TCP.

Idéal pour : Distribution TCP brute, proxy de connexion à une base de données (PgBouncer), protocoles non HTTP, exigences de débit extrêmement élevées

Limitations : Impossible de prendre des décisions de routage basées sur le chemin de l'URL, les en-têtes ou les cookies. Impossible de mettre fin à SSL (doit être fait sur les backends).

Équilibrage de charge L7 (couche application)

Les équilibreurs de charge L7 fonctionnent au niveau HTTP. Ils inspectent les en-têtes de requête, les URL, les cookies et même les corps de requête pour prendre des décisions de routage. Ils gèrent la terminaison SSL, la compression et peuvent modifier les demandes et les réponses.

Idéal pour : Applications Web, passerelles API, routage basé sur le contenu, terminaison SSL, tests A/B, déploiements Canary

Algorithmes d'équilibrage de charge

Bilans de santé et dégradation gracieuse

Les vérifications de l'état déterminent si un serveur backend doit recevoir du trafic. Configurez-les soigneusement :

• Vérification de santé superficielle : une simple vérification de connexion TCP ou HTTP 200 sur un point de terminaison dédié. Détecte les pannes du serveur mais pas les pannes au niveau de l'application.
• Vérification de l'état approfondie : vérifie la connectivité de la base de données, la disponibilité de Redis et l'accessibilité des services externes. Détecte plus de problèmes mais risque de faux négatifs si une dépendance non critique est en panne.
• Période de grâce -- les nouvelles instances ont besoin de temps pour s'échauffer (compilation JIT, remplissage du cache). Définissez une période de grâce de démarrage avant que l'équilibreur de charge n'envoie l'intégralité du trafic.
• Draining -- lors de la suppression d'une instance, arrêtez d'envoyer de nouvelles requêtes mais laissez les requêtes existantes se terminer (drainage de connexion). Généralement 30 à 60 secondes.

---

## Politiques de mise à l'échelle automatique

La mise à l'échelle automatique ajuste le nombre d'instances en fonction de la demande, en faisant correspondre la capacité au trafic sans intervention manuelle.

Mise à l'échelle basée sur des métriques

L'approche la plus courante déclenche des actions de mise à l'échelle lorsqu'une métrique franchit un seuil.

Mise à l'échelle prédictive

Si votre trafic suit des modèles prévisibles (pics quotidiens, cycles hebdomadaires, événements saisonniers), la mise à l'échelle prédictive provisionne la capacité avant l'arrivée du trafic. AWS Auto Scaling prend en charge la mise à l'échelle prédictive qui apprend des modèles historiques et évolue de manière proactive.

Combinez prédictif et réactif : utilisez la mise à l'échelle prédictive pour les modèles connus (rampe de circulation matinale, pré-approvisionnement du Black Friday) et la mise à l'échelle réactive pour les surtensions inattendues.

Mise à l'échelle des meilleures pratiques

1. Évolution rapide, évolution lente : ajoutez des instances de manière agressive (temps de recharge de 1 à 2 minutes), mais supprimez-les progressivement (temps de recharge de 10 à 15 minutes) pour éviter les battements.
2. Utiliser plusieurs métriques -- mise à l'échelle sur le processeur OU la mémoire OU le nombre de requêtes, en utilisant la première métrique qui se déclenche 3. ** Définissez des limites minimales et maximales ** – empêchez la mise à l'échelle jusqu'à zéro (pas de disponibilité) ou la mise à l'échelle indéfinie (explosion des coûts)
3. Testez la mise à l'échelle pendant les tests de charge : vérifiez que la mise à l'échelle automatique se déclenche correctement et que les nouvelles instances diffusent le trafic dans les délais prévus.
4. Surveiller les événements de mise à l'échelle : alerte en cas de mise à l'échelle fréquente pour détecter les problèmes de configuration ou les problèmes de performances sous-jacents.

---

Stratégies de mise à l'échelle de la base de données

Les bases de données n’évoluent pas horizontalement de la même manière que les serveurs d’applications. Les opérations d'écriture nécessitent un consensus et une forte cohérence limite les options de distribution.

Lire les répliques

Les réplicas en lecture copient les données de la base de données principale et servent les requêtes de lecture. Ils adaptent le débit de lecture de manière linéaire mais n’aident pas au débit d’écriture.

Considérations relatives à la mise en œuvre :

• Délai de réplication : les répliques sont finalement cohérentes. Les requêtes immédiatement après une écriture peuvent ne pas voir le changement. Utilisez le primaire pour les lectures après écritures.
• Routage de connexion : votre application a besoin d'une logique pour acheminer les lectures vers les réplicas et les écritures vers le serveur principal. Les ORM et les proxys de connexion (ProxySQL, PgBouncer) peuvent automatiser cela.
• Failover -- si le serveur principal échoue, un réplica peut être promu. Le basculement automatisé (AWS RDS Multi-AZ, AWS Aurora) réduit les temps d'arrêt à quelques secondes.

Partitionnement des tables

Pour les charges de travail lourdes en écriture sur de grandes tables, le partitionnement divise une table en morceaux physiques plus petits tout en conservant une interface logique unique. Pour des stratégies de partitionnement détaillées, consultez notre guide d'optimisation de base de données.

Regroupement de connexions

Les connexions aux bases de données sont coûteuses à créer et en nombre limité. Les poolers de connexions comme PgBouncer regroupent les connexions de nombreuses instances d'application dans un plus petit nombre de connexions de base de données.

Sans mise en pool : 20 instances d'application x 20 connexions chacune = 400 connexions à la base de données (dépassant probablement les limites de PostgreSQL)

Avec PgBouncer : 20 instances d'application se connectent à PgBouncer, qui maintient 50 à 100 connexions à PostgreSQL, multiplexant efficacement les requêtes.

---

Décomposition des microservices

Lorsqu'un monolithe devient trop volumineux pour qu'une seule équipe puisse le développer et le déployer efficacement, la décomposition des microservices permet une mise à l'échelle indépendante des différents composants.

Quand décomposer

Ne commencez pas par les microservices. Commencez avec un monolithe bien structuré et décomposez-le lorsque :

• Différents composants ont des exigences de mise à l'échelle très différentes (la recherche nécessite 20 instances, la commande en nécessite 5)
• Différentes équipes doivent déployer indépendamment sans coordonner les calendriers de publication
• Un composant spécifique nécessite une pile technologique différente (machine learning en Python, API en Node.js)
• Le temps de déploiement du monolithe dépasse 30 minutes en raison de la taille de la base de code

Que faut-il extraire en premier

---

Questions fréquemment posées

Comment puis-je savoir quand je dois évoluer ?

Surveillez quatre mesures clés : l'utilisation du processeur (constamment au-dessus de 70 %), l'utilisation de la mémoire (au-dessus de 80 %), le temps de réponse P95 (au-dessus de votre SLO) et le taux d'erreur (au-dessus de 0,1 %). Lorsqu’une mesure dépasse systématiquement son seuil, vous devez évoluer. La surveillance proactive avec alertes détecte ces tendances avant que les utilisateurs ne s'en aperçoivent. Consultez notre guide de surveillance.

La mise à l'échelle automatique ou le pré-provisionnement sont-ils plus rentables ?

La mise à l'échelle automatique est plus rentable pour le trafic imprévisible, car vous ne payez pour la capacité que lorsque vous en avez besoin. Le pré-approvisionnement est préférable pour les pics prévisibles (Black Friday, pointes quotidiennes), car la mise à l'échelle automatique prend 3 à 10 minutes pour ajouter de la capacité. L'approche la plus rentable combine les deux : pré-provisionnement pour les pics attendus, mise à l'échelle automatique pour les pics inattendus et utilisation d'instances réservées pour votre capacité de base. Consultez notre guide d'optimisation des coûts du cloud.

Dois-je utiliser des conteneurs (Docker/Kubernetes) ou des VM traditionnelles ?

Les conteneurs démarrent plus rapidement (secondes contre minutes), utilisent les ressources plus efficacement (densité plus élevée par hôte) et fournissent des environnements cohérents pour le développement et la production. Kubernetes ajoute une orchestration (mise à l'échelle automatique, auto-réparation, déploiements continus) mais une complexité opérationnelle importante. Commencez par les services de conteneurs gérés (AWS ECS, Google Cloud Run) avant d'envisager Kubernetes.

Comment gérer le basculement de la base de données sans perte de données ?

Utilisez la réplication synchrone pour un basculement sans perte de données : le serveur principal ne reconnaît pas une écriture tant que le réplica ne la confirme pas. Cela ajoute une latence d'écriture (généralement de 1 à 5 ms dans la même région) mais garantit aucune perte de données lors du basculement. AWS RDS Multi-AZ et Aurora fournissent une réplication synchrone gérée avec basculement automatique.

---

Quelle est la prochaine étape

Évaluez votre infrastructure actuelle par rapport à vos projections de croissance. Si vous utilisez un seul serveur, assurez-vous que votre application est sans état et prête pour une mise à l'échelle horizontale. Si vous exécutez déjà plusieurs instances, optimisez la configuration de votre équilibreur de charge et mettez en œuvre des politiques de mise à l'échelle automatique.

Pour une perspective complète de l'ingénierie des performances, consultez notre guide des piliers sur la mise à l'échelle de votre plateforme commerciale. Pour optimiser les coûts à mesure que vous évoluez, lisez notre guide sur l'optimisation des coûts du cloud.

ECOSIRE conçoit et met en œuvre une infrastructure évolutive pour les plateformes métiers sur des environnements AWS et multi-cloud. Contactez notre équipe DevOps pour une évaluation de la mise à l'échelle de l'infrastructure.

---

Publié par ECOSIRE — aider les entreprises à évoluer grâce à des solutions basées sur l'IA dans Odoo ERP, Shopify eCommerce et OpenClaw AI.