Faire expirer des enregistrements temporaires avec TTL

Introduction

Les enregistrements de session temporaires doivent cesser d'être fournis à leur expiration, même si le nettoyage du stockage n'a pas encore eu lieu. Vous allez activer TTL, corriger un attribut d'expiration dont le type est incorrect et configurer une application fournie pour exclure les données expirées à partir de lectures réelles du service.

Terminez d'abord Créer une table DynamoDB pour les commandes et Rechercher des commandes avec une clé de partition et de tri. Le nouvel environnement fournit une table de sessions indépendante, trois enregistrements synthétiques et le socle d'une application de lecture, prêts pour votre configuration de TTL et du filtre de lecture. Utilisez /home/labex/project, la CLI AWS officielle et AWS View. Ce laboratoire évalue la configuration de TTL et les lectures tenant compte de l'expiration ; il ne promet aucun délai de suppression en arrière-plan sur AWS.

Lien avec les certifications

Vue d’ensemble du laboratoire

Activer l'expiration sur la table de sessions préparée

Dans cette étape, vous allez configurer l'attribut d'expiration d'une table. Time to Live (TTL) permet à DynamoDB de supprimer à terme les éléments expirés. C'est un nettoyage asynchrone, pas un minuteur qui supprime chaque élément à la seconde exacte de son expiration. Les applications doivent continuer à refuser les données expirées pendant l'attente de leur suppression par le service.

Pour ce lecteur de sessions, pouvoir servir un enregistrement et le supprimer du stockage sont deux résultats distincts. Vous examinerez l’état TTL, corrigerez le type de l’expiration, puis comparerez l’application avec une lecture brute. ENABLED prouve la configuration ; exclure une session expirée prouve la politique de lecture, pas la suppression de l’élément par le service.

Le nouvel environnement contient une table de sessions avec des enregistrements synthétiques actifs, expirés et permanents. Inspectez leurs types et l'état désactivé de TTL avant toute activation.

cd /home/labex/project

aws dynamodb scan --table-name labex-d05-sessions --consistent-read

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

Activez TTL sur expires_at. Chaque élément fournit sa propre date d'expiration ; la configuration de la table sélectionne l'attribut examiné par le service TTL. Un attribut absent signifie que cet élément n'a pas d'expiration TTL.

aws dynamodb update-time-to-live \
  --table-name labex-d05-sessions \
  --time-to-live-specification Enabled=true,AttributeName=expires_at

aws dynamodb describe-time-to-live --table-name labex-d05-sessions

Poursuivez lorsque la description indique ENABLED et expires_at. Sur AWS, l'activation peut prendre du temps ; répétez la commande de description pendant l'état ENABLING plutôt que de modifier la configuration à plusieurs reprises. Observez AWS View en haut et développez l'entrée TTL dans la carte des sessions.

Corriger le type d'attribut de l'enregistrement expiré

Dans cette étape, vous allez stocker une valeur d'expiration valide. TTL dans DynamoDB exige un Number contenant des secondes depuis l'epoch Unix : le nombre de secondes depuis le 1970-01-01 UTC. Des millisecondes représenteraient une date très lointaine. Une chaîne ressemblant à un horodatage reste un String, et le processus TTL l'ignore.

Inspectez l'enregistrement d'exemple expiré par sa clé exacte. Son attribut expires_at est volontairement encodé avec S ; activer TTL n'a pas corrigé son type.

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

Calculez une expiration une heure dans le passé avec la commande Linux date. +%s affiche les secondes Unix, et $(...) stocke cette sortie dans EXPIRED. La valeur varie à chaque exécution ; elle doit être antérieure à l'heure actuelle.

EXPIRED=$(date -u -d '1 hour ago' +%s)
echo "$EXPIRED"

Placez la valeur typée dans un petit fichier JSON. Ce heredoc utilise un délimiteur JSON sans guillemets, pour que le shell remplace $EXPIRED par votre horodatage ; les délimiteurs précédents entre guillemets conservaient les valeurs littéralement. Garder le JSON dans un fichier évite d'échapper ses guillemets.

cat > expiry-values.json <<JSON
{":expires":{"N":"$EXPIRED"}}
JSON

Utilisez UpdateItem pour remplacer uniquement l'attribut d'expiration. file:// charge le fichier de valeurs ; la condition d'existence évite de recréer un enregistrement si la suppression asynchrone l'a déjà retiré.

aws dynamodb update-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --update-expression 'SET expires_at = :expires' \
  --condition-expression 'attribute_exists(session_id)' \
  --expression-attribute-values file://expiry-values.json \
  --return-values ALL_NEW

L'élément expiré renvoyé possède expires_at: {"N": "..."} dans le passé et conserve son attribut purpose. L'élément actif reste dans le futur ; l'élément permanent n'a toujours pas d'expiration. Sur AWS, si l'enregistrement a été retiré avant une lecture ou une mise à jour ultérieure, ne concluez à sa suppression qu'après une réponse réussie du service, pas après un échec de connexion.

Exclure les données expirées des lectures applicatives

Dans cette étape, vous allez protéger les lectures pendant l'attente du nettoyage TTL. L'application session-reader fournie lit les paramètres ordinaires de session-reader.json et effectue de véritables requêtes Scan. Sa configuration par défaut renvoie volontairement aussi les données expirées. Le code source de l'application est disponible pour inspection ; vous n'avez pas à écrire de Python.

./session-reader

Dans cet environnement, l'application sans filtre renvoie encore les trois enregistrements, y compris expired. Cela ne prouve pas que TTL est mal configuré. La suppression en arrière-plan sur AWS peut avoir lieu plus tard, et aucun calendrier précis ne fait partie des critères de validation de ce laboratoire.

Activez le filtre d'expiration de l'application. Un heredoc entre guillemets écrit littéralement le JSON et remplace le fichier de paramètres.

cat > session-reader.json <<'JSON'
{
  "table": "labex-d05-sessions",
  "filter_expired": true
}
JSON

./session-reader

L'application utilise attribute_not_exists(expires_at) OR expires_at > :now avec les secondes actuelles de type Number et suit les clés de continuation de Scan. Elle ne renvoie maintenant que active et permanent, avec Count 2 et FilterExpired true. L'enregistrement permanent est intentionnel, car il n'a pas de politique d'expiration. Le filtrage empêche de fournir les données expirées, mais n'annule pas le travail de lecture d'un scan.

Comparez la lecture brute par clé avec le résultat de l'application.

aws dynamodb get-item \
  --table-name labex-d05-sessions \
  --key '{"session_id":{"S":"expired"}}' \
  --consistent-read

La lecture brute peut encore contenir expired alors que l'application l'exclut. Si AWS l'a déjà supprimé, un GetItem réussi et vide est également compatible avec TTL. AWS View affiche la configuration TTL et le résultat réel à deux éléments de l'application, sans prétendre que le filtrage a physiquement supprimé l'enregistrement stocké.

Supprimer la table de sessions de l'exercice

Dans cette étape, vous allez nettoyer explicitement la table après avoir vérifié la configuration d'expiration et le comportement applicatif. N'attendez pas que TTL supprime la table entière : TTL supprime des éléments, pas la table elle-même. Supprimer cette table temporaire retire également sa configuration TTL.

aws dynamodb delete-table --table-name labex-d05-sessions

aws dynamodb wait table-not-exists --table-name labex-d05-sessions

aws dynamodb list-tables

aws dynamodb get-item \
  --table-name labex-d05-reference \
  --key '{"id":{"S":"platform"}}' \
  --consistent-read

Seule la table de référence reste et sa note est keep unchanged. Un inventaire et des lectures de référence réussis prouvent que la connexion fonctionne encore après la suppression. AWS View retire la table de sessions et le résultat de l'application. La connexion temporaire prend fin avec cette VM.

Résumé

Vous avez activé TTL sur expires_at, remplacé un horodatage de type chaîne par des secondes numériques depuis l'epoch et exclu les sessions expirées des lectures réelles d'une application. Vous avez distingué l'expiration logique de la suppression physique asynchrone et conservé intentionnellement les enregistrements permanents. Enfin, vous avez supprimé la table de l'exercice et conservé la référence sans rapport.

Pour approfondir ce sujet, consultez la documentation AWS : Expiration TTL et suppression asynchrone des éléments.