Redis ou Memcached : choisir le moteur adapté

Amazon ElastiCache est un service de mise en cache en mémoire entièrement géré qui facilite le déploiement, la gestion et la mise à l’échelle de magasins de données en mémoire open source courants dans le cloud. Il prend en charge deux moteurs : Redis et Memcached. En servant les données fréquemment demandées depuis la mémoire plutôt que depuis une base de données, ElastiCache peut réduire considérablement la charge de la base de données et faire passer la latence des réponses de quelques millisecondes à quelques microsecondes. Le choix entre Redis et Memcached est une question fréquente de l’examen SAA-C03.

Memcached est un magasin distribué clé-valeur en mémoire, axé sur la simplicité et la mise à l’échelle horizontale. Ses principales caractéristiques sont les suivantes : multithread (il peut utiliser tous les cœurs CPU d’un même nœud), stockage clé-valeur simple (chaînes de caractères uniquement, sans structures de données complexes), aucune persistance (les données sont perdues lorsqu’un nœud redémarre), aucune réplication (pas de nœud de secours ni de réplicas) et partitionnement horizontal au moyen d’un hachage cohérent côté client. Memcached est le bon choix lorsque vous avez besoin d’un cache simple et de grande taille, sans persistance, types de données complexes ni haute disponibilité.

Redis (Remote Dictionary Server) est un magasin de structures de données en mémoire, riche en fonctionnalités et monothread (par instance), qui prend en charge les chaînes de caractères, les hachages, les listes, les ensembles, les ensembles triés, les bitmaps, les HyperLogLogs, les flux et les index géospatiaux. Ses principaux avantages par rapport à Memcached sont les suivants : persistance facultative (instantanés AOF et RDB), réplication (réplicas en lecture et basculement automatique), messagerie pub/sub, scripts Lua, transactions (MULTI/EXEC) et mode Cluster pour le partitionnement horizontal. Redis est le bon choix pour la plupart des scénarios réels de mise en cache.

Redis prend en charge deux mécanismes de persistance : RDB (Redis Database) — des instantanés périodiques à un instant donné, enregistrés sur disque selon des intervalles configurables (redémarrages rapides, mais risque de perdre les données modifiées entre deux instantanés). AOF (Append-Only File) — enregistre chaque opération d’écriture ; lors d’un redémarrage, Redis rejoue le journal pour reconstruire l’état (meilleure durabilité, au prix de fichiers plus volumineux et de redémarrages plus lents). Dans ElastiCache, vous pouvez activer AOF afin de conserver les données lors des redémarrages de nœuds. Cette fonctionnalité est essentielle lorsqu’ElastiCache est utilisé non seulement comme cache, mais aussi comme magasin de données principal, par exemple pour les données de session.

Redis prend en charge les groupes de réplication avec un nœud primaire qui gère toutes les écritures et jusqu’à 5 réplicas en lecture qui gèrent les lectures. Lorsque Multi-AZ et le basculement automatique sont activés, ElastiCache promeut automatiquement un réplica en lecture au rang de primaire lorsque le primaire tombe en panne — le basculement s’effectue généralement en moins de 60 secondes. Cela confère aux applications reposant sur Redis une haute disponibilité que Memcached ne peut pas égaler (Memcached ne prend pas en charge la réplication). Pour les applications Production nécessitant une mise en cache HA, utilisez toujours Redis avec le basculement automatique.

Les ensembles triés comptent parmi les structures de données les plus puissantes de Redis. Chaque membre possède un score à virgule flottante associé, et les membres sont toujours conservés dans l’ordre trié. Les ensembles triés sont donc idéaux pour les classements (classement par score), les files d’attente prioritaires (traitement en premier des tâches les plus prioritaires) et la limitation du débit (fenêtre glissante utilisant des horodatages comme scores). Les opérations ZADD, ZRANGE, ZREVRANGE, ZRANK et ZRANGEBYSCORE sont toutes en O(log n), ce qui est extrêmement efficace, même pour des millions d’entrées.

Le pub/sub Redis permet aux éditeurs de diffuser des messages sur des canaux sans savoir qui y est abonné. Les abonnés reçoivent en temps réel tous les messages publiés sur les canaux auxquels ils sont abonnés. Les messages pub/sub ne sont pas persistants : si un abonné est hors ligne, il ne reçoit pas le message. Pour une messagerie persistante avec une livraison garantie, utilisez Redis Streams (une structure de données plus robuste ajoutée dans Redis 5) ou un service de messagerie spécialisé tel que SQS ou SNS. Pour l’examen SAA-C03, le pub/sub Redis est une option adaptée aux notifications légères en temps réel entre services.

Utilisez ce cadre pour choisir la solution appropriée à l’examen SAA-C03 : choisissez Memcached lorsque vous avez besoin d’un cache simple sans exigence de HA, de performances multithread et d’une mise à l’échelle horizontale par ajout de nœuds (cache pur). Choisissez Redis lorsque vous avez besoin de persistance (magasin de sessions), de réplication et de basculement (HA), de types de données complexes (ensembles triés pour les classements, ensembles, listes), du pub/sub, de transactions Lua ou du Cluster Mode pour une mise à l’échelle horizontale sur plusieurs partitions. Si la question d’examen mentionne une fonctionnalité allant au-delà de la simple mise en cache clé-valeur, Redis est presque toujours la réponse.

ElastiCache propose plusieurs familles de types de nœuds : r7g (Graviton 3, optimisé pour la mémoire — meilleur rapport prix/performances, recommandé pour la plupart des caches), m7g (calcul et mémoire équilibrés) et t4g (à capacité extensible, peu coûteux pour le développement et les tests). Les tailles de nœuds vont de cache.t4g.micro (500 MB) à cache.r7g.16xlarge (425 GB). Pour la Production, choisissez une taille de nœud qui conserve votre jeu de données en mémoire avec une marge de 20 à 25 %. Un manque de mémoire provoque des évictions (Memcached) ou des erreurs OOM (Redis).

ElastiCache est déployé dans votre VPC, avec des groupes de sécurité qui contrôlent les accès — aucun accès à Internet public n’est autorisé par défaut. Pour Redis, activez les jetons AUTH (un mot de passe que les clients doivent fournir) et le chiffrement en transit (TLS) des connexions, ainsi que le chiffrement au repos à l’aide de KMS. Pour Memcached, seul le chiffrement TLS en transit est disponible (pas de chiffrement au repos ni d’AUTH). Lors d’une migration de Redis non chiffré vers Redis chiffré, aucune migration sur place n’est possible : vous devez créer un nouveau cluster chiffré et le préchauffer.

Lorsqu’un cache Redis ou Memcached est plein, la stratégie d’éviction détermine quelles clés sont supprimées pour libérer de l’espace. Stratégies d’éviction Redis courantes : noeviction (renvoie une erreur OOM — utile lorsque le cache est le magasin principal), allkeys-lru (éviction des clés les moins récemment utilisées parmi toutes les clés — adapté à un cache général), volatile-lru (LRU parmi les clés auxquelles un TTL est défini — préserve les clés qui n’expirent pas), allkeys-random (éviction aléatoire) et allkeys-lfu (éviction des clés les moins fréquemment utilisées). Pour les cas d’utilisation courants de mise en cache, allkeys-lru ou allkeys-lfu sont recommandés.

Évaluez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Memcached est simple, multithread et ne fournit pas de HA — il convient particulièrement à la mise à l’échelle horizontale de caches simples, que Redis prend en charge les structures de données complexes, la persistance, le pub/sub et le basculement Multi-AZ — il convient donc à la plupart des scénarios de mise en cache en Production, et que les ensembles triés font de Redis le choix naturel pour les classements et les files d’attente prioritaires. Nous allons maintenant explorer les groupes de réplication Redis et le Cluster Mode pour le partitionnement horizontal.