Scaling horizontal

Ajouter des machines derrière un load balancer. La capacité croît presque linéairement et une panne n'en retire qu'une fraction, mais l'application doit être sans état ou partager son état ailleurs.

Où on le retrouve dans les vrais systèmes

  • Load balancer applicatif

    Il termine le TLS, route selon le chemin ou l'hôte et cesse d'envoyer du trafic à une instance qui échoue à ses health checks. L'algorithme compte : moins-de-connexions absorbe mieux les requêtes inégales que le round robin, et les sessions sticky créent des points chauds.

    En production : AWS Application Load Balancer, NGINX, Envoy, HAProxy, Azure Application Gateway

  • Machine virtuelle

    Le débit augmente avec les vCPU et dépend du runtime : Go sert plusieurs fois plus de requêtes par cœur que Python. Si la mémoire est inférieure aux besoins du runtime, la machine swappe et ralentit fortement. Plusieurs instances derrière un load balancer survivent à la perte de l'une d'elles.

    En production : Amazon EC2, Azure Virtual Machines, Google Compute Engine, OVHcloud Public Cloud

  • Groupe d'auto-scaling

    Des instances sont ajoutées quand le CPU dépasse la cible et retirées quand il baisse. Une nouvelle instance doit se préchauffer avant de recevoir du trafic : un pic soudain fait donc mal, garde assez de capacité minimale. Les instances en panne sont remplacées automatiquement.

    En production : AWS Auto Scaling groups, Azure VM Scale Sets, GCP Managed Instance Groups, Kubernetes HPA

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable