Maintenir l’application fonctionnelle quand le cache échoue

Introduction

La consultation doit rester utilisable lorsque le cache facultatif cesse de répondre. Observez l’échec, bornez l’attente, activez le repli vers la source puis rétablissez les hits.

Terminez Add a Cache to a Product Lookup. Cette VM indépendante fournit application, source DynamoDB et nœud Valkey. Utilisez Terminal et AWS View. Le contrôle fourni suspend uniquement le processus de cache du laboratoire ; aucun outil d’injection de panne à construire.

Lien avec la certification

Observer un délai d’attente réel

Un timeout borne l’attente de l’application. Un processus suspendu garde son endpoint sans répondre ; ce n’est pas une clé absente.

Confirmez identité et configuration :

cd /home/labex/project
aws sts \
  get-caller-identity
cat app.json

L’ARN se termine par labex-ca03-operator. Les réglages initiaux sont timeout_seconds: 2 et fallback_on_error: false. Demandez deux fois le produit avec un cache sain :

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

La première lecture utilise la source, la seconde le cache. Activez la panne fournie :

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"pause"}' \
  http://127.0.0.1:8080/api/fault

Demandez le produit en affichant le statut HTTP :

curl -sS -w '\nHTTP %{http_code}\n' \
  http://127.0.0.1:8080/api/products/101

L’échec est intentionnel. Après environ deux secondes, l’application renvoie HTTP 503 avec failure: TimeoutError, alors que DynamoDB conserve le produit. Une panne de cache ne devrait pas rendre le catalogue indisponible.

Borner l’attente et se replier sur la source

Le repli est une autre voie choisie après une erreur du cache. Un miss normal signifie seulement qu’une copie est absente.

Utilisez 0.2 seconde dans cette expérience contrôlée et activez le repli :

jq '.timeout_seconds = 0.2 | .fallback_on_error = true' \
  app.json > app.next.json
mv app.next.json app.json

Gardez le cache suspendu et affichez le temps de la requête :

curl -sS -w '\nHTTP %{http_code}; elapsed %{time_total}s\n' \
  http://127.0.0.1:8080/api/products/101

La réponse HTTP 200 contient le prix actuel 20.00, served_from: source et cache_error: TimeoutError. L’attente contrôlée est désormais d’environ 0.2 seconde. Chaque requête ajoute une lecture de DynamoDB : le repli préserve la fonction mais augmente la charge de la base.

Dans AWS View, comparez timeout, panne suspendue et compteur. Cette expérience ne détermine ni timeout de production, ni capacité de charge, ni garantie de disponibilité AWS.

Rétablir le cache et les hits

Un cache sain et un repli réussi sont deux résultats distincts. Reprenez le processus :

curl -sS -X POST \
  -H 'Content-Type: application/json' \
  --data '{"action":"resume"}' \
  http://127.0.0.1:8080/api/fault

Demandez deux fois le produit :

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

Observez served_from: cache et cache_error: null. Si le TTL initial a expiré, la première requête remplit la clé depuis la source et la suivante est un hit. Le compteur cesse d’augmenter pour des hits consécutifs.

Laissez le cache repris et le repli borné actif pour vérifier. Dans un vrai service, surveillez erreurs et trafic supplémentaire ; le repli ne rend pas fonctionnelle une base elle-même indisponible.

Résumé

Vous avez observé un timeout réel, activé un repli borné vers la source et rétabli les hits. Une clé absente et une erreur nécessitent des traitements distincts ; le repli conserve les réponses au prix de lectures supplémentaires.

Pour approfondir ce sujet, consultez la documentation AWS : Choisir les délais client selon la charge de travail.