Amazon DynamoDB를 위한 백업 전략

이 글은 AWS Database Delivery Blog에 게시된 Backup strategies for Amazon DynamoDB by Ted Zamborsky을 한국어 번역 및 편집하였습니다.

데이터베이스에 관해 논의할 때 가장 중요한 질문 중 하나는 “데이터를 어떻게 백업하고 복원할 것인가?”입니다. 백업은 모든 재해 복구 전략의 핵심 구성 요소이며, 주로 복구 시점 목표(RPO)와 복구 시간 목표(RTO)에 따라 관리됩니다. 백업 전략은 최소한의 관리만으로 요구사항을 지원하고, 비지니스에 지장을 주어서는 안되며, 비용 효율적이어야 합니다. 이 게시글에서는 Amazon DynamoDB에서 사용할 수 있는 다양한 백업 전략과, 각 백업 전략 마다 최적의 사용 사례를 살펴보겠습니다.

Amazon DynamoDB 특정 시점 복구(PITR)

DynamoDB 특정 시점 복구(PITR)는 DynamoDB에 포함되어 있는 완전 관리형 연속 백업 기능입니다. PITR을 활성화하면 테이블을 최근 35일 내에서 어느 시점이던 초 단위로 복원할 수 있습니다. PITR 백업은 시스템 레벨에서 이루어지며, AWS 관리 계정을 통해 관리됩니다. 만약 계정이 유출되더라도 권한이 없는 사용자는 이 백업을 삭제할 수 없습니다. 아래 예제와 같이 AWS 관리 콘솔, AWS SDK 또는 AWS 명령줄 인터페이스(AWS CLI)를 통해 활성화 할 수 있습니다.

aws dynamodb update-continuous-backups --table-name <SOURCE-TABLE> -—point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

PITR을 활성화해도 소급 적용이 되지 않기 때문에 가장 빠르게 복원 가능한 시점은 PITR을 활성화한 시점입니다.

PITR을 활성화하면 DynamoDB 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 테이블을 특정 시점으로 복원할 수 있지만, 일부 원본 테이블 레벨의 설정은 새롭게 복원된 테이블에 자동으로 적용되지 않습니다. 이러한 것들에는 오토 스케일링, 스트림스, 생존시간(TTL) 등이 포함됩니다. AWS CloudFormation 템플릿을 사용하여 원본 테이블 레벨의 설정을 복원된 Amazon DynamoDB 테이블에 자동으로 적용하기 위한 이벤트 기반의 솔루션에 대해서는 복원된 Amazon DynamoDB 테이블에서 테이블 설정 업데이트 자동화를 참조하세요.

PITR은 데이터 손실에 대한 위험을 매우 최소화하고, 테이블에 대해 실수로 데이터를 삭제하거나 데이터를 생성하는 것으로부터 사용자를 보호하기 때문에 데이터 손실에 민감한 워크로드에 매우 유용합니다. 초 단위 수준으로 복원이 가능하기 때문에 엄격한 RPO 목표를 손쉽게 달성할 수 있습니다. 예약 백업과 같은 대안을 고려하는 경우, 마지막 백업 지점으로만 복구가 가능하므로 이는 몇 시간 동안의 데이터를 손실을 유발할 수도 있습니다. PITR에 대한 개요는 Amazon DynamoDB 연속 백업 및 특정 시점 복구(PITR)을 참조하세요.

Amazon DynamoDB 온디맨드 백업

온디맨드 백업을 사용하면 테이블 성능에 영향을 주지 않고 DynamoDB의 전체 테이블에 대한 백업을 수행할 수 있습니다. 서비스 API나 콘솔을 사용하여 개별 백업을 새로운 테이블로 복원할 수 있습니다. 백업을 새로운 테이블로 복원할 때, DynamoDB에서는 글로벌 보조 인덱스(GSI)나 로컬 보조 인덱스(LSI) 또는 암호화 설정 같은 암호화를 유지하거나 변경할 수 있습니다.

콘솔, 프로그래밍 언어를 위한 AWS SDK 또는 AWS CLI를 통해 온디맨드 백업을 수행할 수 있습니다. 다음은 온디맨드 백업을 수행하기 위한 AWS CLI 명령의 기본 예제입니다.

aws dynamodb create-backup --table-name <SOURCE-TABLE> --backup-name <BACKUP-NAME>

많은 워크로드는 매주 또는 매일 특정 시간에 예약 백업 수행이 필요한데, 언뜻 보기에는 온디맨드 백업의 기능이 아닌 것처럼 보일 수 있습니다. 예약된 DynamoDB 백업을 수행하려면, 완전 관리형이고 중앙화된 데이터 보호 서비스인 AWS Backup을 사용할 수 있습니다.  AWS Backup을 사용하여 DynamoDB 테이블에 대한 백업 스케줄을 등록하고 관리할 수 있습니다. AWS Backup은 교차 계정 간 백업이 가능하며, 백업을 다른 AWS 계정으로 복할 수 있도록하여 추가적인 데이터 보호 기능을 제공합니다. 추가적으로 컴플라이언스 요구사항으로 인해 장기간 백업을 유지해야 하는 경우, 콜드 스토리지를 활용하여 비용을 절감할 수 있습니다.

다음은 온디맨드 백업에 적합한 몇 가지 시나리오입니다.

• 규정 준수를 위해 데이터를 35일 이상 보관(미국 증권거래위원회는 데이터를 7년 동안 보관하도록 요구하고 있음)해야 경우
• 개발과 테스트 계정과 같이 AWS 계정 간 테이블 복제가 필요한 경우
• 데이터를 AWS의 다른 리전으로 복제하거나 이동해야 하는 경우

PITR과 온디맨드 백업 중에서 선택하는 방법

몇 가지 다른 DynamoDB 워크로드를 고려해 보겠습니다.

• 워크로드 1 – RPO 요구사항이 45분이고 데이터를 30일 동안 저장해야 하는 웹 애플리케이션을 지원하는 DynamoDB 테이블
• 워크로드 2 – RPO 요구사항이 15분이고 데이터를 7년 동안 보관해야 하는 규정 준수 요건을 갖춘 금융 서비스 애플리케이션을 지원하는 DynamoDB 테이블
• 워크로드 3 – 연구 애플리케이션을 지원하는 DynamoDB 테이블. 테이블에 저장되어 있는 데이터는 연구 애플리케이션에서 수행되는 시뮬레이션에서 조회용도로 사용 되기 때문에 데이터가 변경되지 않습니다. 따라서 RPO 요구사항은 없지만 데이터를 재생성하는데 비용이 많이 필요하기 때문에 여전히 백업이 필요합니다.

첫 번째 워크로드의 경우, PITR이 전체 백업의 요구사항을 충족합니다. PITR은 초 단위로 복원이 가능하고 35일 동안 데이터가 보관되기 때문에 45분의 RPO 요구사항과 30일 동안이 데이터 보관의 요구사항을 쉽게 충족합니다.

두 번째 워크로드는 첫 번째 워크로드보다 조금 더 복잡합니다. PITR을 활성화하면 RPO 요구사항은 만족하지만 7년 동안 데이터를 보관해야 하는 요구사항은 충족하지 못합니다. 이럴 경우, 이 요구사항을 충족하기 위해 PITR과 함께 AWS Backup을 사용할 수 있습니다. AWS Backup을 사용해서 온디맨드 백업에 대한 예약, 7년 동안 데이터 보관 그리고 비용 절감을 위해 데이터를 콜드 스토리지에 저장할 수 있습니다.

세 번째 워크로드의 경우, 데이터가 변경되지 않기 때문에 단일 온디맨드 백업만으로 요구사항을 충족할 수 있습니다.

이러한 예시를 통해 우리는 몇 가지 일반적인 가이드라인을 확인할 수 있습니다.

• 대부분의 테이블 특히 RPO의 요구사항이 짧은 테이블의 경우, PITR을 사용하세요.
• 짧은 RPO의 요구하지만 35일 이상 복제본을 보관해야 하는 경우, PITR과 AWS Backup의 온디맨드 백업을 사용하세요.

결론

이 게시글에서는 백업과 규정 준수 요구사항을 충족하는데 도움이 되는 DynamoDB 테이블에 대한 백업 방법들에 대해 알아보았습니다. 자세한 내용은 온디맨드 백업과 복구와 특정 시점 복구를 참고하세요.

이 게시글을 통해 여러 분의 DynamoDB 백업 전략을 평가하기 위한 출발점으로 삼으시길 바랍니다.