Stockage des sessions et modèles de classements

Les applications web traditionnelles stockent les données de session dans la mémoire du serveur. Cette approche fonctionne avec un seul serveur, mais échoue lors d’une mise à l’échelle horizontale : si la requête suivante d’un utilisateur est acheminée vers une autre instance EC2, celle-ci ne connaît pas la session de l’utilisateur, qui est alors déconnecté. Les sessions persistantes (affinité de session au niveau de l’équilibreur de charge) résolvent partiellement le problème, mais réduisent l’efficacité de l’équilibrage de charge. La solution évolutive consiste à déplacer l’état des sessions vers un stockage partagé à faible latence, accessible depuis toutes les instances, ce que fournit précisément ElastiCache Redis.

Stocker les sessions dans Redis vous offre : des lectures de session en moins d’une milliseconde sur tous les serveurs d’application, un TTL intégré pour l’expiration automatique des sessions, des mises à jour atomiques des sessions afin d’éviter les conditions de concurrence, ainsi que la possibilité d’invalider immédiatement une session en supprimant la clé. L’application stocke l’identifiant de session dans un cookie ; à chaque requête, elle recherche cet identifiant dans Redis afin de récupérer les données de session. Tous les serveurs d’application partagent le même Redis, de sorte que n’importe quel serveur peut traiter la requête de n’importe quel utilisateur.

Un TTL fixe signifie que la session expire N secondes après sa création, quelle que soit l’activité. Un TTL glissant (qui prolonge l’expiration à chaque accès) est plus convivial : la session expire N secondes après le dernier accès. Dans Redis, implémentez un TTL glissant en appelant EXPIRE (ou EXPIREAT) sur la clé de session après chaque lecture réussie de la session afin de réinitialiser le compte à rebours de l’expiration. Les utilisateurs actifs ne sont ainsi jamais déconnectés de manière inattendue, tandis que les sessions inactives expirent automatiquement et libèrent de la mémoire.

Un panier d’achat de commerce électronique se prête naturellement à Redis. Chaque panier est stocké sous la forme d’un Hash Redis, où le champ correspond au SKU du produit et la valeur à la quantité. Des opérations sur les hachages comme HINCRBY et HDEL permettent d’effectuer des mises à jour atomiques sans récupérer puis réécrire l’intégralité du panier. Associé à un TTL (pour faire expirer les paniers abandonnés après 24 heures), Redis fournit un stockage de panier rapide et persistant, sans les coûts liés à l’utilisation d’une base de données relationnelle pour chaque ajout au panier.

Un classement en temps réel est un cas d’utilisation classique de Redis, rendu possible par les ensembles triés (ZSETs). Chaque entrée de joueur possède un score ; l’ensemble trié maintient en permanence les membres dans l’ordre croissant des scores. Les requêtes de classement (les N meilleurs joueurs, le rang d’un joueur, les joueurs dans une plage de scores) s’exécutent en O(log n) ou O(log n + m) — elles sont extrêmement rapides, même avec des millions de joueurs. Les ensembles triés Redis constituent la base de nombreuses fonctionnalités de classement dans les jeux, le fitness et les réseaux sociaux, sans nécessiter de requête complexe dans une base de données ni de recalculer le rang à chaque affichage de page.

Deux fonctionnalités courantes d’un classement, au-delà de « afficher les 10 premiers », sont afficher le rang d’un joueur et afficher les joueurs proches d’un joueur donné. Ces deux fonctionnalités sont triviales avec les ensembles triés Redis. ZREVRANK renvoie le rang d’un joueur, indexé à partir de 0, dans l’ordre décroissant des scores. Pour afficher 5 joueurs au-dessus et au-dessous d’un joueur, récupérez son rang, puis utilisez ZREVRANGE du rang-5 au rang+5. Vous obtenez ainsi une vue personnalisée du classement avec deux commandes Redis seulement, sans avoir besoin de fonctions de fenêtrage SQL complexes.

La limitation du débit (qui consiste à restreindre le nombre de requêtes qu’un client peut effectuer pendant une période donnée) est un autre cas d’utilisation particulièrement intéressant de Redis. L’algorithme de fenêtre glissante utilise un ensemble trié dont chaque membre est l’horodatage d’une requête. Pour chaque requête : supprimez les membres antérieurs à la fenêtre, comptez les membres restants, rejetez la requête si le nombre dépasse la limite, puis ajoutez le nouvel horodatage. Cette méthode met en œuvre une limitation précise par fenêtre glissante, avec une résolution à la milliseconde — bien plus exacte que les compteurs à fenêtre fixe et sans la surcharge d’une base de données.

Les verrous distribués coordonnent l’accès exclusif à une ressource partagée entre plusieurs serveurs d’application. La commande Redis SET key value NX EX ttl fournit une acquisition atomique du verrou : elle définit la clé uniquement si celle-ci n’existe pas (NX = Not eXists) et définit une durée de vie (TTL) afin d’éviter les interblocages si le détenteur tombe en panne. Lorsque l’opération est terminée, le détenteur supprime la clé. L’algorithme Redlock (qui utilise plusieurs nœuds Redis pour obtenir un quorum) fournit un verrou distribué plus robuste, au prix d’une complexité accrue. Pour la plupart des cas d’utilisation, le verrou d’un seul nœud Redis suffit.

ElastiCache Redis et DynamoDB peuvent tous deux stocker des données de session, mais leurs compromis sont différents. ElastiCache Redis : latence de l’ordre de la microseconde, stockage en mémoire (volatile sauf si la persistance est activée), modèle de données plus simple, VPC requis. DynamoDB : latence de quelques millisecondes (DAX peut égaler Redis), service entièrement géré sans cluster à maintenir, données durables par défaut, accès mondial avec les tables globales, architecture sans serveur avec capacité à la demande. Pour l’examen SAA-C03 : si la question met l’accent sur une latence de l’ordre de la microseconde ou des opérations complexes en mémoire, choisissez Redis. Si elle insiste sur la durabilité, l’architecture sans serveur ou l’échelle mondiale, envisagez DynamoDB.

Redis possède un type de données géospatiales intégré (commandes GEO) qui stocke des coordonnées de latitude et de longitude et permet d’effectuer des requêtes de proximité. Avec GEOADD, GEODIST et GEORADIUS (désormais GEOSEARCH dans Redis 6.2), vous pouvez trouver tous les emplacements situés dans un rayon donné autour d’un point, en O(n + log n). Cas d’utilisation : trouver les chauffeurs à proximité (covoiturage), trouver les restaurants dans un rayon de 5 km, trier les résultats de recherche par distance. Vous évitez ainsi une base de données géospatiale distincte et conservez une vitesse de requête adaptée au stockage en mémoire.

Un HyperLogLog est une structure de données probabiliste qui estime le nombre d’éléments uniques d’un ensemble en utilisant une quantité fixe de mémoire (12 Ko dans Redis), quel que soit le nombre d’éléments uniques ajoutés. Il fournit une erreur standard d’environ 0,81 %. Utilisez PFADD pour ajouter des éléments et PFCOUNT pour obtenir l’estimation. Cette structure convient parfaitement pour compter les utilisateurs actifs uniques par jour, les consultations uniques de pages ou les adresses IP uniques lorsque le décompte exact n’est pas nécessaire et que l’efficacité mémoire est importante. Le stockage de millions d’identifiants utilisateur uniques dans un Set Redis consommerait des Go ; HyperLogLog utilise 12 Ko.

Dans cette leçon, vous avez appris que : le stockage des sessions Redis permet une mise à l’échelle horizontale sans état en donnant à toutes les Instances accès à un état de session partagé, avec une latence inférieure à la milliseconde ; les ensembles triés Redis alimentent les classements en temps réel avec des requêtes de rang en O(log n) ; et les types de données Redis spécialisés (HyperLogLog pour les décomptes uniques, GEO pour la proximité, verrous distribués) résolvent efficacement des problèmes d’architecture courants. Le cours sur la mise en cache avec ElastiCache est terminé ; nous allons maintenant étudier la haute disponibilité et les architectures tolérantes aux pannes.