スタック削除後の 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 を使用して物理リソース ID を取得します。このコマンドは、対応する出力があるかどうかに関係なく、スタック内のすべてのリソースを一覧表示します。

ステップ 2: 新しい DLT スタックをデプロイする

同じ CloudFormation テンプレートバージョン (またはそれ以降) を使用して、新しい DLT スタックをデプロイします。元のデプロイと同じパラメータ (VPC 設定、管理者 E メールなど) を使用します。

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 データエクスポート、またはスキャンと書き込みオペレーションを使用します。

オプション A: DynamoDB エクスポート/インポートの使用 (大規模なデータセットに推奨)

数千の項目があるテーブルの場合は、S3 への DynamoDB エクスポートとインポートを使用します。

# 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 はデータコンテンツではなくリソース設定 (テーブルスキーマ、請求モード、暗号化設定) を追跡するからです。

復旧できないもの

スタックが削除されると、以下は失われ、このプロセスでは復元できません。

予防策

将来の復旧シナリオを簡素化するには。