Répartition de charge pour site autonome : déploiement multi-instances, contrôles de santé, persistance de session et bascule
1. Quand la répartition de charge est nécessaire, et quand c’est de la sur-ingénierie
La répartition de charge n’est pas un prérequis au démarrage. Jusqu’à 5 000 visites par jour, un seul VPS 2 cœurs 4 Go avec Nginx, PHP et MySQL suffit largement ; acheter un LB à quelques centaines de yuans ne fait qu’ajouter de la complexité. Trois signaux indiquent un vrai besoin de multi-instances : un CPU qui reste au-dessus de 60 % sur une seule machine, des mises en production qui exigent un arrêt du service, ou des demandes de devis déjà perdues à cause d’une panne de la machine unique. Deux de ces signaux suffisent pour passer au LB.
Le parcours de montée en charge typique d’un site autonome : un seul VPS sous compose (moins de 10 000 visites par jour) → MySQL séparé sur une machine dédiée (30 000 visites) → 2 machines applicatives + LB cloud (50 000 visites) → 3 à 5 machines applicatives + autoscaling (plus de 200 000 visites). Ne sautez pas d’étape. Le CDN absorbe le trafic statique avant le LB et divise par deux la pression sur l’origine, voir Accélération mondiale par CDN.
| Phase | Forme de déploiement | Nombre d’instances applicatives | Trafic quotidien indicatif | Surcoût mensuel |
|---|---|---|---|---|
| Phase de démarrage | VPS unique + compose | 1 | <10 000 | 0 |
| Phase de croissance | 1 machine applicative + 1 machine DB dédiée | 1 | 10 000 à 50 000 | +150 yuans |
| Phase de croisière | 2 machines applicatives + LB cloud | 2 | 50 000 à 200 000 | + environ 100 yuans de frais de LB |
| Période de pointe | 3 à 5 machines applicatives + autoscaling | 3 à 5 | >200 000 | + facturation à l’heure |
2. L4 ou L7 : quelle couche choisir pour un site autonome
La répartition de charge se fait au niveau 4 (L4, commutation TCP/IP) ou au niveau 7 (L7, routage par chemin HTTP). Le L4 est performant et simple à configurer, mais ne commute que par port ; le L7 route selon le domaine, le chemin ou l’en-tête, et gère aussi le déploiement progressif et le déchargement HTTPS. Choisissez le L7 pour un site autonome, car vous devez répartir par chemin : les fichiers statiques passent par le CDN, l’API par l’application, l’administration par un autre groupe d’instances.
Choisir son LB chez les fournisseurs cloud : AWS propose ALB (Application Load Balancer), Alibaba Cloud SLB ou ALB, Tencent Cloud CLB. Les trois se recoupent, à partir de 100 à 200 yuans par mois. Un critère de décision : si votre besoin se limite à « répartir entre deux machines », prenez le LB de couche 4 le moins cher ; si vous devez router par chemin, faire du déploiement progressif ou répartir par domaine, prenez un LB de couche 7.
| Point de comparaison | LB TCP couche 4 | LB HTTP couche 7 |
|---|---|---|
| Critère de répartition | IP + port | Domaine / chemin / Header / Cookie |
| Performance | Très élevée, à la microseconde | Un peu plus faible, à la milliseconde |
| Déchargement HTTPS | Non pris en charge | Pris en charge, certificat sur le LB |
| Déploiement progressif | Pas de répartition par proportion de trafic | Répartition du trafic par poids |
| Adapté au site indépendant | Simple répartition entre deux machines | Routage multi-chemins, déploiement progressif |
| Coût mensuel indicatif | Environ 80 à 120 yuans | Environ 150 à 250 yuans |
3. Health checks : comment les configurer sans tuer vos instances
Le health check est le cœur du LB. Trop permissif, une machine tombée continue de recevoir du trafic ; trop strict, une application un peu lente au démarrage est retirée à tort et provoque un effet boule de neige. La configuration standard pour un site indépendant : chemin de contrôle /health (qui renvoie seulement 200, sans interroger la base de données, pour éviter que la lenteur de la base ne se propage au LB), intervalle de 10 secondes, retrait après 3 échecs consécutifs, rétablissement après 2 succès consécutifs.
L’endpoint /health doit rester léger. L’erreur courante est d’y tester une connexion MySQL : au moindre hoquet de la base, toutes les instances applicatives sont retirées par le LB et le site entier renvoie 503. La bonne approche : /health renvoie uniquement l’état de vie du processus, et la santé de la base passe par un endpoint distinct /health/db, qui sert à la surveillance sans peser sur la décision de retrait. Les seuils d’alerte de surveillance sont indiqués dans Surveillance et alertes du site.
| Caractéristique | Valeur recommandée | Explication | Erreur fréquente |
|---|---|---|---|
| Chemin de contrôle | GET /health | Sans requête DB, renvoie seulement 200 | Requête DB qui retire tout |
| Intervalle de contrôle | 10 secondes | Équilibre entre réactivité et retrait à tort | 1 seconde, trop agressif |
| Délai d’expiration | 5 secondes | Au-delà, compté comme un échec | 1 seconde, trop court |
| Seuil de mauvaise santé | 3 échecs consécutifs | Retire le nœud | Retrait dès 1 échec |
| Seuil sain | 2 succès consécutifs | Remise en service | Rétablissement dès 1 succès |
| Code de réponse | 200 considéré comme sain | Tout autre code considéré comme un échec | Considérer 503 comme sain |
4. Persistance de session : à éviter tant que possible
Beaucoup de gens, au premier passage en multi-instances, se disent : « l’utilisateur se connecte sur la machine A, la requête suivante part sur la machine B et il est déconnecté », et activent donc la persistance de session. C’est une solution commode à court terme qui se paie sur la durée. Le problème : dès que la machine A tombe, tous les utilisateurs qui y sont collés sont déconnectés, ce qui annule la moitié de l’intérêt du basculement automatique.
La bonne approche est de sortir la session de la mémoire de l’application. PHP stocke la session dans Redis, Node utilise des tokens JWT sans état, et l’état de connexion est centralisé dans un stockage partagé. Ainsi, n’importe quelle instance applicative peut traiter la requête de n’importe quel utilisateur, et la chute d’une machine n’affecte pas les utilisateurs en ligne. La persistance de session ne se justifie que dans deux cas : un ancien système impossible à modifier, ou un plugin tiers qui dépend fortement de la session locale.
| Solution de session | Extensibilité | Impact en cas de panne | Coût de migration | Niveau de recommandation |
|---|---|---|---|---|
| Session en fichier local | Médiocre, sticky obligatoire | Machine tombée = utilisateur déconnecté | Faible | Déconseillé |
| Session centralisée dans Redis | Bon | Bascule transparente | Moyen, il suffit de changer la configuration | Recommandé |
| Token JWT sans état | Idéal | Bascule transparente | Élevé, il faut revoir l’authentification | Recommandé pour un nouveau projet |
| Affinité de session par cookie LB | Mauvais | Si la machine ciblée tombe, la session est perdue | Faible, il suffit d’activer l’option | Solution transitoire uniquement |
V. Basculement : comment vérifier que votre LB bascule vraiment
Configurer le LB ne suffit pas à garantir le basculement. Beaucoup d’équipes ne coupent jamais volontairement une machine après la mise en production, et découvrent le jour du vrai incident que le LB n’avait pas de health check ou que le groupe de sécurité ne laissait pas passer le trafic. Avant la mise en production, faites un test de bascule actif : en production (ou en préproduction), arrêtez manuellement l’application A et vérifiez que le LB redirige le trafic vers B en moins de 30 secondes, sans que les utilisateurs s’en aperçoivent.
Un autre piège fréquent : deux instances applicatives hébergées sur la même machine physique ou dans la même baie d’alimentation. Une coupure de la baie met les deux hors service en même temps. Déployez au minimum sur deux zones de disponibilité (AZ), ou à défaut sur deux hôtes distincts. La méthodologie complète des tests de sauvegarde et de restauration est disponible dans Sauvegarde et restauration : s’entraîner à réagir.
Exemple concret : un site B2B faisait tourner WordPress sur un seul VPS. Une nuit, une maintenance de l’hôte a coupé l’alimentation et le site est resté hors ligne 4 heures, manquant 3 demandes de devis de clients européens. L’équipe a ensuite ajouté une seconde instance applicative derrière un LB cloud, déplacé les sessions vers Redis et déployé sur deux zones de disponibilité. Lors de la fenêtre de maintenance suivante, l’instance B a repris tout le trafic automatiquement, sans que les clients ni les commerciaux ne s’en aperçoivent. Les 300 yuans mensuels supplémentaires pour l’instance coûtent bien moins que les demandes de devis perdues lors d’une panne.
| Scénario de test | Actions | Résultat attendu | Que faire en cas d’échec |
|---|---|---|---|
| Arrêter le processus applicatif | systemctl stop app | Retrait par le LB en moins de 30 secondes, bascule du trafic vers B | Vérifier le chemin du health check |
| Couper le réseau de l’application | Blocage du port via iptables | Retrait en moins de 10 secondes | Vérifier que le groupe de sécurité autorise la plage réseau du LB |
| Redémarrer la machine | reboot | Retour automatique dans la file au démarrage | Vérifier le script de démarrage et le health check |
| Instabilité de la base de données | Injection de requêtes lentes | L’application ne doit pas être retirée à tort | Le health check ne doit pas interroger la base de données |
| Basculer tout le trafic vers B | Régler le poids de B à 100 | B tient seul pendant 5 minutes | Tester la capacité de B sous charge |
FAQ — Questions fréquentes
À partir de combien de visites par jour faut-il un load balancer ?
Faut-il activer l’affinité de session ?
Pourquoi le health check ne doit-il pas interroger la base de données ?
Est-ce qu’on peut mettre les deux instances sur la même machine physique ?
Combien coûte le LB d’un fournisseur cloud par mois ?
Comment vérifier que la bascule fonctionne vraiment ?
Pour conclure
La valeur du load balancing pour un site indépendant, c’est moitié absorber le trafic, moitié absorber les pannes. Beaucoup savent calculer la première, la seconde est souvent négligée : le coût d’une instance applicative supplémentaire vous achète un « une machine tombe, l’utilisateur ne s’en aperçoit pas », et dans un scénario de demandes B2B, ça se traduit directement en argent.
Trois étapes pour passer à l’action : première étape, rendre l’application sans état en déplaçant les sessions dans Redis ; deuxième étape, démarrer une seconde instance, la placer derrière le LB cloud et configurer correctement le health check ; troisième étape, faire un exercice en tuant le processus pour confirmer que le trafic bascule en moins de 30 secondes. Une fois ces trois étapes faites, l’architecture multi-instances est vraiment opérationnelle. Pour la supervision et les alertes associées, voir Surveillance et alertes du site ; pour l’autoscaling avancé, voir Autoscaling.
Une phrase à retenir : le load balancing ne sert pas à répartir le trafic, il sert à ce que ni les utilisateurs ni les demandes ne s’aperçoivent de la panne d’une machine.