AWS DynamoDB 장기 데이터 보관 전략: 실무 가이드

7년 이상의 장기 데이터 보관이 필요할 때, 어떤 방법이 가장 효율적일까요?

들어가며

많은 기업들이 규정 준수(Compliance) 요구사항으로 인해 데이터를 장기간 보관해야 합니다. 금융 거래 내역은 7년, 의료 기록은 10년 이상 보관해야 하는 경우가 흔합니다.

DynamoDB를 사용하는 환경에서 이런 장기 보관 요구사항을 어떻게 충족할 수 있을까요? 오늘은 실무에서 자주 고려되는 4가지 방법을 비교하고, 각각 언제 사용해야 하는지 알아보겠습니다.

4가지 백업 방법 비교

1. DynamoDB PITR (Point-in-Time Recovery)

활성화 방법: DynamoDB 콘솔 → 테이블 → 백업 → PITR 활성화

특징

최근 35일 이내 어느 시점으로든 복구 가능
초 단위 정밀도로 복구 지원
활성화만 하면 자동으로 동작

제한사항

⚠️ 최대 보관 기간: 35일
→ 장기 보관 목적으로는 부적합!

적합한 사용 사례

실수로 데이터 삭제했을 때 빠른 복구
최근 변경사항 롤백
운영 중 발생하는 단기 장애 대응

2. AWS Backup (✅ 권장)

설정 위치: AWS Backup 콘솔 → 백업 계획 생성

특징

완전 관리형 백업 서비스
백업 일정 자동화 (매일/매주/매월)
보존 기간 설정 (7년 이상 가능)
여러 AWS 서비스 통합 관리

실제 설정 예시

{
  "BackupPlan": {
    "BackupPlanName": "DynamoDB-7Year-Retention",
    "Rules": [
      {
        "RuleName": "DailyBackup",
        "TargetBackupVaultName": "Default",
        "ScheduleExpression": "cron(0 5 ? * * *)",
        "StartWindowMinutes": 60,
        "CompletionWindowMinutes": 120,
        "Lifecycle": {
          "MoveToColdStorageAfterDays": 30,
          "DeleteAfterDays": 2555
        }
      }
    ]
  }
}

비용 구조

항목	비용
웜 스토리지	GB당 $0.05/월
콜드 스토리지	GB당 $0.01/월
복원	GB당 $0.02

적합한 사용 사례

규정 준수를 위한 장기 보관
중앙 집중식 백업 관리가 필요한 경우
운영 오버헤드를 최소화하고 싶을 때

3. 주문형(On-Demand) 백업

실행 방법: DynamoDB 콘솔 → 테이블 → 백업 → 백업 생성

특징

원하는 시점에 수동으로 백업 생성
명시적으로 삭제하기 전까지 보관
추가 비용 없이 기본 제공

문제점

월요일: 백업 생성 ✅
화요일: 백업 생성 ✅  
수요일: 야근으로 깜빡함 ❌
목요일: 휴가라서 못함 ❌
금요일: 장애 발생... 백업이 없다!

실무에서의 현실

담당자가 바뀌면 인수인계 누락
휴가, 퇴사 시 백업 공백 발생
7년간 매일 수동 작업은 비현실적

적합한 사용 사례

대규모 변경 작업 전 일회성 백업
마이그레이션 전 스냅샷
테스트/개발 환경 복제

4. EventBridge + Lambda 커스텀 솔루션

아키텍처: EventBridge(스케줄) → Lambda → DynamoDB Backup API → S3

Lambda 코드 예시

import boto3
from datetime import datetime

def lambda_handler(event, context):
    dynamodb = boto3.client('dynamodb')
    s3 = boto3.client('s3')

    table_name = 'TransactionTable'
    backup_name = f"{table_name}-{datetime.now().strftime('%Y%m%d-%H%M%S')}"

    try:
        # 백업 생성
        response = dynamodb.create_backup(
            TableName=table_name,
            BackupName=backup_name
        )

        return {
            'statusCode': 200,
            'body': f"Backup created: {response['BackupDetails']['BackupArn']}"
        }

    except Exception as e:
        # 에러 알림 로직 필요
        raise e

필요한 추가 작업들

에러 처리 및 알림 설정
백업 성공/실패 모니터링
Lambda 코드 유지보수
IAM 권한 관리
비용 모니터링

적합한 사용 사례

특수한 비즈니스 로직이 필요한 경우
백업 전후 커스텀 작업이 필요한 경우
AWS Backup이 지원하지 않는 요구사항

한눈에 비교

구분	PITR	AWS Backup	주문형	Lambda
최대 보관	35일	무제한	무제한	무제한
자동화	✅	✅	❌	✅
운영 오버헤드	낮음	낮음	높음	중간
코드 필요	❌	❌	❌	✅
관리형	✅	✅	–	❌
7년 보관	❌	✅	✅	✅

실무 권장 아키텍처

대부분의 경우, PITR + AWS Backup 조합을 권장합니다.

┌─────────────────────────────────────────────────────────────┐
│                    DynamoDB 테이블                          │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│           ┌──────────────┴──────────────┐                   │
│           ▼                             ▼                   │
│  ┌─────────────────┐          ┌─────────────────┐          │
│  │      PITR       │          │   AWS Backup    │          │
│  │   (단기 복구)    │          │   (장기 보관)    │          │
│  ├─────────────────┤          ├─────────────────┤          │
│  │ • 최근 35일     │          │ • 7년 보관      │          │
│  │ • 초 단위 복구  │          │ • 월 1회 백업   │          │
│  │ • 운영 실수 대응│          │ • 콜드 스토리지 │          │
│  └─────────────────┘          └─────────────────┘          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

이 조합의 장점

단기: PITR로 빠른 복구 (실수, 버그 대응)
장기: AWS Backup으로 규정 준수
비용: 콜드 스토리지로 장기 보관 비용 절감
운영: 둘 다 관리형 서비스로 오버헤드 최소화

마무리

데이터 백업 전략을 선택할 때 기억해야 할 핵심은 다음과 같습니다:

원칙	설명
자동화 우선	사람이 반복해야 하는 작업은 반드시 누락된다
관리형 서비스	직접 구축보다 관리형 서비스가 운영 효율적
요구사항 확인	보관 기간, 복구 시간 등 요구사항 먼저 파악
비용 고려	장기 보관은 콜드 스토리지 활용

장기 보관이 필요하다면 AWS Backup, 단기 복구가 중요하다면 PITR을 선택하세요. 대부분의 프로덕션 환경에서는 둘 다 활성화하는 것을 권장합니다.

이 글이 도움이 되셨다면 공유해주세요! 질문은 댓글로 남겨주시면 답변드리겠습니다. 🙂