Load Balancer Scaleway : répartir le trafic et survivre à la panne d'un backend

Une règle PAT envoie le trafic vers une machine ; un load balancer l'envoie vers un service, et continue quand une machine meurt. Toute la différence tient dans le health check, ce test répété qui décide si une machine mérite encore du trafic. Cette leçon construit un Load Balancer devant deux Instances qui n'ont aucune adresse publique, prouve que la répartition fonctionne, puis coupe volontairement l'une des deux pour mesurer, en secondes, le temps que met la panne à être écartée. Vous en repartirez avec les réglages du health check, la décision d'accessibilité qu'on ne peut plus reprendre, et la commande de suppression qui évite de laisser une adresse facturée derrière vous.

Ce que vous allez apprendre

• Enchaîner Load Balancer, backend et frontend, dans l'ordre que l'API impose.
• Prouver la répartition entre deux machines sans adresse publique.
• Mesurer le temps de détection d'une panne, et le régler en connaissance de cause.
• Choisir entre accessibilité publique et privée avant que ce soit définitif.
• Supprimer sans laisser une adresse réservée qui continue de courir.

Que faut-il construire pour qu'un load balancer serve du trafic ?

Trois objets, dans cet ordre, et aucun ne fonctionne seul. C'est la première source de confusion du produit : créer le Load Balancer ne suffit pas, il ne répond à rien tant que la chaîne n'est pas complète.

Objet	Rôle	Ce qu'il exige avant lui
Load Balancer	la machine managée et son adresse publique	rien
Backend	le groupe de serveurs, l'algorithme et le health check	le Load Balancer
Frontend	le port d'écoute, et le backend par défaut	le backend

Glissez pour voir

Un quatrième geste conditionne tout le reste quand les backends sont privés : rattacher le Load Balancer au réseau privé. Sans ce rattachement, il connaît les adresses de vos machines mais n'a aucune route pour les joindre, et tous les backends restent obstinément en panne.

Construire l'ensemble

Le point de départ est un réseau privé qui porte déjà deux Instances sans adresse publique, chacune servant une page qui l'identifie. Le montage du réseau privé et de la passerelle d'administration est celui de la leçon précédente, Public Gateway.

1. Créez le Load Balancer et attendez qu'il soit prêt.

   PN=$(scw vpc private-network list name=demo-pn region=fr-par -o json \
     | jq -r '.private_networks[0].id')
   LB=$(scw lb lb create name=demo-lb type=LB-S zone=fr-par-1 -o json | jq -r .id)
   scw lb lb get "$LB" zone=fr-par-1 -o json

   La sortie doit afficher "status":"ready" après une à deux minutes, et un tableau ip contenant une adresse IPv4. Avant cela, le statut passe par pending.

2. Rattachez-le au réseau privé, faute de quoi il ne joindra aucun backend.

   scw lb private-network attach "$LB" private-network-id="$PN" zone=fr-par-1 -o json

   La sortie doit afficher le rattachement avec son private_network_id. Laissez-lui une vingtaine de secondes avant de créer le backend.

3. Relevez les adresses privées de vos Instances. Comme pour la passerelle, elles appartiennent à la carte réseau, pas au serveur :

   scw ipam ip list private-network-id="$PN" region=fr-par -o json

   La sortie doit contenir une entrée par carte, de type instance_private_nic. Sur le lab du 11 septembre 2026, ce furent 172.16.16.2 et 172.16.16.3.

4. Créez le backend, avec son algorithme et son health check.

   BACK=$(scw lb backend create lb-id="$LB" name=demo-back \
     forward-protocol=http forward-port=80 forward-port-algorithm=roundrobin \
     health-check.port=80 health-check.check-delay=3s \
     health-check.check-timeout=1s health-check.check-max-retries=2 \
     health-check.http-config.uri=/ health-check.http-config.method=GET \
     health-check.http-config.code=200 \
     server-ip.0=172.16.16.2 server-ip.1=172.16.16.3 \
     zone=fr-par-1 -o json | jq -r .id)
   scw lb backend get "$BACK" zone=fr-par-1 -o json

   La sortie doit afficher "pool":["172.16.16.2","172.16.16.3"] et un objet health_check reprenant vos valeurs en millisecondes.

5. Créez le frontend, qui ouvre enfin le port d'écoute.

   FRONT=$(scw lb frontend create lb-id="$LB" backend-id="$BACK" \
     name=demo-front inbound-port=80 zone=fr-par-1 -o json | jq -r .id)
   scw lb frontend get "$FRONT" zone=fr-par-1 -o json

   La sortie doit afficher "inbound_port":80. Comptez une trentaine de secondes avant que le trafic passe réellement.

Comment vérifier que la répartition fonctionne vraiment ?

En comptant, pas en regardant. Une poignée de requêtes à la main donne une impression ; vingt requêtes comptées donnent une preuve. Chaque machine sert une page qui porte son nom, ce qui rend la répartition observable depuis l'extérieur.

for i in $(seq 1 20); do curl -s "http://<adresse-du-lb>/"; echo; done | sort | uniq -c

Le résultat du lab du 11 septembre 2026 avec scw 2.62.0 est sans appel : dix réponses web1 et dix réponses web2 sur vingt requêtes, une alternance parfaite. C'est le comportement attendu de l'algorithme roundrobin, qui envoie chaque nouvelle connexion au serveur suivant, comme un tourniquet. Retenez surtout ce que cette sortie démontre en creux : les deux machines ont été créées avec ip=none et ne portent aucune adresse publique. Elles sont injoignables depuis Internet, elles n'ont même pas de route d'entrée, et le service qu'elles rendent est pourtant public. C'est exactement l'architecture qu'on cherche, et elle ne coûte pas plus cher que la mauvaise : une seule adresse publique, celle du Load Balancer, au lieu d'une par machine.

Combien de temps pour qu'une panne soit détectée ?

Cinq secondes sur le lab, et ce chiffre se calcule avant de se mesurer. C'est la question qui décide vraiment entre un load balancer et une simple redirection de port : que se passe-t-il quand une machine tombe ?

Le protocole est brutal et parlant. On coupe le serveur web d'une des deux machines, puis on interroge le Load Balancer jusqu'à ce qu'il cesse de répondre avec cette machine :

# sur la machine web1, via le bastion
pkill -f http.server

Avec les réglages du backend créé plus haut, à savoir un intervalle de 3 secondes, un timeout d'une seconde et deux échecs consécutifs avant bascule, le retrait de la rotation a été observé au bout de 5 secondes. Le calcul tombe juste : deux vérifications espacées de trois secondes, la première échouant presque immédiatement.

La remise en service est plus rapide encore. Le serveur web relancé, la machine est revenue dans la rotation en 2 secondes. La documentation officielle explique l'asymétrie : il faut franchir le seuil d'échecs pour être déclaré en panne, mais plus de deux succès consécutifs seulement pour revenir.

Le calcul à faire avant de choisir vos valeurs

Le délai de détection vaut approximativement intervalle × nombre d'échecs tolérés. Trois secondes et trois échecs, les valeurs par défaut, donnent donc environ neuf secondes d'aveuglement, pendant lesquelles une part de vos requêtes part vers une machine morte.

Descendre ces valeurs raccourcit la fenêtre mais multiplie les vérifications, donc la charge sur vos backends et la consommation de processeur du Load Balancer. L'intervalle minimal est de 1000 ms, le timeout minimal aussi.

Comment régler un health check qui ne ment pas ?

Un health check trop simple déclare saine une machine qui ne sert plus rien. Un test TCP se contente d'ouvrir une connexion : un serveur web dont la base de données est tombée y répondra parfaitement, et continuera de recevoir du trafic qu'il ne peut pas honorer.

Type de test	Ce qu'il prouve	Quand le choisir
TCP	le port accepte une connexion	dernier recours, ou protocole non couvert
HTTP	une URL répond avec le code attendu	dès que le service parle HTTP
MySQL, PGSQL	la base répond au protocole	bases managées ou auto-hébergées
LDAP, Redis	le service répond à sa commande de test	annuaires et caches

Glissez pour voir

Le réglage qui compte le plus est le chemin HTTP. Viser / teste que le serveur répond ; viser une route applicative comme /health, qui vérifie les dépendances de votre application, teste que le service fonctionne. La différence se paie le jour d'une panne partielle.

Trois pièges documentés qui rendent un test faux

Les redirections ne sont pas suivies. Un 301 ou un 302 renvoyé sur le chemin du health check n'amène pas le Load Balancer sur la cible : le test échoue, puisque le code reçu ne vaut pas celui attendu. Un serveur qui redirige tout vers HTTPS rendra donc ses backends en panne si le test vise HTTP.

Le test PGSQL est buggé au-delà de PostgreSQL 14. La documentation le dit elle-même et recommande un test TCP pour ces versions, le temps qu'un correctif arrive.

Le test MySQL exige un réglage côté serveur. À partir de MySQL 8.0, mysql_native_password n'est plus activé par défaut et doit l'être ; à partir de MySQL 9.0, ce test n'est plus supporté du tout.

Public ou privé : la décision qu'on ne reprend pas

L'accessibilité d'un Load Balancer se fige à sa création et ne se modifie jamais. C'est la phrase la plus importante de la documentation du produit, et elle tient en une ligne : la changer impose de recréer le Load Balancer, donc de changer d'adresse et de basculer le DNS.

	Load Balancer public	Load Balancer privé
Adresse publique	obligatoire en IPv4, IPv6 en option	aucune
Joignable depuis	Internet, et les réseaux privés rattachés	les réseaux privés rattachés seulement
Certificats Let's Encrypt	oui	non, certificats importés uniquement
Backends hors Scaleway	oui, sur les gabarits lb-gp-l et lb-gp-xl	non
Réseaux privés rattachables	8	8

Glissez pour voir

Le Load Balancer privé répond au besoin qu'on oublie : répartir du trafic entre services internes, sans jamais l'exposer. Il se joint par un nom stable de la forme nom-du-lb.nom-du-reseau.internal, la même convention que les Instances, ce qui évite de coder une adresse en dur.

Limites, quotas et plafonds

Ces valeurs viennent de la page officielle des limitations, validée le 6 mai 2026. Le tableau se lit par la colonne des connexions simultanées, souvent plus contraignante que le débit.

Gabarit (doc)	Gabarit (API)	Débit	Connexions simultanées	Prix horaire
LB-S	lb-s	200 Mbps	20 000	0,023 €
LB-M	lb-gp-m	500 Mbps	50 000	0,054 €
LB-L	lb-gp-l	1 Gbps	160 000	0,094 €
LB-XL	lb-gp-xl	4 Gbps	3 000 000	0,941 €

Glissez pour voir

Prix relevés au catalogue public le 10 septembre 2026 en fr-par-1, par nœud. Quatre limites de configuration s'y ajoutent, identiques quel que soit le gabarit : 300 frontends, 300 backends, 300 ACL et 200 certificats par Load Balancer. Une dernière contrainte se rencontre rarement mais surprend quand elle tombe : un Load Balancer ne maintient pas plus de 50 000 sessions TCP vers un même couple serveur et port.

Les noms de gabarits ne sont pas les mêmes partout

La documentation écrit LB-M, LB-L et LB-XL ; l'API et le CLI répondent lb-gp-m, lb-gp-l et lb-gp-xl. Seul le plus petit porte le même nom des deux côtés. Un script écrit d'après la documentation échouera donc sur les trois autres. Fiez-vous à la sortie de scw lb lb-types list, qui donne les noms que l'API accepte réellement.

Et n'oubliez pas ce que ce produit ne fait pas : l'UDP n'est pas supporté. Tout ce qui n'est pas basé sur TCP doit passer par une autre porte.

Le load balancer sous l'angle Well-Architected

Reliability : votre répartiteur est-il lui-même un point de rupture ?

La question clé : si le Load Balancer tombe, que se passe-t-il, et combien de temps ?

Scaleway déclenche automatiquement un réplica et reroute l'adresse flexible vers lui, ce qui rend la bascule transparente pour vos clients. En revanche le Load Balancer reste zonal : il tombe avec sa zone, et son adresse avec lui.

La discipline : régler le health check sur une route qui teste vraiment le service, pas sur /, et savoir si votre disponibilité cible tolère la perte d'une zone entière. Si non, le doublon se décide à la conception, pas pendant l'incident.

Security : combien de machines exposez-vous derrière ce service ?

La question clé : vos backends ont-ils une adresse publique, et si oui, pourquoi ?

Le lab le montre : deux machines créées avec ip=none servent du trafic public sans être joignables. Un backend qui garde une adresse publique reste attaquable directement, en contournant le Load Balancer, donc ses ACL et sa terminaison TLS.

La discipline : aucun backend avec adresse publique, et le filtrage d'entrée sur le Load Balancer plutôt que sur chaque machine.

Cost Optimization : que continuez-vous de payer après la suppression ?

La question clé : quand vous supprimez un Load Balancer, son adresse disparaît-elle avec lui ?

Non, et c'est mesuré plus bas. L'adresse reste réservée, détachée, et facturée 0,005 € par heure, soit environ 44 € par an pour une ressource qui n'existe plus.

La discipline : supprimer avec release-ip=true, puis relister les adresses de Load Balancer pour vérifier qu'il n'en reste aucune.

Pièges courants

Tous ces messages ont été obtenus en lab le 11 septembre 2026 avec scw 2.62.0.

Symptôme	Cause	Solution
Unknown argument 'health-check.port' sur backend update	update n'accepte ni le health check ni la liste de serveurs	scw lb backend update-healthcheck pour le test, set-servers pour les serveurs
Backend used by one or many frontend	le backend est encore référencé	supprimer le frontend d'abord
Invalid arguments 'InboundPort'	le port doit être compris entre 1 et 65535	corriger le port d'écoute
HTTP 404: IP not owned by Scaleway	un backend hors Scaleway sur un gabarit non multi-cloud	passer en lb-gp-l ou lb-gp-xl, ou n'utiliser que des ressources Scaleway
Tous les backends restent en panne	le Load Balancer n'est pas rattaché au réseau privé	scw lb private-network attach
Des backends privés sains signalés en panne, avec Connection refused	état transitoire du rattachement au réseau privé	détacher puis rattacher le réseau privé
L'adresse du Load Balancer réapparaît dans lb ip list après suppression	suppression sans release-ip=true	supprimer l'adresse, ou la réutiliser sur un nouveau Load Balancer

Glissez pour voir

Antipatterns à éviter

Ces cinq erreurs se ressemblent : elles font confiance à une apparence de bon fonctionnement, alors que rien n'a été vérifié sous panne.

Antipattern	Conséquence	Discipline
Se contenter d'un health check TCP	une machine dont l'application est morte reste dans la rotation	tester une route applicative qui vérifie les dépendances
Laisser une adresse publique sur les backends	le Load Balancer, ses ACL et son TLS se contournent	créer les Instances avec ip=none
Garder les valeurs par défaut sans les calculer	environ neuf secondes de trafic envoyé à une machine morte	choisir intervalle et seuil en fonction du service
Supprimer un Load Balancer sans release-ip=true	une adresse facturée que rien ne signale	supprimer en libérant, puis relister
Choisir l'accessibilité sans y réfléchir	elle est définitive, la reprendre impose une bascule DNS	décider public ou privé avant la création

Glissez pour voir

Nettoyer

L'ordre est imposé par les dépendances, et l'oubli le plus coûteux est le dernier.

1. Supprimez le frontend, puis le backend. L'inverse échoue.

   scw lb frontend delete "$FRONT" zone=fr-par-1
   scw lb backend delete "$BACK" zone=fr-par-1

2. Supprimez le Load Balancer en libérant son adresse.

   scw lb lb delete "$LB" zone=fr-par-1 release-ip=true

   La sortie doit afficher Lb has been successfully deleted.

3. Vérifiez qu'aucune adresse ne survit.

   scw lb ip list zone=fr-par-1 -o json
   scw lb lb list zone=fr-par-1 -o json

   Les deux sorties doivent être des listes vides.

Sans `release-ip`, l'adresse survit sans rien dire

Mesuré le 11 septembre 2026 : après un scw lb lb delete sans release-ip=true, la commande répond Lb has been successfully deleted. et tout semble propre. Pourtant scw lb ip list affiche toujours l'adresse, cette fois avec "lb_id": null.

Elle n'est plus attachée à rien, elle reste facturée, et aucune alerte ne se déclenche. C'est le reste de lab le plus fréquent, parce que le message de succès donne toute confiance. Si l'adresse est déjà orpheline, libérez-la :

scw lb ip delete <id-de-l-adresse> zone=fr-par-1

Ce que ce lab a prouvé

Le volet réseau se clôt sur la brique qui expose, et voici ce qu'elle a démontré.

Ce qui a été prouvé	Mesure
Un service s'expose sans aucune adresse publique sur ses machines	2 Instances à ip=none, servies par un seul répartiteur
La répartition est effective, pas déclarative	20 requêtes, 10 sur chaque Instance
La panne d'un backend est absorbée	retrait de la rotation en 5 secondes
Ce délai se règle, il ne se subit pas	check-delay=3s, check-timeout=1s, check-max-retries=2

Glissez pour voir

Ce qui a résisté : trouver les adresses privées. Les chercher par identifiant de ressource ne donne rien ; il faut filtrer l'IPAM sur le réseau privé et sur le type de rattachement. C'est la manipulation qui coûte le plus de temps à qui découvre le volet.

Dépendances de destruction, validées en lab :

Objet	Bloque	Conséquence
Répartiteur de charge	le réseau privé	à détruire avant lui
Passerelle publique	le réseau privé	facturée à l'heure, oubliée facilement
Instances	le réseau privé	leurs cartes privées le retiennent
Réseau privé	le VPC	dernier de la chaîne

Glissez pour voir

La vérification de sortie a porté sur 7 familles de ressources, toutes ramenées à zéro.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• La chaîne est Load Balancer, puis backend, puis frontend, et rien ne répond tant qu'elle n'est pas complète.
• scw lb private-network attach est indispensable avec des backends privés : sans lui, ils restent tous en panne.
• La répartition se prouve en comptant : 20 requêtes ont donné 10 web1 et 10 web2 en roundrobin, sur deux Instances créées avec ip=none.
• La détection d'une panne vaut à peu près intervalle × seuil d'échecs : 5 secondes mesurées avec 3 s et 2 échecs, contre environ 9 secondes avec les valeurs par défaut.
• Le retour est plus rapide que la sortie : 2 secondes mesurées, car il suffit de plus de deux succès consécutifs pour revenir.
• Un health check TCP ne prouve presque rien : viser une route applicative, en sachant que les redirections 301 et 302 ne sont pas suivies.
• L'accessibilité publique ou privée est définitive, et un Load Balancer privé perd Let's Encrypt et les backends externes.
• Les noms de gabarits diffèrent entre la documentation et l'API : LB-M côté doc, lb-gp-m côté CLI. Seul lb-s est identique.
• L'UDP n'est pas supporté, et le Load Balancer reste zonal malgré sa bascule automatique sur réplica.
• release-ip=true à la suppression, sinon l'adresse survit avec "lb_id": null et continue d'être facturée.

Pour aller plus loin

• IAM : donner le droit minimal à une CI, et le prouver : restreindre par une politique le droit de créer un Load Balancer, donc d'exposer un service.
• Infrastructure as Code sur Scaleway : qui fait quoi : déclarer la chaîne Load Balancer, backend et frontend plutôt que de la reconstruire à la main.

Ressources externes

• Limitations du Load Balancer : débits, connexions simultanées et plafonds de configuration par gabarit.
• Configurer les health checks : les types de test, leurs réglages fins et les limites connues.
• Load Balancer public ou privé : ce que chaque mode permet, et ce qu'il interdit définitivement.
• FAQ Load Balancer : protocoles supportés, bascule sur panne et cloisonnement des adresses flexibles.

×

📖 Voir la documentation →