Añadir una caché a la consulta de productos

Introducción

La aplicación consulta DynamoDB en cada solicitud. Añadirás un nodo Amazon ElastiCache con Valkey para reutilizar el valor de un producto y demostrarás el cambio mediante el origen de las respuestas y el contador de lecturas reales.

Completa primero AWS Foundations for Beginners y las operaciones básicas de elementos de AWS DynamoDB for Beginners. Este entorno independiente incluye la aplicación, el catálogo y la red. Usa Terminal para los comandos y AWS View para observar el nodo, los registros y las respuestas. AWS CLI ya está configurada: no necesitas una cuenta personal ni recursos de otro laboratorio.

Relación con la certificación

Observar el origen de los productos

Una caché guarda datos reutilizables en memoria. La base de datos sigue siendo la fuente de verdad: perder una copia en caché no debe eliminar el registro del catálogo. Primero observa la aplicación sin caché.

Entra en el directorio del proyecto y confirma la identidad configurada:

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

El ARN termina en labex-ca01-operator e identifica el entorno que consultarás. Lee directamente el producto 101; DynamoDB representa las cadenas con S y los números con N:

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

Travel mug cuesta 20.00. El producto 202, Notebook, es independiente y debe conservarse. La aplicación HTTP devuelve JSON del producto. Solicítalo dos veces:

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

Ambas respuestas contienen "served_from":"source". En AWS View, el contador aumenta en dos y la tarjeta ElastiCache todavía no tiene clúster. Cada lectura corresponde a una solicitud real de DynamoDB; no mide cargos de AWS. Send request también envía una solicitud real y puede modificar el contador. Compara si aumenta, sin exigir un número final fijo.

Crear un nodo de caché Valkey

Amazon ElastiCache administra motores de caché en memoria. Valkey almacena valores por clave; aquí, el ID del producto identifica cada copia. Usarás un nodo independiente. El grupo de subredes indica la ubicación de red preparada y el grupo de seguridad aporta su configuración. El diseño de reglas se estudia en el curso de VPC.

Lee los identificadores de este entorno:

cat resources.json

Guarda y muestra el ID del grupo de seguridad. $(...) conserva la salida de un comando para la operación siguiente:

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

Crea una caché pequeña de un nodo, identificada por product-cache. El motor y el número de nodos seleccionan la configuración Valkey del curso:

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"

Observa CacheClusterStatus y consulta el endpoint, la dirección y el puerto de conexión:

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

Continúa cuando el clúster esté available y el nodo 0001 tenga endpoint. Si aún se está creando, espera brevemente y repite la consulta. Guarda y muestra la dirección real:

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"

Prueba la conexión con el cliente Valkey preparado:

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

PONG demuestra que el motor responde, aunque todavía no prueba que la aplicación lo utiliza. AWS View muestra el nodo y su endpoint reales.

Conectar la aplicación y observar un acierto

La estrategia cache-aside busca primero product:101 en la caché. Una clave ausente es un fallo de caché: la aplicación lee DynamoDB y guarda el producto. Un acierto posterior devuelve esa copia sin otra lectura del origen.

app.json contiene ajustes ordinarios. Usa jq para cambiar el modo y el endpoint; escribe un archivo temporal y reemplaza la configuración:

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

Inspecciona el resultado:

cat app.json

La aplicación relee la configuración en cada solicitud, sin reinicio. ttl_seconds es la vida de la copia; el siguiente laboratorio explica su caducidad. Solicita el producto una vez:

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

La primera respuesta es served_from: source, porque la nueva caché está vacía. Observa el contador en AWS View y repite:

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

Ahora aparece served_from: cache, con el mismo ID, nombre y precio, y el contador no aumenta. Si ya solicitaste el producto desde AWS View, el primer comando puede ser un acierto: compara solicitudes consecutivas después de llenar la caché. Lee el valor real almacenado:

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

El JSON coincide con Travel mug en DynamoDB. Has demostrado menos accesos al origen en consultas repetidas, sin medir latencia, capacidad ni disponibilidad de producción. Deja la aplicación y el nodo activos para verificar. El entorno es desechable; en una cuenta AWS real, elimina las cachés innecesarias para detener cargos continuados.

Resumen

Creaste un nodo Valkey, conectaste la aplicación y observaste fallos y aciertos de cache-aside. La copia coincide con el producto autoritativo y los aciertos evitan nuevas lecturas. A continuación estudiarás la frescura mediante TTL e invalidación explícita.

Para ampliar este tema, consulta la referencia de AWS: Flujo de datos cache-aside; Seleccionar un endpoint de conexión de caché.