[DB] Définition des critères de configuration du cache

Bonjour ? Je suis Jayon.

Aujourd'hui, je vais vous expliquer les critères de configuration du cache. Il s'agit d'un article écrit à partir de mon expérience pratique, veuillez donc le considérer comme une simple référence ! ㅎㅎ

Qu'est-ce que le cache ?

Le cache consiste à stocker à l'avance les résultats qui seront demandés ultérieurement afin de fournir un service plus rapide. En d'autres termes, il s'agit d'une technique qui consiste à stocker les résultats à l'avance et, lorsqu'une requête est reçue ultérieurement, à traiter cette requête en accédant au cache au lieu de consulter la base de données ou l'API. La raison d'être de ce cache réside dans la loi de Pareto.

La loi de Pareto stipule que 80 % des résultats sont dus à 20 % des causes. Je vous conseille de consulter l'image ci-dessous !

En d'autres termes, le cache ne nécessite pas de mettre en cache tous les résultats, mais seulement les 20 % les plus utilisés lors de la fourniture du service, ce qui permet d'améliorer l'efficacité globale.

Quelles données mettre en cache ?

Conformément à la loi de Pareto, il ne faut pas mettre en cache n'importe quelles données, mais uniquement les données essentielles. Quelles données faut-il donc mettre en cache ?

Données fréquemment lues mais rarement écrites

En théorie, on dit souvent qu'il faut mettre en cache les « données fréquemment lues mais rarement écrites », mais les critères de « fréquence de lecture » et de « rareté des écritures » étaient assez flous.

C'est pourquoi j'utilise les étapes suivantes pour identifier les données à mettre en cache.

• Je vérifie le Top 5 des historiques d'appels de requêtes RDB via un APM tel que DataDog.
• Parmi celles-ci, je recherche les requêtes de recherche et vérifie de quelle table elles proviennent.
• Je vérifie la fréquence d'appel des requêtes de mise à jour de cette table.

Ce processus consiste à vérifier si les requêtes de recherche sont fréquentes mais que les requêtes de mise à jour sont peu fréquentes. En pratique, j'ai vérifié une table dont les requêtes de recherche étaient appelées 1,74 million de fois par jour, tandis que les requêtes de mise à jour étaient appelées environ 500 fois au maximum. On peut considérer que cela correspond aux conditions idéales pour le cache ! ㅎㅎ

Données sensibles à la mise à jour

Pour les données sensibles à la mise à jour, cela signifie que l'écart de temps entre la base de données relationnelle et le cache doit être court. Par exemple, les informations relatives aux paiements sont très sensibles à la mise à jour, il faut donc réfléchir à leur application même si elles correspondent aux conditions de cache mentionnées ci-dessus.

J'ai dû mettre en cache une table liée aux paiements qui correspondait à ces deux caractéristiques. Par conséquent, je n'ai pas appliqué le cache à toutes les logiques utilisant cette table liée aux paiements, mais j'ai décidé de l'appliquer partiellement à des logiques relativement sûres où les paiements ne sont pas effectués en pratique.

Cache local vs cache global

Maintenant que nous avons défini les données à mettre en cache et la portée de la mise en cache, nous devons réfléchir à l'emplacement de stockage des données mises en cache. En général, on peut les stocker dans la mémoire locale ou sur un serveur dédié comme Redis.

Cache local

Le cache local consiste à stocker les données à mettre en cache dans la mémoire du serveur d'applications. On utilise généralement Guava cache ou Caffeine cache.

**Avantages**

• Comme la recherche du cache s'effectue directement dans la mémoire du même serveur lors de l'exécution de la logique de l'application, la vitesse est rapide.
• Facile à mettre en œuvre.

**Inconvénients**

• Si plusieurs instances sont utilisées, plusieurs problèmes surviennent.

Cache global

Le cache global consiste à utiliser un serveur distinct pour stocker les données mises en cache, comme Redis.

**Avantages**

• Comme le cache est partagé entre les instances, même si une instance modifie le cache, toutes les instances peuvent obtenir la même valeur de cache.
• Lorsqu'une nouvelle instance est lancée, il suffit de regarder le référentiel de cache existant, il n'est donc pas nécessaire de charger le cache.

**Inconvénients**

• Comme il faut passer par le trafic réseau, la vitesse est plus lente que celle du cache local.
• Il faut mettre en place un serveur de cache distinct, ce qui entraîne des coûts de gestion de l'infrastructure.

Quel choix ai-je fait ?

Le serveur d'applications de l'entreprise actuelle utilise une structure à plusieurs instances, mais j'ai opté pour le cache local.

Il y a trois raisons principales à cela.

• Les données à mettre en cache stockées dans la base de données relationnelle sont un peu moins de 40 000, et leur chargement complet en mémoire ne dépasse pas 4 Mo.
• Les performances de recherche des données relatives aux paiements devaient être élevées.
• Redis est déjà en place, mais le stockage de nouveaux caches dans Redis entraîne des coûts d'infrastructure.

Comment mettre à jour le cache ?

Si le serveur d'applications est composé de plusieurs instances et que le cache local est appliqué, la valeur du cache stockée sur chaque serveur d'applications peut être différente. Par exemple, la valeur de données mises en cache stockées sur le serveur A est « 1 », mais la valeur de données mises en cache stockées sur le serveur B peut être « 2 » après modification sur le serveur B. Dans ce cas, si l'utilisateur envoie une requête au load balancer, il recevra des valeurs différentes des serveurs A et B.

Par conséquent, il est nécessaire de configurer la suppression automatique du cache sur chaque instance afin de consulter la base de données relationnelle. Pour ce faire, on utilise principalement le TTL.

Quelle valeur définir pour le TTL ?

TTL est l'abréviation de Time To Live. Il s'agit d'un paramètre qui permet de supprimer le cache après un certain temps. Par exemple, si le TTL est défini sur 5 secondes, les données mises en cache seront supprimées automatiquement après 5 secondes. Ensuite, en cas d'erreur de cache, les données sont récupérées dans la base de données relationnelle et stockées.

Quelle valeur faut-il donc définir pour le TTL ?

**Lecture/écriture sur un seul serveur de cache**

Si la lecture/écriture s'effectue sur un seul serveur de cache global comme Redis ou sur un seul serveur d'applications sur lequel le cache local est appliqué, la valeur du TTL peut être augmentée à une unité de temps supérieure. De toute façon, lors de l'écriture, le cache existant sera modifié, et le serveur qui récupère les données de ce cache disposera toujours des données les plus récentes.

Dans ce cas, au lieu de définir le TTL, on peut configurer le cache pour qu'il se vide progressivement via l'algorithme LRU lorsque le serveur de cache est plein.

**Lecture/écriture sur plusieurs serveurs de cache**

Si la lecture/écriture s'effectue sur plusieurs serveurs de cache global ou sur plusieurs serveurs d'applications sur lesquels le cache local est appliqué, il est préférable de définir le TTL en secondes ou en minutes. En effet, il existe un risque de lire les anciennes données d'un serveur de cache qui n'a pas encore appliqué les données modifiées.

Dans ce cas, le TTL est déterminé en fonction de divers contextes. Plus la mise à jour est importante et plus la probabilité de modification de la valeur est élevée, plus le TTL doit être court. Inversement, si la mise à jour est moins importante et que la probabilité de modification de la valeur est faible, le TTL peut être légèrement plus long.

Comment ai-je configuré le TTL ?

Les données que je mets en cache sont liées aux paiements, et même si je n'applique pas le cache à la logique stricte de paiement, la mise à jour est importante en raison de la nature des paiements. Toutefois, comme la probabilité de mise à jour est faible, j'ai défini le TTL sur 5 secondes par mesure de sécurité.

Conclusion

En résumé, voici le mode de mise en cache que j'ai choisi.

• Données relatives aux paiements
• Les consultations sont très fréquentes, mais les modifications sont rares.
• Application du cache uniquement aux logiques où des consultations sont effectuées, mais où aucun paiement n'est effectué en pratique.
• Application du cache local avec un TTL de 5 secondes.

La prochaine étape consiste à effectuer des tests de performance sur le mode de mise en cache que j'ai effectivement appliqué. Je réfléchis encore à la manière dont je vais procéder à ces tests de performance, je vous en ferai part dans un prochain article !