PERF03-BP05 Mise en œuvre de modèles d’accès aux données utilisant la mise en cache - AWS Well-Architected Framework

PERF03-BP05 Mise en œuvre de modèles d’accès aux données utilisant la mise en cache

Mettez en œuvre des modèles d’accès qui peuvent tirer parti de la mise en cache des données pour une récupération rapide des données fréquemment consultées.

Anti-modèles courants :

  • Vous mettez en cache des données qui changent fréquemment.

  • Vous utilisez les données mises en cache comme si elles étaient stockées de manière durable et toujours disponibles.

  • Vous ne tenez pas compte de la cohérence de vos données mises en cache.

  • Vous ne surveillez pas l’efficacité de la mise en œuvre de la mise en cache.

Avantages liés au respect de cette bonne pratique : Le stockage des données dans un cache contribue à améliorer la latence et le débit de lecture, l’expérience utilisateur et l’efficacité globale, tout en réduisant les coûts.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : moyen

Directives d’implémentation

Un cache est un composant logiciel ou matériel destiné à stocker des données afin que les requêtes futures portant sur les mêmes données puissent être traitées plus rapidement ou plus efficacement. Les données stockées dans un cache peuvent être reconstruites en cas de perte en répétant un calcul antérieur ou en les récupérant dans un autre magasin de données.

La mise en cache des données peut être l’une des stratégies les plus efficaces pour améliorer les performances globales de votre application et réduire la charge qui pèse sur vos sources de données principales sous-jacentes. Les données peuvent être mises en cache à plusieurs niveaux dans l’application, par exemple dans l’application effectuant des appels à distance et également connue sous le nom de mise en cache côté client, ou en utilisant un service secondaire rapide pour stocker les données, ce que l’on appelle aussi mise en cache à distance.

Mise en cache côté client

Grâce à la mise en cache côté client, chaque client (une application ou un service qui interroge le magasin de données backend) peut stocker les résultats de ses requêtes uniques localement pendant une durée spécifiée. Cela permet de réduire le nombre de requêtes adressées à un magasin de données sur le réseau en vérifiant d’abord le cache du client local. En l’absence de résultats, l’application peut alors interroger le magasin de données et stocker ces résultats localement. Ce modèle permet à chaque client de stocker les données dans l’emplacement le plus proche possible (le client lui-même), ce qui se traduit par la latence la plus faible possible. Les clients peuvent également continuer à répondre à certaines requêtes lorsque le magasin de données backend n’est pas disponible, ce qui augmente la disponibilité de l’ensemble du système.

L’un des inconvénients de cette approche est que lorsque plusieurs clients sont impliqués, ils peuvent stocker les mêmes données mises en cache localement. Cela entraîne à la fois une double utilisation du stockage et une incohérence des données entre ces clients. Un client peut mettre en cache les résultats d’une requête et, une minute plus tard, un autre client peut exécuter la même requête et obtenir un résultat différent.

Mise en cache à distance

Pour résoudre le problème de duplication des données entre clients, un service externe rapide, ou cache distant, peut être utilisé pour stocker les données interrogées. Au lieu de vérifier un magasin de données local, chaque client vérifie le cache distant avant d’interroger le magasin de données backend. Cette stratégie permet d’obtenir des réponses plus cohérentes entre les clients, d’améliorer l’efficacité des données stockées et d’augmenter le volume de données mises en cache, car l’espace de stockage évolue indépendamment des clients.

L’inconvénient d’un cache distant est que l’ensemble du système peut connaître une latence plus élevée, car un saut de réseau à réseau supplémentaire est nécessaire pour vérifier le cache distant. La mise en cache côté client peut être utilisée parallèlement à la mise en cache à distance pour une mise en cache à plusieurs niveaux afin d’améliorer la latence.

Étapes d’implémentation

  1. Identifiez les bases de données, les API et les services réseau susceptibles de bénéficier de la mise en cache. Les services dont la charge de travail de lecture est importante, qui ont un ratio lecture/écriture élevé ou qui sont coûteux à adapter conviennent à la mise en cache.

  2. Identifiez le type de stratégie de mise en cache le mieux adapté à votre modèle d’accès.

  3. Suivez les bonnes pratiques en matière de mise en cache pour votre magasin de données.

  4. Configurez une stratégie d’invalidation du cache, telle qu’une durée de vie (TTL), pour toutes les données afin d’équilibrer la fraîcheur des données et de réduire la pression qui pèse sur le magasin de données backend.

  5. Activez des fonctionnalités telles que les nouvelles tentatives de connexion automatiques, le backoff exponentiel, les délais d’attente côté client et le regroupement des connexions dans le client, le cas échéant, car elles peuvent améliorer les performances et la fiabilité.

  6. Surveillez le taux d’accès au cache en visant un objectif de 80 % ou plus. Des valeurs inférieures peuvent indiquer une taille de cache insuffisante ou un modèle d’accès qui ne bénéficie pas de la mise en cache.

  7. Implémentez la réplication des données pour transférer les lectures vers plusieurs instances et améliorer les performances et la disponibilité de lecture des données.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :