Chapitre 4.3.3
Le cache applicatif

En informatique, une application désigne tout programme qui exécute une logique métier, qu’il s’agisse d’un site web, d’un service backend ou d’un logiciel installé. Les applications mobiles qu’on télécharge depuis les stores ne sont qu’un cas particulier. Le mot application ne renvoie donc pas à un appareil ou un format précis, mais à tout système qui exécute un traitement, qu’il soit local, web, distribué ou hébergé dans le cloud.

Le cache applicatif regroupe les systèmes utilisés directement par l’application pour accélérer son fonctionnement. Les développeurs y stockent principalement :

• Les résultats de requêtes en base de données.
• Les réponses des appels réseau vers d'autres briques internes ou des partenaires.

Pour stocker ces données, les applications utilisent des logiciels comme Redis ou Memcached. Ces outils sont conçus pour être extrêmement rapides. Ils exploitent principalement la mémoire vive (RAM) pour lire et écrire les données presque instantanément, plutôt que le disque, plus lent. Ils sont souvent installés sur des machines dédiées, spécialement configurées pour disposer d’une grande quantité de mémoire.

Redis et Memcached sont considérés comme des bases de données NoSQL. Ils fonctionnent selon un principe simple de clé-valeur : chaque donnée est associée à une clé unique qui permet de la retrouver instantanément.

Prenons un exemple :

1. Tu veux afficher sur une page tes offres d'abonnement.
2. Ton catalogue d'offres est hébergé chez un partenaire. Il peut mettre jusqu'à 5 secondes pour te répondre, c'est-à-dire une éternité dans la navigation d'un client.
3. Tu veux proposer des offres différentes à un client européen et à un client américain.

Les offres ne changent pas tous les jours, on décide donc de les mettre en cache pour éviter l'appel de 5 secondes.

Deux stratégies possibles :

1. Le premier client qui arrive déclenche la requête vers le partenaire. Le résultat est mis en cache après 5 secondes d'attente. C’est la solution la plus simple et la plus courante.
2. Pour améliorer l'expérience du premier client, on peut développer un script pour préremplir le cache. On appelle ça du préchauffage (warmup).

Le préchauffage sert aussi, et notamment, à protéger les systèmes au moment du renouvellement du cache.

L'infrastructure de production est dimensionnée en prenant en compte le cache. Supprimer les anciennes données sans avoir préchauffé les nouvelles revient à retirer une couche de protection. Tous les clients qui chargent une page pendant les 5 secondes suivantes vont déclencher une requête vers le partenaire. Ça risque de provoquer un pic de trafic pour lui et une accumulation de connexions sur nos propres serveurs. Tout le système pourrait s'effondrer !

Pour l'exemple, nous allons laisser le premier client subir ces 5 secondes d'attente.

Premier client :

1. Il ouvre la page pour voir toutes les offres.
2. Ce client est détecté comme étant européen. Pour obtenir les offres européennes déjà en cache, une requête est envoyée à Redis "donne-moi le contenu de la clé offres_europe". Redis répond qu'il ne connaît pas cette clé.
3. Le partenaire est appelé pour fournir les offres européennes. Il répond au bout de 5 secondes.
4. La réponse est stockée sous la clé offres_europe dans le cache Redis.
5. La réponse est retournée au client pour qu'il puisse voir les offres sur la page.

Second client :

1. Il ouvre la page pour voir toutes les offres.
2. Ce client est détecté comme étant européen. Cette fois, Redis connait la clé et nous permet d'obtenir directement la liste des offres européenne.
3. La réponse est retournée au client pour qu'il puisse voir les offres sur la page.

On a gagné 5 secondes par client ! Enfin, pour les européens… Le premier client américain va lui aussi devoir attendre 5 secondes.

Dans notre exemple, le cache est segmenté par un seul critère : le continent. C'est une liste finie dont on connaît les valeurs, on aurait donc pu facilement préchauffer le cache.

C'est loin d'être toujours le cas ! On pourrait segmenter les offres selon de multiples critères : ce client est déjà abonné et on ne veut lui proposer que de l'upgrade, ce client a résilié son abonnement et il faut essayer de le retenir, ce client a déjà bénéficié d'une promotion donc il ne faut pas lui en proposer une nouvelle…

Et si un cache est difficile à préchauffer, il sera aussi difficile à invalider.