Einen Cache für Produktabfragen hinzufügen

AWSBeginner
Jetzt üben

Einführung

Die Produktanwendung liest bei jeder Anfrage aus DynamoDB. Füge einen Amazon-ElastiCache-Knoten mit Valkey hinzu, damit wiederholte Anfragen einen Produktwert wiederverwenden. Belege die Änderung anhand der Antwortquelle und der tatsächlichen Quellenzugriffe.

Absolviere zuerst AWS Foundations for Beginners und die grundlegenden Elementoperationen in AWS DynamoDB for Beginners. Diese unabhängige Umgebung stellt Anwendung, Katalog und Netzwerk bereit. Verwende Terminal für Befehle und AWS View für aktuelle Knoten, Quelldaten und Antworten. Die AWS CLI ist bereits konfiguriert; ein persönliches Konto oder Ressourcen aus anderen Labs sind nicht erforderlich.

Bezug zur Zertifizierung

Zertifizierung Prüfungsaufgabe Praxis
Cloud Practitioner (CLF-C02) Task 3.4 Einen speicherbasierten Cache von maßgeblichen Quelldaten unterscheiden und das Anwendungsverhalten beobachten.

Konzeptioneller Überblick dieses Labs

Die Produktquelle beobachten

Ein Cache hält wiederverwendbare Daten im Speicher. Die Datenbank bleibt die maßgebliche Quelle: Der Verlust eines Cache-Werts darf keinen Katalogdatensatz löschen. Beobachte zunächst die Anwendung ohne Cache.

Wechsle ins Projektverzeichnis und überprüfe deine konfigurierte Identität:

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

Die ARN endet auf labex-ca01-operator und identifiziert diese Umgebung. Lies Produkt 101 direkt aus DynamoDB. S bezeichnet Zeichenfolgen, N Zahlen:

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

Travel mug kostet 20.00. Produkt 202, Notebook, ist unabhängig und soll unverändert bleiben. Die HTTP-Anwendung liefert Produkt-JSON. Frage dasselbe Produkt zweimal ab:

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

Beide Antworten enthalten "served_from":"source". In AWS View steigt der Lesezähler um zwei; die ElastiCache-Karte enthält noch keinen Cluster. Ein Quellenzugriff entspricht einer tatsächlichen DynamoDB-Anfrage, nicht einer gemessenen AWS-Gebühr. Send request sendet ebenfalls eine echte Anfrage und kann den Zähler verändern. Vergleiche seine Veränderung statt eines festen Endwerts. Beispiel in AWS View vor dem Caching: Anfragen lesen die Quelle. Dein Zähler kann abweichen.

Einen Valkey-Knoten erstellen

Amazon ElastiCache verwaltet speicherbasierte Cache-Engines. Valkey speichert Werte unter Schlüsseln; hier identifiziert die Produkt-ID die Kopie. Du verwendest einen eigenständigen Knoten. Die bereitgestellte Subnetzgruppe benennt den vorbereiteten Netzwerkstandort, die Sicherheitsgruppe seine Netzwerkkonfiguration. Das VPC-Kursmaterial behandelt den Entwurf von Netzwerkregeln.

Lies die Netzwerkkennungen dieser neuen Umgebung:

cat resources.json

Speichere und zeige die Sicherheitsgruppen-ID. $(...) übernimmt die Ausgabe eines Befehls für die nächste Operation:

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

Erstelle den kleinen Cache mit einem Knoten und der Kennung product-cache. Engine und Knotenzahl wählen die Valkey-Konfiguration dieses Kurses:

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"

Beobachte CacheClusterStatus und frage den Endpunkt ab, also Adresse und Port für die Verbindung:

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

Fahre fort, sobald der Cluster available ist und Knoten 0001 einen Endpunkt besitzt. Andernfalls warte kurz und wiederhole die Abfrage. Speichere und zeige die tatsächliche Adresse:

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"

Teste die Verbindung mit dem bereitgestellten Valkey-Client:

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

PONG beweist eine Antwort der Engine, noch keine Nutzung durch die Anwendung. AWS View zeigt jetzt den tatsächlichen Knoten und Endpunkt.

Die Anwendung verbinden und Cache-Treffer beobachten

Bei cache-aside sucht die Anwendung zuerst nach product:101 im Cache. Ein fehlender Schlüssel ist ein Miss: Sie liest DynamoDB und speichert das Produkt. Ein späterer Hit liefert diese Kopie ohne erneuten Quellenzugriff.

app.json enthält gewöhnliche Anwendungseinstellungen. Ändere Modus und Endpunkt mit jq, schreibe eine temporäre Datei und ersetze damit die Konfiguration:

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

Prüfe die neuen Einstellungen:

cat app.json

Die Anwendung liest sie bei jeder Anfrage; ein Neustart ist unnötig. ttl_seconds gibt die Lebensdauer der Kopie an. Das nächste Lab erklärt Ablauf und Aktualität. Frage Produkt 101 einmal ab:

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

Die erste Antwort lautet served_from: source, weil der neue Cache leer ist. Beobachte den Zähler in AWS View und wiederhole die Anfrage:

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

Jetzt lautet die Antwort served_from: cache, bei identischer ID, identischem Namen und Preis. Der Lesezähler bleibt gleich. Eine vorherige AWS-View-Anfrage kann bereits die erste Terminal-Anfrage zum Hit machen; vergleiche aufeinanderfolgende Anfragen nach dem Befüllen. Lies den tatsächlich gespeicherten Wert:

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

Das JSON entspricht dem Travel-mug-Quelldatensatz. Das belegt weniger Quellenzugriffe bei wiederholten Abfragen, aber keine Produktionslatenz, Kapazität oder Verfügbarkeit. Lass Anwendung und Knoten zur Prüfung laufen. Diese Lernumgebung ist kurzlebig; in einem echten AWS-Konto entfernst du unnötige Caches, um weitere Ressourcenkosten zu beenden. Beispiel in AWS View nach der Verbindung: Der Cache liefert denselben Preis ohne weiteren Quellenzugriff.

Zusammenfassung

Du hast einen Valkey-Knoten erstellt, die Anwendung verbunden und cache-aside-Misses und -Hits beobachtet. Die Kopie stimmt mit DynamoDB überein und wiederholte Hits vermeiden Quellenzugriffe. Als Nächstes untersuchst du Aktualität durch TTL und gezielte Invalidierung.

Weitere Informationen bietet die AWS-Dokumentation: Cache-aside-Datenfluss; Cache-Verbindungsendpunkt auswählen.