A mesure que le trafic et les sollicitations de votre application augmentent, les temps de réponse peuvent être mis à rude épreuve et les performances s’en ressentent inévitablement.
Afin de gérer des centaines voire des milliers d’utilisateurs simultanés de manière satisfaisante (donc avec un temps de chargement « presque instantanée ») et de ‘mettre à l’échelle’ les performances de votre application, la mise en cache (mise en œuvre d’un cache applicatif) peut être utile sinon nécessaire.
La mise en cache qu’est-ce que c’est ?
La mise en cache consiste à stocker des copies de fichiers dans un emplacement de stockage temporaire afin d’y accéder plus rapidement.
Pour comprendre le fonctionnement des caches, on peut faire l’analogie avec des caches de nourriture par exemple. L’explorateur Roald Amundsen et ses hommes ont survécu grâce aux cachettes de nourriture qu’ils avaient stockées et qu’ils ont pu retrouver sur le chemin du retour lors de leur expédition au Pôle sud en 1912.
Les caches sur internet ont un objectif similaire : ils stockent temporairement du contenu qui sera nécessaire à un moment ou un autre.
Comment marche la mise en cache ?
Avec l’évolution rapide du web ces dernières années, la taille moyenne des pages web pour les « sites classiques » est passée de 467 à 2286 Ko entre 2010 et aujourd’hui, soit une augmentation de 389%. Pour les « sites mobiles », c’est encore plus spectaculaire puisque l’augmentation atteint 1286% en passant de 144 à 2006 Ko entre 2011 et aujourd’hui (source). Désormais chaque fois qu’un utilisateur charge une page web, le navigateur doit charger un grand nombre de données pour les afficher.
Pour optimiser le temps de chargement, la plupart des navigateurs (Edge, Chrome, Firefox, etc.) conservent en mémoire une partie du contenu des pages visitées dans le disque dur de l’appareil afin que celles-ci se chargent plus rapidement lors des prochains chargements. Bien entendu, la quantité de stockage est limitée et par ailleurs les utilisateurs peuvent vider le cache de leur navigateur à tout moment voire même le désactiver totalement.
Comme l’explique Thomas, consultant senior et scrum master
Une solution de cache applicatif sera par conséquent basée sur des solutions « serveurs » proposant un cache hautement disponible, résiliant et supportant une mise à l’échelle. Par ailleurs l’utilisation du cache peut, dans certains cas, libérer des ressources et permettre d’envisager un scale-in/scale-down au niveau de la couche de stockage (et donc des économies potentielles) tout en assurant un niveau de service identique ou meilleur pour les utilisateurs.
C’est tout l’objet du service Azure Cache for Redis. Comme son nom l’indique ce service est basé sur le système de base de données en mémoire Redis (acronyme pour REmote DIctionary Server).
Azure Redis Cache fournit à la fois la version open-source de Redis (OSS Redis) et la version commerciale de Redis (Redis Enterprise) sous forme d’un magasin de données en mémoire.
Hormis l’utilisation en tant que cache applicatif, il peut être également être utilisé comme magasin de sessions, répartiteur de messages (message broker) voire même remplacer un SGBDR classique (SQL Server, MySQL, PostgreSQL, Oracle). Attention toutefois, dans ce dernier cas, à bien vérifier votre cas d’usage car Redis propose une approche bien différente de celle d’une base de données relationnelle.
Il peut être déployé en tant que service autonome ou parallèlement à d’autres services de base de données Azure comme Azure SQL ou Cosmos DB.
L’un des principaux avantages de Redis (comme pour d’autres SGBD en mémoire) est sa rapidité à servir les données puisqu’elles sont directement consultables dans la mémoire du serveur. Sur le Web, Redis est par conséquent souvent utilisé comme mémoire cache.
Azure Redis Cache fournit nativement de nombreux services intégrés pour assurer une couche hautement disponible de mise en cache et pour garantir une expérience utilisateur constante tels que : les sauvegardes automatiques, la détection instantanée de panne, la redondance géographique.
Les différentes méthodes de gestion du cache
Mise en cache Lazy loading
Ceci est l’approche la plus courante pour mettre en œuvre un cache applicatif. Avec cette stratégie, l’application cherche tout d’abord dans le cache pour récupérer les données. Si des données n’y sont pas, l’application récupère alors directement les données de la couche de stockage et les place dans le cache pour la prochaine utilisation. Cette approche est particulièrement adapté pour les applications dont les données varient peu (beaucoup de lecture, peu d’écriture).
Mise en cache Write behind
Dans cette stratégie, les données sont d’abord écrites dans le cache avant d’être mises à jour de manière asynchrone dans le stockage de données opérationnel utilisé. Cette approche améliore la performance d’écriture et facilite le développement de l’application car le développeur n’écrit que sur Redis.
Mise en cache Write through
Cette stratégie est similaire à la précédente. Le cache se trouve entre l’application et le stockage de données utilisé, mais les mises à jour sont réalisées de manière synchrone. Le système d’écriture immédiate favorise la cohérence des données entre le cache et le stockage de données, car l’écriture a lieu sur le fil principal du serveur.
Mise en cache Read Replica
Dans un environnement contenant une grande quantité de données historiques (par exemple, mainframe), ou si vous exigez que chaque écriture soit enregistrée sur un stockage de données en fonctionnement, les connecteurs de capture de données (CDC) de Redis Enterprise peuvent capturer des changements individuels de données et propager des copies exactes sans affecter les opérations en cours tout en conservant leur consistance en quasi temps réel. Couplé à la capacité de Redis Enterprise d’utiliser plusieurs modèles de données, CDC peut vous fournir une vision appréciable des données précédemment verrouillées.
Conclusion
Le cache Azure pour Redis offre différents types de caches, permettant de choisir parmi plusieurs tailles et fonctionnalités de cache en toute flexibilité allant jusqu’à la persistance de données. Après avoir créé un cache De base, Standard ou Premium, vous pouvez changer sa taille et son niveau pour répondre aux besoins de votre application.
