Bonjour ? Je suis Jayeon.

Aujourd'hui, je vais vous expliquer les critères de configuration du cache. Il s'agit d'un article que j'ai écrit en basé sur mon expérience professionnelle, alors veuillez le considérer uniquement comme une référence ㅎㅎ

Qu'est-ce que le cache ?

Le cache est un moyen de stocker les résultats d'une demande à l'avance afin de pouvoir les fournir rapidement. En d'autres termes, le cache est une technique qui consiste à enregistrer les résultats à l'avance et à les utiliser pour traiter les demandes sans avoir à faire référence à la base de données ou à l'API. La loi de Pareto est à l'origine de l'apparition de ce type de cache.

La loi de Pareto stipule que 80 % des résultats sont dus à 20 % des causes. N'hésitez pas à consulter l'image ci-dessous !

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

Quelles données faut-il mettre en cache ?

Conformément à la loi de Pareto, il ne faut pas mettre en cache des données quelconques. Seules les données absolument nécessaires doivent être mises en cache. Quelles données faut-il donc mettre en cache ?

Données devant être fréquemment lues, mais rarement écrites

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

C'est pourquoi j'effectue les recherches de données à mettre en cache en suivant les étapes suivantes :

• Je vérifie les 5 premières requêtes d'appel à la base de données via APM comme DataDog.
• Parmi celles-ci, je recherche les requêtes de recherche et je vérifie la table à partir de laquelle elles sont récupérées.
• Je vérifie le nombre d'appels à la requête de mise à jour de la table concernée.

En suivant ce processus, je vérifie si la requête de recherche est fréquente, mais que la requête de mise à jour est rarement effectuée. La table que j'ai vérifiée en pratique a reçu 1,74 million de requêtes de recherche par jour, tandis que la requête de mise à jour ne se produisait que 500 fois au maximum. En d'autres termes, il est évident que cette table est adaptée à la mise en cache ㅎㅎ

Données sensibles à la mise à jour

Les données sensibles à la mise à jour signifient que la désynchronisation entre la base de données et le cache doit être courte. Par exemple, les informations relatives aux paiements sont très sensibles à la mise à jour, et même si elles répondent aux critères de mise en cache mentionnés ci-dessus, il faut réfléchir à leur application.

J'ai dû mettre en cache une table liée aux paiements qui répondait à ces deux caractéristiques. J'ai donc décidé de ne pas appliquer la mise en cache à toutes les logiques utilisant cette table, mais de mettre en cache la logique relativement sûre où les paiements ne sont pas réellement effectués.

Mise en cache locale vs mise en cache globale

Nous avons maintenant défini les données à mettre en cache et la portée de la mise en cache. Il faut alors se demander « où » stocker les données mises en cache. En général, vous pouvez les stocker dans la mémoire locale ou dans un serveur distinct tel que Redis.

Mise en cache locale

La mise en cache locale consiste à stocker les données à mettre en cache dans la mémoire du serveur d'applications. Guava cache ou Caffeine cache sont souvent utilisés à cette fin.

Avantages

• La récupération des données en cache dans la mémoire du même serveur pendant l'exécution de la logique de l'application est rapide.
• Facile à mettre en œuvre.

Inconvénients

• Il existe plusieurs problèmes lorsque plusieurs instances sont utilisées.
  • Les modifications apportées au cache par une instance ne peuvent pas être propagées aux autres instances. Cependant, il existe également des bibliothèques de mise en cache locale qui permettent de propager les modifications aux autres instances.
  • Comme le cache est stocké dans chaque instance, il est nécessaire de réinsérer le cache chaque fois qu'une nouvelle instance est créée. Cela peut entraîner de nombreuses erreurs de cache, ce qui peut rendre l'instance incapable de gérer le trafic et entraîner sa mort.

Mise en cache globale

La mise en cache globale consiste à utiliser un serveur distinct, tel que Redis, pour stocker les données mises en cache.

Avantages

• Le cache est partagé entre les instances, ce qui permet à toutes les instances d'obtenir la même valeur du cache, même si une instance modifie le cache.
• Lorsque de nouvelles instances sont créées, elles peuvent faire référence au même référentiel de cache, ce qui élimine le besoin de remplir le cache.

Inconvénients

• Il faut passer par le trafic réseau, ce qui rend la vitesse plus lente que la mise en cache locale.
• Il faut un serveur de cache distinct, ce qui entraîne des coûts de gestion d'infrastructure.
  • Coûts de gestion d'infrastructure ? → Frais de serveur, temps consacré à la configuration et à la maintenance de l'infrastructure, planification des mesures de réponse aux pannes, etc.

Qu'ai-je choisi ?

Le serveur d'applications de l'entreprise actuelle utilise plusieurs instances, mais j'ai choisi la mise en cache locale.

Il y a trois raisons principales :

• Les données à mettre en cache stockées dans la base de données représentent un peu moins de 40 000 enregistrements, ce qui ne représente que 4 Mo au maximum si l'on met tout en mémoire.
• Il était nécessaire d'améliorer les performances de recherche des données liées aux paiements.
• Redis était déjà en place, mais le stockage d'un nouveau cache dans Redis impliquait des coûts d'infrastructure.

Comment mettre à jour le cache ?

Si le serveur d'applications a plusieurs instances et que la mise en cache locale est appliquée, la valeur du cache stockée dans chaque serveur d'applications peut être différente. Par exemple, la valeur du cache stockée sur le serveur A est « 1 », tandis que la valeur du cache stockée sur le serveur B est « 2 » après une modification sur le serveur B. Dans ce cas, si un utilisateur envoie une requête au serveur de répartition de charge, il recevra des valeurs différentes du serveur A et du serveur B.

Par conséquent, il faut configurer chaque instance pour qu'elle supprime automatiquement le cache et interroge la base de données. Pour ce faire, on utilise généralement le TTL.

Quelle valeur du TTL faut-il définir ?

TTL signifie « Time To Live ». Il s'agit d'un paramètre qui permet de supprimer le cache après un certain temps. Par exemple, si vous définissez un TTL de 5 secondes, les données en cache seront automatiquement supprimées 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 et stockées.

Alors, quelle valeur du TTL faut-il définir ?

Lecture/écriture sur un seul serveur de cache

Si la lecture/écriture est effectuée sur un seul serveur de cache global comme Redis ou sur un seul serveur d'applications avec la mise en cache locale, vous pouvez augmenter la valeur du TTL à l'unité de temps ou plus. De toute façon, lorsque vous écrivez, vous modifierez le cache existant, et le serveur qui récupère les données dans ce cache recevra toujours des données mises à jour.

Dans ce cas, vous pouvez également configurer le serveur de cache pour qu'il ne définisse pas de TTL, mais pour qu'il libère automatiquement un peu de cache au fur et à mesure qu'il se remplit, à l'aide de l'algorithme LRU.

Lecture/écriture sur plusieurs serveurs de cache

Si la lecture/écriture est effectuée sur plusieurs serveurs de cache global ou sur plusieurs serveurs d'applications avec la mise en cache locale, il est préférable de définir le TTL en secondes ou en minutes. En effet, il existe un risque de lire des données obsolètes d'un serveur de cache qui n'a pas encore été mis à jour.

Dans ce cas, le TTL est déterminé dans des contextes variés. Plus la mise à jour est importante et plus la probabilité de modification de la valeur est élevée, plus le TTL doit être court. À l'inverse, si la mise à jour est moins importante et si la probabilité de modification de la valeur est faible, le TTL peut être plus long.

Comment ai-je défini le TTL ?

Les données que je mets en cache sont liées aux paiements, et même si je n'applique pas la mise en cache à la logique stricte qui génère réellement les paiements, la mise à jour est importante en raison de la nature même des paiements. Cependant, la probabilité de mise à jour est faible, j'ai donc défini un TTL de 5 secondes par mesure de sécurité.

Conclusion

En résumé, voici la méthode de mise en cache que j'ai choisie :

• Données liées aux paiements
• Lecture très fréquente, mais modifications rares.
• La mise en cache est appliquée uniquement à la logique qui génère des recherches, mais pas à la logique qui génère réellement des paiements.
• La mise en cache locale a été appliquée et le TTL a été défini à 5 secondes.

La prochaine étape consiste à effectuer des tests de performance sur la méthode de mise en cache que j'ai réellement appliquée. Je suis encore en train de réfléchir à la façon d'effectuer ces tests, je les détaillerai dans un article ultérieur !