기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

스택 삭제 후 DLT 데이터 복구

이 섹션에서는 원래 스택이 삭제된 후 테스트 시나리오를 복원하고 기록을 새 DLT 스택으로 실행하는 방법을 설명합니다. 이는 고객의 S3 버킷과 DynamoDB 테이블이 유지되고(기본 동작) 고객이 새 배포에 다시 연결하려는 경우에 적용됩니다.

배경

DLT 스택이 삭제되면 데이터 보호 정책으로 인해 다음 리소스가 고객의 AWS 계정에 유지됩니다.

모든 리소스 이름은 CloudFormation에서 자동으로 생성됩니다. 새 스택을 배포할 때 예측할 수 없으며 파라미터로 지정할 수 없습니다.

중요한 제약 조건

복구 프로세스

1단계: 보존된 리소스 식별

새 스택을 배포하기 전에 삭제된 스택에서 보관된 리소스를 찾습니다.

# 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')]"

삭제 전에 CloudFormation 스택 출력을 기록한 경우 정확한 이름을 사용합니다. 관련 출력은 다음과 같습니다.

스택 출력으로 노출되지 않은 리소스(예: 기록 테이블)의 경우 삭제 list-stack-resources 전에를 사용하여 물리적 리소스 IDs를 가져옵니다. 이 명령은 스택에 해당 출력이 있는지 여부에 관계없이 스택의 모든 리소스를 나열합니다.

2단계: 새 DLT 스택 배포

동일한 CloudFormation 템플릿 버전(또는 최신 버전)을 사용하여 새 DLT 스택을 배포합니다. 원래 배포와 동일한 파라미터를 사용합니다(VPC 설정, 관리자 이메일 등).

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=<admin-name> \
               ParameterKey=AdminEmail,ParameterValue=<admin-email> \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND

스택이 CREATE_COMPLETE 상태에 도달할 때까지 기다립니다.

3단계: 새 스택의 리소스 식별

새 스택의 출력에서 리소스 이름을 검색합니다.

aws cloudformation describe-stacks \
  --stack-name distributed-load-testing-new \
  --query "Stacks[0].Outputs"

다음에 대한 값을 기록해 둡니다.

스택 출력으로 노출되지 않은 리소스(예: 기록 테이블)의 경우 list-stack-resources를 사용하여 논리적 ID로 찾습니다.

aws cloudformation list-stack-resources \
  --stack-name distributed-load-testing-new \
  --query "StackResourceSummaries[?contains(LogicalResourceId, 'HistoryTable')].{LogicalId:LogicalResourceId,PhysicalId:PhysicalResourceId}"

이 명령은 스택이 관리하는 모든 리소스를 나열합니다. 논리적 ID 하위 문자열을 기준으로 필터링하여 리소스를 찾을 수 있습니다.

4단계: DynamoDB 데이터 마이그레이션

보관된 테이블에서 데이터를 내보내고 새 테이블로 가져옵니다. DynamoDB 데이터 내보내기 또는 scan-and-write 작업을 사용합니다.

옵션 A: DynamoDB 내보내기/가져오기 사용(대규모 데이터 세트에 권장)

수천 개의 항목이 있는 테이블의 경우 DynamoDB를 S3로 내보낸 다음 가져오기를 사용합니다.

# Export from retained table to S3
aws dynamodb export-table-to-point-in-time \
  --table-arn arn:aws:dynamodb:<region>:<account>:table/<old-scenarios-table> \
  --s3-bucket <temporary-export-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=<temporary-export-bucket>,S3KeyPrefix=dlt-migration/scenarios/ \
  --table-creation-parameters '{"TableName":"<new-scenarios-table>","KeySchema":[{"AttributeName":"testId","KeyType":"HASH"}],"AttributeDefinitions":[{"AttributeName":"testId","AttributeType":"S"}],"BillingMode":"PAY_PER_REQUEST"}' \
  --input-format DYNAMODB_JSON

옵션 B: 스캔 및 BatchWrite(권장)

이 접근 방식은 보관된 테이블에서 직접 읽고 스택 드리프트를 일으키지 않고 새 스택의 테이블에 씁니다. Python 3 및 boto3 라이브러리가 필요합니다.

# 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="<region>")

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("<old-scenarios-table>", "<new-scenarios-table>")

# Migrate history
migrate_table("<old-history-table>", "<new-history-table>")

큰 테이블(수만 개의 항목)의 경우 병렬 스캔 세그먼트를 사용하여 읽기 단계의 속도를 높이는 것이 좋습니다.

옵션 C: PITR에서 복원(35일 기간 이내인 경우)

스택이 지난 35일 이내에 삭제되었고 PITR이 활성화된 경우(기본값) 테이블을 특정 시점으로 복원할 수 있습니다. 그러나 PITR 복원은 다른 이름으로 새 테이블을 생성하므로 옵션 B를 사용하여 스택 관리형 테이블에 데이터를 복사해야 합니다.

# Restore to a new temporary table
aws dynamodb restore-table-to-point-in-time \
  --source-table-name <old-scenarios-table> \
  --target-table-name dlt-scenarios-restored \
  --restore-date-time <timestamp-before-deletion>

# Then scan from dlt-scenarios-restored and batch-write into the new stack's table

5단계: S3 데이터 마이그레이션

보관된 버킷의 테스트 스크립트와 결과 파일을 새 스택의 버킷으로 복사합니다.

# Copy all objects from the old scenarios bucket to the new one
aws s3 sync \
  s3://<old-scenarios-bucket> \
  s3://<new-scenarios-bucket> \
  --source-region <region> \
  --region <region>

이 복사본은 다음을 복사합니다.

6단계: 마이그레이션 확인

7단계: 보존된 리소스 정리

모든 데이터가 성공적으로 마이그레이션되었는지 확인한 후 보관된 이전 리소스를 삭제하여 지속적인 스토리지 비용을 방지합니다.

# Delete old DynamoDB tables
aws dynamodb delete-table --table-name <old-scenarios-table>
aws dynamodb delete-table --table-name <old-history-table>

# Empty and delete old S3 buckets
aws s3 rm s3://<old-scenarios-bucket> --recursive
aws s3api delete-bucket --bucket <old-scenarios-bucket>

aws s3 rm s3://<old-logs-bucket> --recursive
aws s3api delete-bucket --bucket <old-logs-bucket>

aws s3 rm s3://<old-console-bucket> --recursive
aws s3api delete-bucket --bucket <old-console-bucket>

새 스택이 모든 기록 데이터를 그대로 유지하면서 완전히 작동하는지 확인한 후에만이 단계를 수행합니다.

스택 드리프트 방지

스택 드리프트는 리소스의 실제 상태가 CloudFormation에서 예상하는 것과 다를 때 발생합니다. 이 복구 프로세스 중에 드리프트를 방지하려면:

CloudFormation은 데이터 콘텐츠가 아닌 리소스 구성(테이블 스키마, 결제 모드, 암호화 설정)을 추적하기 때문에 CloudFormation 관리형 테이블 및 버킷에 데이터를 쓰는 것은 안전합니다.

복구할 수 없는 항목

스택이 삭제되면 다음이 손실되고이 프로세스를 통해 복원할 수 없습니다.

예방 조치

향후 복구 시나리오를 간소화하려면: