Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Récupération des données DLT après suppression de la pile Cette section décrit comment restaurer des scénarios de test et exécuter l'historique dans une nouvelle pile DLT après la suppression de la pile d'origine. Cela s'applique lorsque les compartiments S3 et les tables DynamoDB du client ont été conservés (comportement par défaut) et que le client souhaite les reconnecter à un nouveau déploiement. ## Contexte Lorsqu'une pile DLT est supprimée, les ressources suivantes sont conservées dans le compte AWS du client conformément aux politiques de protection des données : | Ressource | Contains | Dénomination | | --- | --- | --- | | Scénarios : compartiment S3 | Scripts de test (JMeter/K6/Locust), fichiers XML de résultats par tâche, actifs du framework JMeter | Auto-generated (par exemple,`dltstack-scenariosbucket-abc123`) | | Compartiment Logs S3 | Journaux d'accès S3 pour tous les compartiments DLT | Auto-generated | | Compartiment pour console S3 | Ressources statiques de l'interface utilisateur Web | Auto-generated | | Scénarios : tableau DynamoDB | Définitions de test, configurations, règles de planification | Auto-generated (par exemple,`DLTStack-ScenariosTable-xyz789`) | | Historique de la table DynamoDB | Résultats des tests, durées, taux de réussite | Auto-generated (par exemple,`DLTStack-HistoryTable-xyz789`) | | CloudWatch groupes de journaux | Journaux d'exécution Lambda et ECS (10 ans de conservation) | Nommé par fonction | Tous les noms de ressources sont générés automatiquement par CloudFormation. Ils ne sont pas prévisibles et ne peuvent pas être spécifiés en tant que paramètres lors du déploiement d'une nouvelle pile. ## Contraintes importantes 1. Le CloudFormation modèle DLT n'accepte pas les paramètres des tables DynamoDB ou des compartiments S3 existants. Un nouveau déploiement crée toujours de nouvelles ressources. 1. La modification directe CloudFormation-managed des ressources en dehors de la pile entraîne une dérive de la pile. Toute migration de données doit se faire au niveau des données, et non au niveau de l'infrastructure. 1. L'UUID de la solution est généré de manière aléatoire à chaque nouveau déploiement. La nouvelle pile aura un UUID différent de celui d'origine. 1. La restauration (PITR) est activée par défaut pour Point-in-Time les tables DynamoDB, ce qui permet d'effectuer des sauvegardes continues au cours des 35 derniers jours. ## Processus de rétablissement ### Étape 1 : Identifier les ressources conservées Avant de déployer une nouvelle pile, localisez les ressources conservées dans la pile supprimée. ``` # List retained DynamoDB tables (look for DLT naming patterns) aws dynamodb list-tables --query "TableNames[?contains(@, 'ScenariosTable') || contains(@, 'HistoryTable')]" # List retained S3 buckets (look for DLT naming patterns) aws s3api list-buckets --query "Buckets[?contains(Name, 'dlttestrunnerstoragedlts') || contains(Name, 'dltconsoleresourcesdltda')]" ``` Si vous avez noté les sorties de la CloudFormation pile avant la suppression, utilisez ces noms exacts. Les résultats pertinents étaient les suivants : + `ScenariosBucket`— le nom du compartiment S3 + `ScenariosTable`— le nom de la table des scénarios DynamoDB Pour les ressources qui ne sont pas exposées sous forme de sorties de pile (telles que la table d'historique), `list-stack-resources` utilisez-la avant la suppression pour obtenir les identifiants des ressources physiques. Cette commande répertorie toutes les ressources de la pile, qu'elles aient ou non une sortie correspondante. ### Étape 2 : Déployer une nouvelle pile DLT Déployez une nouvelle pile DLT en utilisant la même version de CloudFormation modèle (ou une version plus récente). Utilisez les mêmes paramètres que le déploiement d'origine (paramètres VPC, e-mail de l'administrateur, etc.). ``` aws cloudformation create-stack \ --stack-name distributed-load-testing-new \ --template-url https://s3.amazonaws.com/solutions-reference/distributed-load-testing-on-aws/latest/distributed-load-testing-on-aws.template \ --parameters ParameterKey=AdminName,ParameterValue= \ ParameterKey=AdminEmail,ParameterValue= \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND ``` Attendez que la pile atteigne `CREATE_COMPLETE` son statut. ### Étape 3 : Identifier les ressources de la nouvelle pile Récupérez les noms des ressources à partir des sorties de la nouvelle pile. ``` aws cloudformation describe-stacks \ --stack-name distributed-load-testing-new \ --query "Stacks[0].Outputs" ``` Notez les valeurs pour : + `ScenariosBucket`(nouveau nom du bucket) + `ScenariosTable`(nouveau nom de table) Pour toute ressource non exposée sous forme de sortie de pile (telle que la table d'historique), utilisez cette `list-stack-resources` option pour la rechercher par son identifiant logique : ``` aws cloudformation list-stack-resources \ --stack-name distributed-load-testing-new \ --query "StackResourceSummaries[?contains(LogicalResourceId, 'HistoryTable')].{LogicalId:LogicalResourceId,PhysicalId:PhysicalResourceId}" ``` Cette commande répertorie toutes les ressources gérées par la pile. Vous pouvez filtrer par sous-chaîne d'ID logique pour trouver n'importe quelle ressource. ### Étape 4 : migrer les données DynamoDB Exportez les données des tables conservées et importez-les dans les nouvelles tables. Utilisez l'exportation de données DynamoDB ou les opérations de numérisation et d'écriture. **Option A : utilisation de Export/Import DynamoDB (recommandée pour les grands ensembles de données)** Pour les tables contenant des milliers d'éléments, utilisez une exportation DynamoDB vers S3 suivie d'une importation : ``` # Export from retained table to S3 aws dynamodb export-table-to-point-in-time \ --table-arn arn:aws:dynamodb:::table/ \ --s3-bucket \ --s3-prefix dlt-migration/scenarios/ \ --export-format DYNAMODB_JSON # Wait for export to complete, then import into new table aws dynamodb import-table \ --s3-bucket-source S3Bucket=,S3KeyPrefix=dlt-migration/scenarios/ \ --table-creation-parameters '{"TableName":"","KeySchema":[{"AttributeName":"testId","KeyType":"HASH"}],"AttributeDefinitions":[{"AttributeName":"testId","AttributeType":"S"}],"BillingMode":"PAY_PER_REQUEST"}' \ --input-format DYNAMODB_JSON ``` **Note** L'`import-table`API crée une nouvelle table. Étant donné que la nouvelle pile a déjà créé la table cible, utilisez plutôt l'option B ou supprimez d'abord la nouvelle table vide et recréez-la par importation (cela provoquera une dérive de la pile, voir l'avertissement ci-dessous). **Option B : Numériser et BatchWrite (recommandé)** Cette approche permet de lire directement les tables conservées et d'écrire dans les tables de la nouvelle pile sans provoquer de dérive de la pile. Il nécessite Python 3 et la `boto3` bibliothèque. ``` # Install boto3 if not already available pip install boto3 ``` ``` #!/usr/bin/env python3 """Migrate DynamoDB items directly from retained tables to new stack tables.""" import boto3 dynamodb = boto3.resource("dynamodb", region_name="") def migrate_table(source_table_name, target_table_name): source = dynamodb.Table(source_table_name) target = dynamodb.Table(target_table_name) # Scan all items from the retained table (handles pagination automatically) items = [] response = source.scan() items.extend(response["Items"]) while "LastEvaluatedKey" in response: response = source.scan(ExclusiveStartKey=response["LastEvaluatedKey"]) items.extend(response["Items"]) print(f"Scanned {len(items)} items from {source_table_name}") # Write items to the new table using batch_writer (handles batching automatically) with target.batch_writer() as batch: for item in items: batch.put_item(Item=item) print(f"Wrote {len(items)} items to {target_table_name}") # Migrate scenarios migrate_table("", "") # Migrate history migrate_table("", "") ``` Pour les tables de grande taille (des dizaines de milliers d'éléments), pensez à utiliser des segments de numérisation parallèles pour accélérer la phase de lecture. **Option C : Restaurer à partir du PITR (dans un délai de 35 jours)** Si la pile a été supprimée au cours des 35 derniers jours et que le PITR a été activé (c'est le cas par défaut), vous pouvez restaurer la table à un moment donné. Cependant, les restaurations PITR créent une nouvelle table portant un nom différent. Vous devez donc toujours copier les données dans la table gérée par pile à l'aide de l'option B. ``` # Restore to a new temporary table aws dynamodb restore-table-to-point-in-time \ --source-table-name \ --target-table-name dlt-scenarios-restored \ --restore-date-time # Then scan from dlt-scenarios-restored and batch-write into the new stack's table ``` ### Étape 5 : migrer les données S3 Copiez les scripts de test et les fichiers de résultats du bucket conservé vers le bucket de la nouvelle pile. ``` # Copy all objects from the old scenarios bucket to the new one aws s3 sync \ s3:// \ s3:// \ --source-region \ --region ``` Cela copie : + Scripts de test (`.jmx`fichiers JMeter, scripts K6, fichiers Locust, archives ZIP) + Fichiers XML de résultats de test organisés par ID de test et par région + Ressources et plugins du framework JMeter ### Étape 6 : vérifier la migration 1. Connectez-vous à la console Web DLT à l'aide de l'URL de la nouvelle pile (qui se trouve dans la sortie de la `WebConsole` pile). 1. Vérifiez que tous les scénarios de test apparaissent dans la liste des scénarios. 1. Ouvrez des scénarios individuels et vérifiez que l'historique des tests est visible. 1. Vérifiez que les scripts de test sont téléchargeables depuis la page détaillée du scénario. 1. Exécutez un petit test pour vérifier le fonctionnement de bout en bout de la nouvelle pile. ### Étape 7 : Nettoyer les ressources conservées Après avoir vérifié que toutes les données ont bien été migrées, supprimez les anciennes ressources conservées afin d'éviter des coûts de stockage permanents. ``` # Delete old DynamoDB tables aws dynamodb delete-table --table-name aws dynamodb delete-table --table-name # Empty and delete old S3 buckets aws s3 rm s3:// --recursive aws s3api delete-bucket --bucket aws s3 rm s3:// --recursive aws s3api delete-bucket --bucket aws s3 rm s3:// --recursive aws s3api delete-bucket --bucket ``` N'effectuez cette étape qu'après avoir confirmé que la nouvelle pile est pleinement opérationnelle et que toutes les données historiques sont intactes. ## Éviter la dérive des piles La dérive de la pile se produit lorsque l'état réel d'une ressource diffère de ce qui CloudFormation était attendu. Pour éviter toute dérive au cours de ce processus de restauration : + NE renommez ni ne modifiez directement les tables DynamoDB ou les compartiments S3 de la nouvelle pile. + NE PAS utiliser `import-table` pour remplacer les tables de la nouvelle pile (cela nécessiterait d'abord de supprimer la CloudFormation-managed table). + NE modifiez PAS les politiques IAM, les politiques de compartiment ou les paramètres de table en dehors de CloudFormation. + N'utilisez que des opérations au niveau des données :`PutItem`,`BatchWriteItem`,`s3 sync`,`s3 cp`. + ÉCRIVEZ les données dans les tables et les compartiments CloudFormation créés. L'ajout d'éléments à une table DynamoDB ou d'objets à un compartiment S3 ne constitue pas une dérive. L'écriture de données dans CloudFormation-managed des tables et des compartiments est sûre car elle CloudFormation permet de suivre la configuration des ressources (schéma de table, mode de facturation, paramètres de chiffrement), et non le contenu des données. ## Ce qui ne peut pas être récupéré Les éléments suivants sont perdus lorsqu'une pile est supprimée et ne peuvent pas être restaurés par le biais de ce processus : | Élément | Raison | | --- | --- | | Comptes utilisateurs Cognito | Le groupe d'utilisateurs est supprimé avec la pile. Les utilisateurs doivent se réinscrire. | | EventBridge Horaires actifs | Les règles de test planifiées sont supprimées. Recréez les plannings manuellement dans l'interface utilisateur DLT. | | CloudWatch tableaux de bord | Per-test les tableaux de bord (`EcsLoadTesting*`) sont supprimés. Les nouvelles exécutions créeront de nouveaux tableaux de bord. | | UUID de la solution | Un nouvel UUID aléatoire est généré. Cela n'affecte que la corrélation des métriques opérationnelles. | | Associations de stack régionales | Les piles régionales doivent être redéployées et réassociées à la nouvelle pile du hub. | ## Mesures préventives Pour simplifier les futurs scénarios de restauration, procédez comme suit : 1. Enregistrez les sorties de la pile avant toute suppression. Enregistrez les noms des tables `ScenariosBucket``ScenariosTable`,, et d'historique. 1. Activez DynamoDB PITR (activé par défaut dans DLT). Vérifiez qu'il reste actif. 1. Activez le versionnement S3 (activé par défaut dans le compartiment des scénarios). Cela protège contre la suppression accidentelle d'objets. 1. Envisagez d'activer la protection contre la suppression de DynamoDB sur les scénarios et les tables d'historique à titre de protection supplémentaire : ``` aws dynamodb update-table \ --table-name \ --deletion-protection-enabled ``` 1. Utilisez AWS Backup pour créer des sauvegardes planifiées des tables DynamoDB afin de les conserver à long terme au-delà de la période PITR de 35 jours.