Ajouter un cache à la consultation des produits

Introduction

L’application lit son catalogue dans DynamoDB à chaque requête. Ajoutez un nœud Amazon ElastiCache exécutant Valkey pour réutiliser un produit. Prouvez le changement avec l’origine des réponses et le nombre réel de lectures de la source.

Terminez AWS Foundations for Beginners et les opérations élémentaires de AWS DynamoDB for Beginners. Cet environnement indépendant fournit application, catalogue et réseau. Utilisez Terminal pour les commandes et AWS View pour observer les ressources et réponses. AWS CLI est déjà configurée ; aucun compte personnel ni ressource d’un autre laboratoire n’est nécessaire.

Lien avec la certification

Observer la source des produits

Un cache conserve en mémoire des données réutilisables. La base reste la source faisant autorité : perdre une copie en cache ne doit pas supprimer le produit. Observez d’abord le comportement sans cache.

Placez-vous dans le projet et confirmez votre identité :

cd /home/labex/project
aws sts \
  get-caller-identity

L’ARN se termine par labex-ca01-operator et identifie cet environnement. Lisez directement le produit 101. DynamoDB représente les chaînes par S et les nombres par N :

aws dynamodb \
  get-item \
  --table-name product-catalog \
  --key '{"product_id":{"S":"101"}}' \
  --consistent-read

Travel mug coûte 20.00. Le produit 202, Notebook, est indépendant et doit rester intact. L’application HTTP renvoie le produit en JSON. Demandez-le deux fois :

curl -sS http://127.0.0.1:8080/api/products/101
curl -sS http://127.0.0.1:8080/api/products/101

Les réponses contiennent "served_from":"source". Dans AWS View, le compteur augmente de deux et la carte ElastiCache n’affiche aucun cluster. Une lecture correspond à une vraie demande à DynamoDB ; elle ne mesure pas une facture AWS. Send request envoie aussi une vraie requête et peut faire varier le compteur. Comparez son évolution, sans attendre une valeur finale fixe.

Créer un nœud Valkey

Amazon ElastiCache gère des moteurs de cache en mémoire. Valkey stocke des valeurs par clé ; ici, l’ID du produit identifie sa copie. Vous utiliserez un nœud autonome. Le groupe de sous-réseaux indique l’emplacement préparé et le groupe de sécurité sa configuration réseau. Le cours VPC couvre la conception des règles.

Lisez les identifiants fournis :

cat resources.json

Enregistrez et affichez l’ID du groupe de sécurité. $(...) récupère la sortie d’une commande pour la suivante :

CACHE_GROUP_ID=$(jq -r .security_group_id resources.json)
echo "$CACHE_GROUP_ID"

Créez le petit cache à un nœud nommé product-cache. Le moteur et le nombre de nœuds sélectionnent la configuration Valkey du cours :

aws elasticache \
  create-cache-cluster \
  --cache-cluster-id product-cache \
  --engine valkey \
  --engine-version 7.2 \
  --cache-node-type cache.t3.micro \
  --num-cache-nodes 1 \
  --cache-subnet-group-name product-cache-network \
  --security-group-ids "$CACHE_GROUP_ID"

Observez CacheClusterStatus, puis recherchez l’endpoint, adresse et port de connexion :

aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].{Status:CacheClusterStatus,Nodes:CacheNodes}'

Continuez lorsque le cluster est available et que le nœud 0001 possède un endpoint. Sinon, attendez brièvement et répétez la requête. Enregistrez et affichez l’adresse réelle :

CACHE_HOST=$(aws elasticache \
  describe-cache-clusters \
  --cache-cluster-id product-cache \
  --show-cache-node-info \
  --query 'CacheClusters[0].CacheNodes[0].Endpoint.Address' \
  --output text)
echo "$CACHE_HOST"

Testez la connexion avec le client fourni :

valkey-cli -h "$CACHE_HOST" -p 6379 PING

PONG prouve que le moteur répond, mais pas encore que l’application l’utilise. AWS View affiche le vrai nœud et son endpoint.

Connecter l’application et observer un accès au cache

Avec cache-aside, l’application recherche d’abord product:101 dans le cache. Une clé absente provoque un cache miss : elle lit DynamoDB et stocke le produit. Un cache hit ultérieur renvoie cette copie sans nouvelle lecture de la source.

app.json contient la configuration ordinaire. Utilisez jq pour changer le mode et l’endpoint, puis remplacez le fichier par le fichier temporaire :

jq --arg host "$CACHE_HOST" \
  '.mode = "cache-aside" | .cache_host = $host' \
  app.json > app.next.json
mv app.next.json app.json

Inspectez le résultat :

cat app.json

La configuration est relue à chaque requête, sans redémarrage. ttl_seconds est la durée de vie de la copie ; le prochain laboratoire traite l’expiration. Demandez une fois le produit :

curl -sS http://127.0.0.1:8080/api/products/101

La première requête renvoie served_from: source, car le nouveau cache est vide. Observez le compteur dans AWS View, puis recommencez :

curl -sS http://127.0.0.1:8080/api/products/101

La réponse indique served_from: cache, avec les mêmes ID, nom et prix ; le compteur n’augmente pas. Si AWS View a déjà demandé le produit, la première commande peut être un hit : comparez des requêtes consécutives après remplissage. Lisez le contenu réellement stocké :

valkey-cli -h "$CACHE_HOST" -p 6379 GET product:101

Le JSON correspond à Travel mug dans DynamoDB. Cela démontre moins d’accès à la source pour ces requêtes, sans établir la latence, la capacité ou la disponibilité en production. Laissez application et nœud actifs pour vérifier. Cet environnement est jetable ; dans un compte AWS réel, supprimez les caches inutiles pour arrêter leurs frais.

Résumé

Vous avez créé un nœud Valkey, connecté l’application et observé les misses et hits de cache-aside. La copie correspond à la source et les hits évitent de nouvelles lectures. Étudiez ensuite la fraîcheur grâce au TTL et à l’invalidation.

Pour approfondir ce sujet, consultez la documentation AWS : Flux de données cache-aside; Choisir un point de terminaison de connexion au cache.