Les équipes qui accèdent à Cloudflare Load Balancing à partir d'un AWS ALB configurent souvent tout correctement, puis rencontrent un comportement que leur modèle mental n'explique pas : un client continue d'arriver à la même origine pendant quelques minutes après son échec, la répartition de la charge semble inégale entre les instances et le basculement prend plus de temps que ce que suggèrent les vérifications de l'état. Le produit fonctionne, mais il fonctionne différemment que prévu, car il fonctionne sur le DNS, et non sur la couche transport ou application.
Comment fonctionne réellement l'équilibrage de charge Cloudflare
Cloudflare Load Balancing est un service de distribution de trafic qui agit lors de la résolution de noms. Lorsqu'un client effectue une requête DNS pour le domaine équilibré, Cloudflare Authoritative évalue quelles origines sont saines, applique la règle de pilotage configurée et renvoie l'adresse IP de l'origine sélectionnée. À partir de ce point, le client se connecte directement à la source – ou au PoP Cloudflare, si l'enregistrement est par proxy – et toutes les demandes de cette session sont dirigées vers cette destination jusqu'à ce que la durée de vie expire et que le client doive à nouveau résoudre le nom.
Cela signifie que la répartition de la charge s'effectue via la résolution DNS, et non via une requête HTTP. Deux clients simultanés qui résolvent le domaine dans la même seconde peuvent se voir attribuer des origines différentes. Un seul client qui résout le nom une fois et maintient la connexion ouverte reste indéfiniment sur la même origine. S'il y a dix instances exécutées derrière un ALB, l'ALB répartit les requêtes entre elles à chaque nouvelle requête. Avec Cloudflare LB, la granularité dépend du client et non de la demande.
Le système de vérification de l'état corrige le chemin lorsqu'une source échoue. Cloudflare effectue des contrôles de santé actifs à partir de plusieurs PoP (et non d'un seul point) pour chaque origine enregistrée. Lorsque le pourcentage d'échecs dépasse le seuil configuré, la source est marquée comme dégradée et supprimée du pool de résolution. Les nouveaux clients qui résolvent leur nom après cette balise ne reçoivent plus l'adresse IP de la source problématique. Les clients qui ont déjà résolu le nom et dont l'adresse IP est mise en cache continuent d'essayer de se connecter jusqu'à l'expiration de la durée de vie. Le basculement comporte donc deux composantes de latence : le temps nécessaire au contrôle de santé pour détecter et marquer l'échec, et la durée de vie restante des clients déjà résolus.
Le modèle de tarification et ce qu'il couvre
Le plan de base Cloudflare Load Balancing coûte 5 $ par mois et comprend deux pools d'origines, cinq origines par pool et des contrôles de santé configurables. Les frais supplémentaires de 0,50 $ pour 500 000 requêtes de contrôle de santé s'appliquent au volume généré par les contrôles : avec des intervalles de 60 secondes et une répartition sur plusieurs PoP, le volume mensuel augmente rapidement, mais reste dans une fourchette raisonnable pour les configurations actives-passives avec de petits pools.
Pour une configuration active-passive simple – un pool principal avec deux sources et un pool de secours – la facture mensuelle est inférieure à 10 $ dans la plupart des scénarios. Pour les architectures plus élaborées avec plusieurs pools régionaux et des contrôles de santé granulaires par PoP, le coût augmente, mais reste compétitif par rapport aux frais opérationnels liés à la gestion du basculement manuel entre les régions.
Geo Steering : routage par origine géographique du client
Geo Steering est la fonctionnalité qui transforme le Load Balancer en une véritable couche de routage géographique. La configuration associe des régions (continents ou pays spécifiques) à des pools sources. Les clients brésiliens résolvent le domaine et reçoivent l'adresse IP d'origine à São Paulo. Les clients européens reçoivent l'IP d'origine à Francfort. Cloudflare faisant autorité identifie l'emplacement géographique du résolveur qui a effectué la requête et renvoie la réponse du pool correspondant.
Lorsque le pool régional devient indisponible (toutes les origines qu'il contient sont marquées comme dégradées), Cloudflare passe automatiquement au pool de secours global configuré. Le client européen dont le pool de Francfort se trouve à l'extérieur reçoit l'IP de São Paulo ou de tout autre pool sain, sans intervention manuelle. Ce mécanisme de repli automatique est ce qui rend Geo Steering utile pour la haute disponibilité géographique, et pas seulement pour l'optimisation de la latence.
L'affinité de session de cookie complète le routage géographique dans les cas où la même instance doit servir le même client sur plusieurs résolutions DNS. Cloudflare injecte un cookie dans la réponse HTTP qui identifie l'origine sélectionnée, et Load Balancer utilise ce cookie pour renvoyer le client à la même origine lors des résolutions ultérieures, même si la durée de vie a déjà expiré. Pour les applications apatrides, cela n'a pas d'importance ; Pour les sessions qui stockent le contexte dans la mémoire de l'instance, c'est le mécanisme qui empêche la rupture de l'expérience lors des re-résolutions TTL normales.
La distinction qui change la conception de l'architecture
Un ALB fonctionne au niveau de la couche 7. Il reçoit les connexions TCP, inspecte les en-têtes HTTP, applique les règles de routage des chemins et des en-têtes et distribue chaque requête individuelle à une instance du pool back-end. Il voit chaque demande. Vous pouvez effectuer un routage basé sur le chemin : /api va à un groupe d'instances, /static va à un autre. Peut injecter ou modifier des en-têtes. A une visibilité sur le corps de la requête si le protocole le permet.
Cloudflare LB ne voit pas les demandes individuelles. Il répond aux requêtes DNS. Il n'existe aucun moyen d'inspecter le chemin /api car le chemin n'existe même pas au niveau de la couche DNS — il n'apparaît qu'une fois que le client a établi la connexion TCP avec l'origine et envoyé le HTTP GET. Il ne s’agit pas d’une limitation accidentelle ; c'est la conséquence naturelle de fonctionner avec un mauvais protocole pour ce niveau de granularité.
Le modèle qui combine les deux résout différents problèmes à chaque couche. Cloudflare LB s'occupe du routage géographique et du basculement entre les régions : les clients du Brésil arrivent à São Paulo, les clients d'Europe arrivent à Francfort, et si São Paulo tombe en panne, le trafic migre automatiquement. Dans chaque région, un ALB ou nginx distribue les requêtes entre les instances du pool, effectue un routage basé sur le chemin et gère la charge au niveau des requêtes. Les deux coexistent sans conflit car ils résolvent des problèmes à différentes couches de la pile.
Que signifient les contrôles de santé pour le SLA de basculement
La vitesse de basculement dépend de trois variables : l'intervalle de vérification de l'état, le nombre d'échecs consécutifs requis pour marquer une source comme dégradée et la durée de vie de l'enregistrement DNS. Avec des contrôles de santé toutes les 60 secondes et deux échecs consécutifs comme seuil, le pire des cas de détection est de 120 secondes. En ajoutant la durée de vie (qui pour les enregistrements proxy est de 60 secondes), la fenêtre de basculement maximale est d'environ 3 minutes.
La réduction de l'intervalle de vérification de l'état accélère la détection, mais augmente le volume de requêtes facturées. Le seuil de rentabilité dépend du SLA de disponibilité du service. Pour les systèmes où 3 minutes de panne partielle sont acceptables (l'origine morte ne sert aucun nouveau client lors de la détection, mais les clients avec un cache actif essaient toujours jusqu'à la durée de vie) - la configuration par défaut est adéquate. Pour les systèmes où tout détournement de trafic vers une source dégradée est inacceptable, la combinaison d'un faible TTL, d'un contrôle de santé à intervalle court et d'au moins deux PoP vérifiant en parallèle réduit la fenêtre à moins de 2 minutes en pratique.
Le point que les équipes ayant des antécédents ALB sous-estiment est que Cloudflare LB ne supprime pas les connexions actives lorsqu'une origine est marquée comme dégradée. Il cesse de renvoyer cette adresse IP dans les nouvelles résolutions DNS. Les clients dont l'adresse IP est déjà mise en cache continuent d'essayer. Le délai d'expiration de la connexion TCP ou l'erreur d'application est ce que le client rencontrera jusqu'à ce que la durée de vie expire et qu'une nouvelle résolution renvoie une adresse IP saine. L’impact réel dépend de la fraction de clients actifs disposant d’un cache récent par rapport au cache expiré au moment de la panne.
A lire aussi
-Cloudflare DNS : une infrastructure réseau qui va bien au-delà de la résolution de noms
- DNS proxy vs DNS uniquement : ce qui change et quand chaque mode a du sens -DNSSEC avec Cloudflare : ce qu'il protège, ce qu'il ne protège pas et comment l'activer sans problème
- Cloudflare Email Routing : recevez des e-mails sur votre domaine — et ce qui n'est pas inclus
- KV vs R2 vs API Cache : quand utiliser chaque niveau de stockage Cloudflare -Cloudflare KV : Que signifie une distribution mondiale lorsque vous devez écrire