En bref : le scaling horizontal consiste à ajouter des instances de serveurs pour répartir la charge plutôt qu'à muscler des machines individuelles. C'est le socle d'une architecture cloud fiable et rentable face à un trafic imprévisible, mais il introduit une complexité autour de la gestion de l'état, du load balancing et de la configuration de l'autoscaling que les équipes doivent anticiper avant d'atteindre leurs limites de capacité.
Toute application a un plafond. Pendant un temps, on peut le repousser en améliorant le matériel : plus de CPU, plus de RAM, du stockage plus rapide. Mais à un moment donné, un seul serveur ne suit plus, et le coût de sa mise à niveau dépasse la valeur apportée. La décision bascule alors du scaling vertical vers le scaling horizontal.
Le scaling horizontal, qui consiste à ajouter des serveurs pour se partager la charge plutôt qu'à grossir un serveur unique, est l'architecture qui fait tourner la majorité des applications cloud modernes. C'est ainsi que les applications absorbent les pics de trafic sans s'effondrer, que les équipes mettent en place de la redondance sans exploits d'ingénierie, et que les coûts d'infrastructure restent proportionnels à la demande réelle plutôt qu'aux projections les plus pessimistes.
Ce guide explique le fonctionnement du scaling horizontal, ses cas d'usage pertinents et ses limites, et comment les équipes CloudOps peuvent l'implémenter sur AWS, Google Cloud et Kubernetes sans sacrifier la fiabilité sur l'autel de la complexité.
Qu'est-ce que le scaling horizontal et comment fonctionne-t-il ?
Le scaling horizontal consiste à ajouter des instances d'une ressource pour répartir la charge entre plusieurs nœuds, plutôt qu'à augmenter la capacité d'un seul nœud. Là où le scaling vertical met à niveau un serveur unique (plus de cœurs CPU, plus de mémoire), le scaling horizontal multiplie le nombre de serveurs qui traitent les requêtes. Un load balancer se place devant la flotte et répartit le trafic entrant entre les instances disponibles, afin qu'aucun nœud ne devienne un goulot d'étranglement.
Les mécanismes varient légèrement selon la plateforme, mais le schéma reste constant. Sur AWS, les Auto Scaling Groups surveillent les métriques CloudWatch et lancent ou arrêtent automatiquement des instances EC2 lorsque l'utilisation franchit des seuils définis. Sur Kubernetes, le Horizontal Pod Autoscaler (HPA) surveille l'utilisation CPU et mémoire (ou des métriques personnalisées) et ajuste en conséquence le nombre de pods actifs. Sur Google Cloud, les Managed Instance Groups remplissent la même fonction pour les workloads Compute Engine. Dans chaque cas, une couche de contrôleur prend la décision de scaling à la place de l'équipe d'ingénierie.
Quelles implications en matière de performance et de capacité ?
Le scaling horizontal fait passer le modèle de capacité d'un plafond fixe à une plage dynamique. Un système à scaling vertical atteint une limite stricte lorsque le plus grand type d'instance disponible ne peut plus absorber la charge. Un système à scaling horizontal, correctement configuré, peut continuer à ajouter des instances jusqu'à ce que l'architecture ou le budget bride la croissance.
Le bénéfice en performance se conjugue à la distribution géographique. Déployer des instances sur plusieurs zones de disponibilité signifie qu'une panne dans une zone ne fait pas tomber l'application : le trafic contourne la zone affectée pendant que des instances de remplacement démarrent. Le compromis se situe au niveau de la latence inter-nœuds : des instances distribuées qui doivent communiquer entre elles paient un coût d'aller-retour réseau qu'une configuration mono-serveur évite, ce qui pèse pour les opérations sensibles à la latence.
Quel impact sur les coûts et la gestion des ressources ?
Le scaling horizontal aligne le coût de l'infrastructure sur la demande réelle bien mieux que le scaling vertical. Un serveur à scaling vertical tourne à sa taille provisionnée quel que soit le trafic. Une flotte à scaling horizontal se contracte en heures creuses et s'étend lors des pics, en payant des tarifs on-demand pour la capacité transitoire et des tarifs de réservation pour la base prévisible.
Cet alignement ne tient cependant que si les politiques d'autoscaling sont bien réglées. Des seuils de scale-out mal configurés qui se déclenchent trop tôt, ou des politiques de scale-in qui ne retirent pas les instances assez vite, transforment l'avantage en gaspillage. La tarification basée sur l'engagement pour la flotte de base (AWS Savings Plans, remises d'utilisation engagée sur GCP) combinée à de la capacité de burst on-demand offre à la plupart des équipes le meilleur profil de coût.
Pour les workloads Kubernetes en particulier, le right-sizing des requests et limits des pods compte autant que la politique de scaling elle-même. Des pods aux requests de ressources gonflées bloquent l'efficacité du bin-packing, ce qui oblige le cluster à mobiliser plus de nœuds que le workload n'en exige réellement. DoiT PerfectScale for Kubernetes fait remonter automatiquement ces opportunités de right-sizing, en identifiant les pods dont les requests ne reflètent pas l'utilisation réelle.
Quelle complexité opérationnelle le scaling horizontal introduit-il ?
Plus d'instances, c'est plus de surface à gérer. La dérive de configuration, les patchs sur une flotte, l'agrégation des logs et le tracing distribué deviennent tous plus difficiles à grande échelle que sur un seul serveur. Les équipes qui n'ont pas conçu leur système en ce sens le découvrent vite : quand un bug apparaît sur un type d'instance mais pas sur un autre, ou quand il faut corréler les logs de 40 pods pour tracer une seule requête.
L'outillage infrastructure-as-code (Terraform, Pulumi, CloudFormation) constitue la première ligne de défense. Les patterns d'infrastructure immuable, où les instances sont remplacées à partir d'une image saine plutôt que modifiées en place, éliminent la dérive de configuration. La centralisation des logs et le tracing distribué rendent le débogage multi-instances réellement praticable.
Scaling horizontal ou scaling vertical : comment trancher côté CloudOps ?
Le scaling vertical (scale up) et le scaling horizontal (scale out) ne s'excluent pas mutuellement. La plupart des architectures de production utilisent les deux : des instances correctement dimensionnées pour le workload, au sein d'une flotte à scaling horizontal. La vraie question est de savoir quel levier actionner en premier quand la capacité devient une contrainte.
Le scaling vertical est plus rapide à mettre en œuvre et ne nécessite aucun changement applicatif. On ajoute du CPU et de la mémoire à une instance existante, on redémarre si nécessaire, et c'est terminé. Il fonctionne bien pour les workloads difficiles à distribuer : processus mono-thread, applications aux fortes dépendances d'état, ou systèmes legacy qui n'ont pas été conçus pour un fonctionnement multi-instances. Le plafond reste le plus grand type d'instance disponible, et le coût n'évolue pas proportionnellement à la demande.
Le scaling horizontal suppose une application prête pour cela. Les services stateless, où chaque requête transporte tout le contexte nécessaire au serveur et où aucun état local ne persiste entre les requêtes, se distribuent bien sur un nombre quelconque d'instances. Les services stateful, où l'application stocke localement des données de session ou un état en mémoire, exigent une architecture supplémentaire pour fonctionner correctement sur une flotte.
Pourquoi les applications stateless sont-elles idéales pour le scaling horizontal ?
Les applications stateless sont la cible naturelle du scaling horizontal car n'importe quelle instance peut traiter n'importe quelle requête. Un load balancer peut répartir le trafic en round-robin sur la flotte sans logique de routage au-delà des vérifications de disponibilité. Quand le trafic monte, de nouvelles instances démarrent et prennent immédiatement leur part de charge. Quand il redescend, les instances s'arrêtent sans affecter le moindre état en cours.
La plupart des couches web modernes, des couches API et des microservices sont stateless par conception. Une API REST qui lit dans une base de données partagée n'a que faire de savoir quel serveur traite la requête. Un microservice conteneurisé qui lit depuis une file d'attente et écrit ses résultats dans un object store scale horizontalement sans coordination supplémentaire, et l'autoscaling maintient la capacité proportionnelle à la demande sans intervention manuelle.
Où se situent les difficultés avec les bases de données et workloads stateful ?
Les bases de données et les services stateful ne scalent pas horizontalement par défaut. Une base de données relationnelle tournant sur une instance primaire unique ne peut pas simplement être répliquée sur cinq nœuds en espérant encaisser cinq fois le débit d'écriture. Les lectures peuvent scaler horizontalement via des read replicas, mais les écritures passent toujours par la primaire, ce qui fait des workloads à forte intensité d'écriture un goulot d'étranglement quel que soit le nombre de réplicas.
Les équipes contournent cela en partitionnant l'état dans une couche partagée — une base de données managée, un cache distribué comme Redis, ou un object store — accessible à toutes les instances. Les données de session vont sur Redis ou DynamoDB. Les uploads de fichiers vont sur S3 ou Cloud Storage. Cette architecture à état partagé rend la couche applicative véritablement stateless tout en préservant les données dont elle a besoin.
Sur Kubernetes en particulier, les workloads stateful nécessitant du stockage persistant s'appuient sur des StatefulSets plutôt que sur des Deployments. Les StatefulSets attribuent à chaque pod une identité réseau stable et un persistent volume claim, ce qui compte pour les bases de données, les files d'attente et autres services stateful ordonnés.
Quand le scaling horizontal fonctionne-t-il, et quand échoue-t-il ?
Le scaling horizontal donne sa pleine mesure dans des conditions précises : trafic imprévisible ou en dents de scie, couches applicatives stateless, microservices distribués, et workloads dont les exigences de disponibilité imposent la redondance. Il apporte moins de valeur, voire crée parfois de nouveaux problèmes, dans d'autres conditions.
Les workloads conteneurisés et les microservices y sont les mieux adaptés. Chaque service scale indépendamment selon sa propre demande, ce qui évite qu'un pic sur une partie du système ne surprovisionne le reste. Un cluster Kubernetes qui exécute 20 microservices peut autoscaler chaque service indépendamment, en maintenant une utilisation élevée des ressources partout au lieu de tout dimensionner pour la charge de pointe. Le Kubernetes Horizontal Pod Autoscaler donne aux équipes un contrôle fin sur ces politiques, y compris via des métriques personnalisées au-delà du CPU et de la mémoire.
Les architectures event-driven scalent particulièrement bien à l'horizontal. Une flotte de workers consommant depuis une file d'attente peut s'étendre et se contracter selon la profondeur de file, traiter des bursts sans délai et libérer des instances dès que la file se vide. Des outils comme KEDA (Kubernetes Event-Driven Autoscaling) portent nativement ce pattern dans Kubernetes, en scalant les pods en fonction de sources d'événements externes comme la longueur d'une file SQS ou le retard d'un consumer Kafka.
Quelles décisions de load balancing et de distribution du trafic comptent le plus ?
Le load balancer est le point d'entrée de tout le trafic vers une flotte à scaling horizontal, ce qui fait de sa configuration un facteur direct du comportement applicatif. La distribution round-robin convient aux services stateless où toutes les instances sont équivalentes. Le routage least-connection fonctionne mieux lorsque le temps de traitement des requêtes varie sensiblement, en dirigeant les nouvelles connexions vers l'instance disposant de la plus grande capacité disponible.
Les health checks sont la pièce maîtresse opérationnelle. Un load balancer qui envoie du trafic vers une instance en mauvaise santé annule l'intérêt même d'avoir une flotte. Les health checks doivent tester la véritable disponibilité applicative (un vrai endpoint HTTP qui vérifie que les dépendances répondent) et pas seulement vérifier que l'instance répond à une connexion TCP. Des health checks mal configurés, trop permissifs ou trop stricts, provoquent du flapping et des événements de scaling inutiles.
Comment la gestion des sessions et la cohérence des données influent-elles sur le scaling horizontal ?
La gestion des sessions est souvent l'endroit où les implémentations de scaling horizontal se cassent. Une application qui stocke les données de session en mémoire locale fonctionne très bien sur un serveur unique. Répartie sur une flotte, la deuxième requête du même utilisateur peut atterrir sur une autre instance qui ignore tout de la session précédente, provoquant des échecs d'authentification ou la perte du contenu d'un panier.
La solution consiste à externaliser l'état de session. Redis et Memcached sont les choix standard pour le stockage de sessions distribué. La couche applicative devient véritablement stateless, en lisant et écrivant les données de session dans le cache partagé plutôt qu'en mémoire locale. Toutes les instances voient le même état de session, quelle que soit celle qui traite la requête. Cela ajoute un aller-retour réseau à chaque lecture de session, un compromis raisonnable pour gagner en scalabilité horizontale dans la plupart des applications.
La cohérence des données entre instances distribuées exige une attention de conception explicite pour les workloads à forte intensité d'écriture. Le verrouillage distribué, le contrôle de concurrence optimiste ou les patterns d'event sourcing répondent au problème de coordination selon les exigences de cohérence.
Quelles décisions de monitoring et de configuration d'autoscaling déterminent le succès ?
Les politiques d'autoscaling ne valent que par les métriques qui les pilotent. L'utilisation CPU est la métrique par défaut de la plupart des services d'autoscaling managés, mais c'est un indicateur retardé pour de nombreux workloads. Une application sous pression mémoire ou avec une file d'attente saturée peut afficher une utilisation CPU normale jusqu'au moment où elle s'effondre. Des métriques personnalisées (profondeur de file de requêtes, percentiles de latence de réponse, nombre de connexions actives) offrent aux politiques d'autoscaling des signaux plus précoces et plus précis.
Les politiques de scale-out doivent être agressives : mieux vaut surprovisionner brièvement que laisser un pic de trafic dégrader l'expérience utilisateur. Les politiques de scale-in doivent rester prudentes, avec des périodes de cooldown et des paliers progressifs pour éviter d'arrêter des instances trop vite après un pic. Une flotte qui scale-in trop rapidement lors d'un schéma de trafic qui oscille entre haut et normal va thrasher, en démarrant et arrêtant constamment des instances à perte.
Le guide d'optimisation des coûts Kubernetes détaille comment aligner la configuration de l'autoscaling avec l'efficacité des coûts, y compris les quotas de ressources au niveau namespace et les patterns d'intégration VPA.
Comment implémenter les patterns de scaling horizontal et éviter les pièges courants ?
L'implémentation suit une séquence cohérente quelle que soit la plateforme : valider que l'application est stateless, configurer le scaling group, définir les politiques et tester avant que du trafic de production n'en dépende.
Sur AWS, la stack se compose d'Auto Scaling Groups avec des instances EC2 (ou de tâches ECS pour les workloads conteneurisés), d'un Application Load Balancer et d'alarmes CloudWatch qui pilotent les politiques de scaling. Les décisions de configuration critiques sont les nombres d'instances minimum et maximum, la métrique d'utilisation cible et les périodes de cooldown scale-in/scale-out. Pour une référence de configuration EC2 détaillée, le guide AWS EC2 : coûts, bénéfices et bonnes pratiques traite en profondeur de la sélection d'instances et de l'optimisation des coûts.
Sur Google Cloud, les Managed Instance Groups avec des politiques d'autoscaling et un Global External Application Load Balancer offrent l'équivalent. Les clusters GKE ajoutent par-dessus un autoscaling natif Kubernetes, avec le Cluster Autoscaler qui gère le nombre de nœuds et le HPA qui gère le nombre de pods, indépendamment.
Sur Kubernetes, quel que soit le cloud, l'architecture ajoute une couche d'abstraction. Les Deployments définissent l'état souhaité des pods, le HPA ajuste le nombre de réplicas selon les métriques, et le Cluster Autoscaler ou Karpenter ajuste le nombre de nœuds en fonction de la pression de scheduling des pods. Pour les équipes qui construisent une architecture Kubernetes à partir de zéro, Kubernetes architecture explained constitue une référence utile.
Les pièges les plus courants ne viennent pas de la configuration du scaling elle-même. Ils viennent d'hypothèses applicatives qui cassent en mode distribué : hostnames codés en dur, écritures sur le système de fichiers local, caches en mémoire qui divergent entre instances, et appels synchrones à des services qui ne peuvent pas scaler au même rythme. Repérer ces hypothèses avant la mise en production évite la séance de débogage qui survient sinon en plein pic de trafic.
Les Forward Deployed Engineers de DoiT travaillent directement avec les équipes CloudOps sur ces patterns d'implémentation, en validant les hypothèses architecturales et en configurant des politiques de scaling alignées sur le comportement réel du trafic.
En quoi le scaling horizontal soutient-il des opérations cloud résilientes ?
Le scaling horizontal est l'infrastructure adaptée à la réalité du trafic à laquelle la plupart des applications cloud font face : une demande difficile à prévoir, des pics qui surviennent sans prévenir, et des exigences de disponibilité qui ne tolèrent aucun point unique de défaillance. Une flotte qui s'étend quand le trafic arrive et se contracte quand il passe absorbe cette réalité sans exiger qu'un ingénieur réagisse à chaque événement de scaling.
La maturité opérationnelle qui fait fonctionner le scaling horizontal ne tient pas à un simple changement de configuration. Elle repose sur un ensemble de pratiques : conception applicative stateless, externalisation de la gestion d'état, autoscaling piloté par métriques, infrastructure-as-code et outillage d'observabilité qui rend une flotte distribuée déboguable. Les équipes qui adoptent ces pratiques tôt scalent sans drame. Celles qui les négligent scalent dans les incidents.
DoiT accompagne les équipes CloudOps à chaque étape de ce parcours, de l'architecture initiale d'un cluster Kubernetes au right-sizing et à l'optimisation de l'autoscaling pour des flottes établies. DoiT PerfectScale for Kubernetes analyse en continu les workloads des clusters et fait remonter des recommandations de right-sizing et de scaling, pour que les équipes passent moins de temps à du tuning manuel et plus de temps sur ce qui fait avancer le business. Échangez avec un ingénieur DoiT pour voir comment cette approche s'applique à votre architecture.
Foire aux questions sur le scaling horizontal
Quelle est la différence entre scaling horizontal et scaling vertical ?
Le scaling horizontal ajoute des instances d'une ressource (plus de serveurs, plus de pods, plus de nœuds) pour répartir la charge. Le scaling vertical augmente la capacité d'une instance existante (plus de CPU, plus de RAM). Le scaling horizontal absorbe une demande imprévisible et apporte de la redondance. Le scaling vertical est plus simple à mettre en œuvre, mais bute sur un plafond strict : la taille maximale d'instance disponible.
Quand une équipe CloudOps doit-elle choisir le scaling horizontal plutôt que vertical ?
Le scaling horizontal s'impose pour les couches applicatives stateless, les microservices et les workloads à trafic variable ou imprévisible. Le scaling vertical convient mieux aux processus mono-thread, aux applications legacy qui ne peuvent pas distribuer leur état, ou aux workloads qui ont besoin d'une augmentation rapide de capacité sans changement applicatif. La plupart des architectures de production utilisent des instances correctement dimensionnées (vertical) au sein d'une flotte à scaling horizontal.
Le scaling horizontal réduit-il automatiquement les coûts ?
Non, pas automatiquement. Le scaling horizontal aligne mieux le coût sur la demande qu'un gros serveur fixe, mais uniquement si les politiques d'autoscaling sont bien réglées et si la flotte de base utilise une tarification basée sur l'engagement. Des politiques de scale-in mal configurées qui laissent tourner des instances après une retombée de trafic, ou des seuils de scale-out trop prudents qui exigent une intervention manuelle pendant les pics, érodent le bénéfice en termes de coûts.
Comment Kubernetes gère-t-il le scaling horizontal ?
Kubernetes utilise le Horizontal Pod Autoscaler (HPA) pour ajuster le nombre de réplicas de pods actifs en fonction de l'utilisation CPU, de la mémoire ou de métriques personnalisées. Le Cluster Autoscaler (ou Karpenter sur AWS) ajuste le nombre de nœuds en fonction de la demande de scheduling des pods. Ces deux contrôleurs fonctionnent de concert : le HPA scale la couche applicative, et l'autoscaler de nœuds scale l'infrastructure sous-jacente pour la soutenir.
Quelle est la plus grosse erreur d'implémentation des équipes CloudOps avec le scaling horizontal ?
Supposer que l'application est stateless alors qu'elle ne l'est pas. Les écritures sur le système de fichiers local, le stockage de session en mémoire et les caches en mémoire créent un état caché qui casse dès que les requêtes d'un même utilisateur atterrissent sur des instances différentes. Auditer l'application pour traquer ces hypothèses avant de scaler la flotte évite que ce mode de défaillance n'apparaisse en production.