Naviguer dans le Labyrinthe des Problèmes de Redirection de Pages Web : Défis et Solutions en Matière de Scalabilité
11 octobre 2024
Vous vous souvenez l’époque où le web était essentiellement statique, composé de quelques pages HTML interconnectées ? Ce bon vieux temps, où les redirections de pages web étaient utilisées principalement pour des URLs obsolètes ou des erreurs de navigation ? Et où l’on pouvait se contenter des fichiers .htaccess pour gérer les redirections temporaires ou les redirections permanentes ? Cette belle et grande période qui donnait l’impression de facilité. Attachez vos modules Apache : RewriteEngine On.
Une simple petite commande Redirect 301 (ou RedirectPermanent pour les intimes) et voici qu’on part sur une nouvelle route. Une aire de jeu plus complexe ? Pas de soucis ! On active les RewriteCond et RewriteRule boostées par nos expressions régulières préférées. Besoin de prendre temporairement un autre chemin ? Allez ! On prend l’itinéraire Redirect 302.
Un peu d’historique
Bref ! Je vous parle là d’une époque où les sites internet attiraient un trafic relativement modeste. Puis est arrivé l’an 2000 et son fameux « bug ». Mais ce n’est pas ce dernier qui marqua le plus l’histoire. C’est plutôt les bouleversements importants qu’a subit l’écosystème web depuis. Car oui ! Tout s’est emballé. Le statique est devenu dynamique, interactif. Le trafic web a explosé avec l’adoption massive de l’e-commerce, des réseaux sociaux, des services de streaming et j’en passe.
Et puis nous avons délaissé de plus en plus nos ordinateurs de bureau pour passer aux ordinateurs portables, puis aux périphériques mobiles, puis à l’IoT, etc. (Dirk Gently avait raison : « Everything is connected« ). Pour répondre à cette demande, nous avons vu apparaître des répartiteurs de charge plus sophistiqués que ce qui pouvait se faire fin des années 90, des systèmes de cache avancés, des répartitions géographiques, les SPA (rien à voir avec les animaux), le cloud computing, les micro-services, les architectures composables, etc. En résumé, nous sommes entrés dans l’air des gros mots de la scalabilité.
« Et nos redirections ? » me direz-vous. Hé bien il a fallu les planifier minutieusement. Car nous avons vu apparaître des dédales de redirections, parfois avec des boucles de redirection infinies (diminution de l’efficacité du crawling des moteurs de recherche), ou encore des impacts négatifs sur la vitesse de chargement des pages, ce qui est crucial dans un monde où les millisecondes sont la clé de l’expérience utilisateur et du SEO (avec nos fameuses Core Web Vitals).
Mais avant d’entrer plus en profondeur dans les problèmes des redirections de pages web dans des environnements à forte scalabilité, ainsi que les meilleures pratiques pour s’assurer que vos redirections soient efficientes, commençons par nous remettre à jour sur ce que sont les redirections web.
Les fondamentaux des redirections de page web
Les redirections de page web correspondent à une technique de gestion des URLs (Uniform Resource Locators, en anglais dans le texte). Elles sont parfois invisibles, parfois visibles. Leur utilisation vise à orienter les utilisateurs et/ou les moteurs de recherche, pour privilégier une adresse à une autre. Concrètement, lorsque quelqu’un tente d’accéder à une page web spécifique, il est redirigé vers une nouvelle URL définie au lieu de voir cette page. C’est le cas, par exemple, lorsque vous tapez « kaliop.com » et que votre destination finale est « https://www.kaliop.com« . Mais cela peut aller bien plus loin.
Les redirections de page web sont aussi une stratégie importante en matière de SEO (Search Engine Optimisation, toujours en anglais dans le texte) et d’UX (User eXperience). Elles permettent de définir des adresses hiérarchisées et plus compréhensibles. Elles peuvent aussi orienter les visiteurs vers la langue correspondant à leurs préférences dans le navigateur. Enfin, elles sont la puissance atomique en cas de migrations de sites.
Les types de redirections
Redirection 301
Derrière le nom de code « Redirection 301« , on parle plus précisément d’un type de redirection dit permanent. Pourquoi « permanent »? Tout simplement parce que lorsqu’une page web vous répond avec un code « 301 », elle transporte aussi une en-tête indiquant une nouvelle destination. En recevant ce code de statut et cette information, les moteurs de recherche vont automatiquement considérer l’ancienne URL comme étant obsolète. Ils commenceront à la désindexer, au profit de la nouvelle.
Ce type de redirection web est donc très largement utilisé en cas de refonte de site ou de modification de la structure de contenu. Elle permet ainsi de rediriger son trafic de manière automatique. Elle évite de perdre ses utilisateurs et le ranking de l’ancienne page (les backlinks SEO vous remercient).
Considérez donc la redirection 301 comme un panneau à l’entrée de votre jardin. Il dirait : « Vu qu’il neige, le barbecue prévu ici a été déplacé à la salle des fêtes du village. Attendez calmement, un bus va venir vous chercher pour vous y emmener. » (Même si ce serait une très mauvaise idée de faire un barbecue en intérieur et qu’une bonne grosse raclette serait bien plus appropriée. Mais chacun ses goûts après tout).
Redirection 302
À la seconde place des redirections 30x, nous retrouvons la « Redirection 302« . Aussi appelée redirection temporaire, elle a la particularité de rediriger le trafic d’une page web sans transférer l’autorité de son prédécesseur. En d’autres termes, lorsqu’une page web vous répond avec un code « 302 », elle vous redirige vers la page indiquée dans l’en-tête. Cependant, elle n’agit pas sur les indexations des moteurs de recherche (et donc sur le référencement et les métriques SEO).
La particularité temporaire de cette redirection en fait un outil pratique pour les changements temporaires ou l’A/B Testing. Attention toutefois car le moteur de recherche continue d’indexer l’ancienne URL. Cela peut entraîner une dilution de l’autorité SEO si elle est mal utilisée.
Une redirection 302 est donc l’équivalent de : « Mon bureau est toujours là. Mais pour l’instant, si vous voulez me parler, vous aurez plus de chance à la machine à café. Et sinon, promis je vais revenir. » (Par contre on n’a pas précisé combien de temps allait durer la pause café).
Redirection 303
Un peu moins fréquente mais avec un fort potentiel, vient ensuite la « Redirection 303« . Celle-ci est plus tricky car son but est légèrement différent. Elle va indiquer au client (navigateur ou moteur de recherche) qu’il doit chercher la ressource demandée à une autre URL, en utilisant la méthode GET.
Le but est donc de rediriger la navigation, mais en jouant avec les protocoles HTTP. Pourquoi? Me direz vous. Tout simplement pour éviter des soumissions indésirables par exemple. Prenons le cas d’un formulaire que vous auriez pu soumettre de manière très simple avec une méthode POST. Si la méthode ne change pas en réponse, l’utilisateur peut soumettre à nouveau la requête en rechargeant la page. Il suffirait donc que l’utilisateur ferme son navigateur après une soumission, puis le rouvre avec l’option de rouvrir la navigation précédente. Hop! Vous voici avec une nouvelle requête (j’espère pour vous que ce n’était pas une requête de paiement sur un site obscur). La redirection 303 va donc permettre de basculer sur une méthode GET en réponse à votre soumission. Ainsi le rechargement ne fera que vous réafficher le résultat de la transaction.
Redirection 304
Celle-ci je l’aime bien car j’aime beaucoup ce qui n’est pas ce qu’il semble être. Oui cette phrase est toute aussi bizarre que la « Redirection 304« car cette dernière est une redirection… qui ne redirige pas. En effet, c’est un code de statut qui indique que la ressource demandée n’a pas été modifiée depuis la dernière fois que le client l’a récupérée. Si le client a déjà une version en cache de cette ressource, il peut l’utiliser sans télécharger à nouveau la ressource. Cela améliore les performances du site en réduisant les temps de chargement.
Redirections 307 et 308 (HTTP/1.1)
Oui je sais, comme dans l’informatique on ne manipule que les 0 et les 1, on compte très mal et après 304, on passe directement à 307. Et donc kézako que les redirections 307 et 308?
Comme l’utilisation des redirections 301 et 302 ont vu quelques abus et détournements de leurs spécifications, nous avons vu apparaître de nouveaux numéros dans la déclaration 1.1 du protocole HTTP (je devrais dire protocole HTT en fait, mais là je vais embrouiller du monde). Et ces nouvelles venues parmi les redirections sont la « Redirection 307 » pour le côté temporaire, et la « Redirection 308 » pour un aspect plus permanent. Qu’apportent elles me direz vous? Et bien tout bonnement une assurance! Une garantie que la méthode et le corps ne seront pas modifiés lorsque la requête redirigée aura lieu.
Les défis liés aux redirections de page web dans un environnement à haute scalabilité
Nous sommes maintenant tou.te.s d’accord pour se dire que les redirections web n’ont rien de bien compliqué en soit. En tout cas, c’était mon avis et mon expérience, jusqu’à ce jour fatidique où la scalabilité est devenue un enjeu dans mes architectures web. Qu’est-ce que cela change au final? Le but est le même. Alors pourquoi cela deviendrait il problématique?
Tout simplement parce que ce qui fonctionne à petite échelle s’avère parfois inadapté à plus grande échelle. Il faut par conséquent voir les choses autrement. Je n’irai pas jusqu’à voir les choses en 10 dimensions comme dans la théories des cordes « conventionnelles » (même 11 dans la théorie M et la supergravité, et 26 dans la théorie des cordes bosoniques… mais là je dérive du sujet). Néanmoins il faut penser au-delà de la simple application monolithique sur un serveur unique.
Qui dit fort trafic, dit maintenant souvent de multiples couches de services qui doivent communiquer entre elles. Cela implique des serveurs géolocalisés, des architectures composables, etc. Et tout ce petit monde doit rester à jour et relayer l’information correctement, sans perte de performances.
L’impact sur la performance
Les utilisateurs d’aujourd’hui ont des attentes élevées en matière de performance web. Ils s’attendent à ce que les pages se chargent presque instantanément. Selon plusieurs études(1), même un retard d’une seconde dans le temps de chargement peut réduire le taux de conversion. Cela peut aussi augmenter le taux de rebond, et nuire à la perception globale d’un site web.
Les temps de chargement des pages
Qui dit redirection web dit aussi étape supplémentaire dans le processus de chargement des pages. La suite logique pour un navigateur qui requête une page soumise à une redirection temporaire ou permanente est la suivante :
- Requête avec l’URL d’origine
- Réponse avec le code de redirection et l’en-tête contenant la nouvelle adresse
- Nouvelle requête vers l’URL ciblée par la redirection
- Chargement de la page finale
Et encore, là nous parlons d’une redirection simple. Car il faut savoir que dans la vie d’un site web, c’est un peu comme à la SNCF : une redirection peut en cacher une autre (non je ne ferai pas de blague douteuse avec une analogie entre les problèmes de performances et les retards des trains).
Il en résulte donc une série d’aller-retour entre le client (navigateur) et le serveur qui implique une latence de réponse. Nous parlons souvent de millisecondes, j’en conviens. Prenez maintenant cette latence et multipliez là par des millions de requêtes simultanées. Notre dixième de millisecondes vient de devenir une centaine de secondes. Attendre plus d’une minute pour que ma page s’affiche? C’est so 1990!
Afin de limiter l’impact, il est donc préférable de régulièrement revoir sa stratégie de redirection. Cela permet d’éviter les boucles et de réduire les intermédiaires non nécessaires (de toute façon, la redirection de proximité est bien plus éco-responsable).
La latence accumulée dans un environnement distribué
On a vu l’impact de la simple redirection liée au trafic. Montons encore d’un cran et parlons d’infrastructure distribuée. Le cloud computing est magique. Mais alors qu’est-ce qu’il nous complique la tâche! Car reprenons notre petite redirection qui prend du temps sur son serveur, et plaçons la maintenant dans un contexte avec des serveurs décentralisés. Je suis un utilisateur qui cherche un produit spécifique et je tombe sur un annuaire de référencement spécialisé. Celui-ci met en avant une société sur un autre continent qui met à disposition une livraison mondiale. Et comme leur site internet est bien fait, il s’affiche directement dans ma langue de prédilection. Génial me direz vous!
Mais qu’est-il advenu de ma petite redirection? Hé bien la même succession que dans mon histoire compliquée à suivre. C’est-à-dire que mon navigateur a interrogé un serveur à proximité de moi. Ce serveur a répondu avec une redirection qui m’a aiguillé vers un autre serveur sur un autre continent. Ce dernier prend en considération ma langue et redirige vers la bonne traduction. On vient donc de faire voyager notre requête avec redirection, au travers de plusieurs relais pour atteindre un serveur sur un autre continent. Et cela a amené une latence réseau qui sera plus élevée en raison de la distance géographique.
Lorsque des redirections sont enchaînées (par exemple, une première redirection de l’URL A à l’URL B, puis une seconde de l’URL B à l’URL C), cette latence s’accroît à chaque étape. Cela nécessite donc une optimisation maîtrisée et suivie pour ne pas perdre les utilisateurs en route (et si vous lisez ceci malgré le temps de lecture de cet article, j’ai bien de la chance de ne pas vous avoir perdu).
Il est donc crucial de bien penser sa stratégie de proximité en terme d’hébergement pour limiter les latences réseau.
La gestion du trafic élevé
Je ne vous apprendrai rien sur la gestion des serveurs en vous disant que cela coûte excessivement cher à entretenir. Alors pour rentabiliser ces gouffres, chaque serveur mutualise ses ressources entre plusieurs comptes clients, ou applicatifs web. Même dans le cas du cloud, quand on parle de virtualisation, de containeurisation ou de serverless, il y a toujours des machines physiques qui fonctionnent au final. Les méthodes ne font que simplifier le partage de ressources et l’ajustement de ces dernières en fonction des besoins. Et même dans le meilleur des cas, où votre applicatif génère assez de revenus pour rentabiliser un serveur dédié, vos utilisateurs se partagent les capacités de ce serveur.
Comme une redirection implique au minimum une requête supplémentaire à chaque fois, dans un environnement où les ressources sont partagées entre de nombreux utilisateurs, une mauvaise gestion des redirections peut engendrer une consommation supplémentaire de bande passante, d’énergie CPU, et de mémoire. Ceci peut facilement saturer un serveur ou engendrer des coûts pharamineux dans un environnement cloud.
Comme si ce n’était pas assez compliqué, nos petites redirections doivent aussi composer avec l’aspect marketing ou promotionnel. On ne va pas se voiler la face. Si on publie du contenu, c’est pour qu’il soit lu. Une page a donc pour perspective d’être un vecteur de notoriété et/ou de revenus financiers. Pour cela, on va tenter de la mettre en avant par différentes opérations telles que des publicités, des campagnes SEO, des ventes flash, etc. Tout cela va amener un pic de traffic sur notre jolie page redirigée.
Il est donc important de monitorer ses serveurs et ses redirections pour détecter les goulets d’étranglement potentiels.
La complexité de la persistance des sessions
Nous avons déjà parlé de plein de choses, mais il y a un axe essentiel dans nos usages courants en terme d’expérience client : la personnalisation en fonction de nos critères personnels et l’accès à nos données de manière simple. C’est là qu’entrent en jeu les sessions et le fait de garantir qu’un utilisateur est toujours connecté au même serveur, ou groupe de serveurs, tout au long de sa session. Mais en quoi cela a à voir avec nos redirections web? Bien plus que vous ne croyez!
Dans un cluster de serveurs distribués, rien ne garantit que l’URL que vous tentez de consulter se trouve sur le même serveur que celui sur lequel vous étiez quand vous vous êtes authentifié. Il se peut donc que vous passiez d’un serveur à un autre et que votre session ne soit pas suivie. Dans ce cadre, quoi de plus énervant que d’avoir à saisir ses informations en permanence ou de se voir déconnecté en plein milieu de notre parcours d’achat et de perdre son panier ? La mise en place de redirections impose donc que la gestion des sessions soit aussi centralisée plutôt que gérée localement sur chaque serveur afin de pérenniser le parcours utilisateur.
Le stockage en mémoire des sessions
Aussi appelée « centralisation des sessions », le stockage en mémoire est une des pratiques les plus complètes. Les sessions ne sont pas stockées localement sur chaque serveur. Elles sont centralisées dans une base de données en mémoire, comme Redis ou Memcached. Cela permet à tout serveur du cluster d’accéder aux données de session de l’utilisateur. La session reste intacte, même après une redirection.
Cette approche apporte donc une plus grande flexibilité et scalabilité. En contrepartie, elle nécessite une gestion rigoureuse de la base de données en mémoire pour ne pas qu’elle devienne un point de défaillance unique (SPOF)
Les Sticky Sessions
/!\ Attention, dans certains cadres (comme celui de la scalabilité qui nous concerne plus spécifiquement) et pour plusieurs considérations, il est préférable de privilégier la centralisation des sessions utilisateurs.
Mais si pour x ou y raison cela vous est impossible, une technique couramment utilisée pour éviter la perte de sessions lors des redirections est celle des « sticky sessions« . Cette pratique permet de garantir que toutes les requêtes d’un utilisateur donné sont toujours dirigées vers le même serveur, même après une redirection, et maintient donc une continuité sans interruption.
Cependant, les sticky sessions peuvent entraîner un déséquilibre dans la répartition de la charge entre les serveurs si un seul d’entre eux est fortement sollicité dans ce cadre. Ce concept induit aussi la mise en place d’un routage sophistiqué. Les load balancers doivent être configurés pour reconnaître les sessions individuelles et rediriger les utilisateurs vers le bon serveur, même après une redirection.
Les sticky sessions peuvent donc s’avérer utiles mais ne sont pas appropriées à tous les cas d’usage et toutes les architectures. Et elles ne sont pas sans complexité.
Solutions techniques pour une gestion efficace des redirections de page web
Ce chapitre ressemble un peu au TL;DR de cet article. J’aurais pu commencer par ça me direz vous. Mais où aurait été le plaisir ? Nous allons donc essayer de résumer les points clés pour que les redirections de pages web dans un environnement à haute scalabilité ne soient pas votre pire cauchemar hanté par des problèmes de performance, des interruptions de service, et une dégradation significative de l’expérience utilisateur.
L’optimisation des redirections pour la performance
La réduction des chaînes de redirections
Vous pouvez analyser tous vos logs serveurs, ou encore utiliser la console Google Search ou des plateformes comme Screaming Frog, SEO PowerSuite pour ne citer qu’elles. Peu importe l’outil tant que vous êtes capable d’identifier et supprimer ou minimiser les chaînes de redirections inutiles. Faites donc en sorte, autant que possible, de rediriger directement l’URL d’origine vers la destination finale, sans étapes intermédiaires inutiles.
La mise en cache des redirections
Les coûts et les performances sont les maîtres mots quand on parle d’hébergement et d’expérience utilisateur. Comme pour parvenir à un bon résultat, il est crucial de limiter la charge des serveurs, alors la mise en cache des redirections est votre meilleure alliée.
Selon votre contexte, vous pouvez toujours activer votre module mod_cache sur votre serveur Apache, utiliser un serveur Nginx qui offre une prise en charge native de la mise en cache, utiliser un load balancer comme HAProxy qui permet une mise en cache, utiliser un système de cache distribué de type Varnish ou encore des CDN comme Cloudflare, Akamai, Fastly, ou AWS CloudFront. Je ne vous cache pas que nous avons nos préférences, mais comme nous ne sommes pas sponsorisés (mais je ne suis pas contre l’idée … à bon entendeur) et que chaque projet requiert ses propres outils, je ne ferai pas de publicité.
C’est bien gentil de vous balancer ces outils, mais je ne remplirais pas totalement mon rôle si je vous laissais là. Je peux donc aussi vous confier des petites astuces supplémentaires.
Types de redirections à mettre en cache
Nous avons évoqué précédemment plusieurs types de redirections. Avant que vous vous emballiez dans vos configurations, il est à préciser que toutes ne sont pas bonnes à mettre en cache.
De par leur nature, l’intérêt de la mise en cache des redirections concerne surtout les redirections 301 (c’est permanent, donc on ne va pas s’amuser à la recalculer à chaque fois non plus). Cependant, il peut s’avérer aussi utile de mettre en cache à court terme certaines redirections 302, comme dans le cas de campagnes marketing limitées dans le temps.
Durée de vie de la mise en cache
Quand on parle de redirection 301, on parle de redirection permanente. De plus, nous sommes à notre époque concernés par l’éco-conception. C’est pourquoi ce type de redirection se doit d’être mise en cache pour une longue période. Si vous êtes frileux, 24h est un minimum acceptable. Mais une durée plus long n’est pas dénuée de sens. Si votre redirection est définitive et que votre roadmap ne prévoit pas de revenir dessus avant longtemps, vous pouvez même compter en mois ou année.
Si comme vu dans le point précédent, vous mettez en cache des redirections 302, il est donc préférable de voir plus court. Les plus frileux partiront donc sur quelques minutes, voire quelques heures. Mais si votre campagne est bien assurée, le cache peut couvrir sa durée potentiellement.
Pour répondre à ces besoins, il vous suffit de configurer vos entêtes HTTP Cache-Control avec un max-age, ou encore Expires si vous voulez configurer une date d’expiration exacte pour la redirection.
Attention tout de même ! Parfois on prépare nos stratégies de redirection minutieusement, et pourtant ça n’est pas assez. Et là : boum ! Je dois faire un changement de dernière minute, ma redirection change et ma mise en cache bien calculée se retrouve propagée avec mon ancienne URL de redirection. On ne va pas se mentir, ça arrive tout le temps.
Dans ce cas, deux choses vous sauveront la vie si vous les anticipez : des mécanismes d’invalidation de cache ou des purges de cache (si vous utilisez un CDN, il existe en général des API permettant de purger manuellement ou automatiquement le cache lorsque les redirections doivent être modifiées).
La scalabilité et l’équilibrage de charge
La répartition des requêtes
Répartir les requêtes utilisateurs entre plusieurs serveurs, c’est éviter la surcharge d’un seul serveur et réduire le risque de temps d’arrêt. Le premier point à assurer est donc l’équilibrage de la charge.
Nous en parlions précédemment dans les outils listés au niveau de la mise en cache, mais là aussi un load-balancer comme HAProxy peut vous être grandement utile pour distribuer efficacement les requêtes HTTP et HTTPS, incluant les redirections, sur plusieurs serveurs. Grâce à lui, vous pouvez configurer une répartition des requêtes en « round-robin« , garantissant une distribution uniforme des charges (RTFM).
Nous avions aussi parlé de Nginx. Hé bien là aussi, il n’est pas qu’un serveur web. Il est aussi très puissant lorsqu’il s’agit de load-balancing pour gérer à la fois les redirections et la répartition des requêtes.
Côté cloud, vous pouvez aussi compter sur AWS Elastic Load Balancer (ELB pour les intimes) pour fournir un équilibrage de charge automatique, ou encore configurer un DNS géolocalisé (comme Amazon Route 53) pour que les redirections envoient les utilisateurs vers le serveur ou le centre de données le plus performant.
Je faisais le beau précédemment en citant sans prévenir « round-robin » comme stratégie de répartition. Mais sachez qu’il existe d’autres approches en fonction de vos besoins et de votre stratégie :
- Round-Robin : Répartit les requêtes de manière séquentielle entre tous les serveurs.
- Least connections : Redirige les nouvelles requêtes vers le serveur qui a le moins de connexions actives, garantissant ainsi que les serveurs avec peu de charge sont priorisés.
- IP hash : Utilise l’adresse IP du client pour rediriger la requête vers un serveur spécifique, ce qui peut être utile pour maintenir la cohérence des sessions utilisateurs.
La haute disponibilité et forte scalabilité
Dans le cadre d’applicatifs web à très fort traffic et avec des enjeux importants en termes de temps de réponse vraiment optimisé, il peut être tentant de simplement axer sa stratégie sur la scalabilité horizontale en ajoutant de nouveaux serveurs au pool de load balancing. Cependant, il est préférable de retarder cette option qui s’avère rapidement coûteuse. Nous allons avant tout tenter d’optimiser nos stratégies avec l’existant.
Pour y parvenir, certains outils plus avancés que ceux pré-cités peuvent vous être utiles. Je peux avancer F5 Big-IP ou encore Kemp LoadMaster. Bien que Nginx par exemple, permette aussi de mettre en place des stratégies de Failover automatique ou de health checks (surveillance des serveurs), ces plateformes s’avèreront plus robustes en cas de fort traffic, plus riches en fonctionnalités et spécialisées : gestion intelligente des sessions, WAF (Web Application Firewall), DPI (Deep Packet Inspection), SSL Offloading, etc.
La persistance des sessions
À ce stade, vous avez mis en place un super système de redirection de pages web, qui répond vite et bien. Vous êtes exténué mais content de vous. Sauf que votre QA appelle et vous dit : « les tests d’authentification sur le site sont KO ! On se fait déconnecter régulièrement en changeant de page. » (cette histoire est basée sur des faits réels. Aucune personne travaillant à la QA n’a été blessée pendant l’écriture). Après des heures à faire des tests, requêter dans les logs, remettre en cause toute votre stratégie de redirection, vérifier que vos cache sont bien synchronisés, etc. Vous vous apercevez que vos sessions ne sont aléatoirement pas maintenues lors de certaines redirections. Foutue stickiness !
Les techniques pour maintenir la persistance des sessions à travers les redirections
Les cookies de session
L’astuce est que le load-balancer génère un cookie au moment de la première requête de chaque utilisateur et s’en serve ensuite pour rediriger toujours vers le même serveur à chaque requête.
Si vous êtes team Nginx, le module Sticky Cookie vous permettra de générer un cookie unique afin de maintenir la persistance de chaque session. Pour les teams HAProxy et F5 Big-IP, tout est déjà présent pour configurer des règles d’affinité basées sur des valeurs spécifiques de cookies. Attention toutefois à configurer l’expiration des cookies de manière cohérente avec la durée de la session sur le serveur.
Persistance basée sur les en-têtes HTTP
L’équilibreur de charge peut analyser les en-têtes HTTP spécifiques d’une requête pour déterminer si l’utilisateur doit être dirigé vers un serveur particulier. Cela est particulièrement utile dans des environnements où où l’utilisation de cookies peut être limitée, comme les applications mobiles ou des API spécifiques.
IP Source Hashing
Avec cette technique, on utilise l’adresse IP source de l’utilisateur pour déterminer quel serveur va gérer ses requêtes. Dans ce cas, pas de cookie à gérer. Mais cela peut poser problème si plusieurs utilisateurs partagent la même IP (par exemple, derrière un proxy NAT). Là encore, la team Nginx est au rendez-vous avec l’utilisation de la directive ip_hash.
HAProxy supporte lui aussi le hachage IP. Quant à Kemp LoadMaster, il offre un panel d’outil assez étoffé pour cet usage.
Cependant, j’insiste sur le fait que cette méthode est efficace dans des environnements où les utilisateurs ont des IP uniques, mais elle peut être limitée dans des environnements où les adresses IP sont partagées.
Sticky sessions
Certaines solutions de cache, comme Varnish ou des CDNs comme Akamai et Cloudflare, peuvent être configurées pour maintenir la persistance des sessions via le cache serveur, en se basant sur des en-têtes HTTP spécifiques ou des cookies.
Redis, Memcached quant à eux, ne stocke pas les sessions localement sur le serveur, mais dans une base de données centralisée ou une solution de stockage de sessions. Pour les adeptes du cloud, AWS Elasticache peut vous permettre de mettre en place Redis ou Memcached et profiter de tous leurs avantages sur étagère.
Attention tout de même aux coûts ! Il est recommandé de synchroniser régulièrement les sessions ou de configurer un timeout approprié pour les sessions afin de limiter la consommation de mémoire dans ces bases de données centralisées.
Les tips de dernière minute
- Auditer régulièrement les sessions : des outils de monitoring, tels que Prometheus et Grafana, peuvent être utilisés pour observer la distribution des sessions et identifier tout déséquilibre.
- Limiter la durée des sessions : des timeouts raisonnables pour les sessions aide à réduire la consommation de ressources et limite la surcharge sur le système de session store.
- Optimiser le déchargement SSL : décharger les opérations SSL vers le load balancer (comme avec F5 Big-IP ou Kemp LoadMaster) peut améliorer les performances.
Conclusion
Vous l’aurez compris : mettre en place des redirections de page web efficaces dans un environnement de scalabilité peut être un casse-tête entre la latence, la persistance des sessions, le SEO, etc. Mais il existe des solutions pour garantir une bonne expérience utilisateur et de bonnes performances. La première action à considérer est de mener un audit de votre solution, vérifier la complexité de vos redirections. La suite ne dépend de votre capacité à suivre les évolutions de vos redirections.
(1) Sources sur la façon dont le temps de chargement peut réduire le taux de conversion :
Commentaires
