전역 테이블 관리 모범 사례 및 요구 사항
Amazon DynamoDB 전역 테이블을 사용하여 AWS 리전 간에 테이블 데이터를 복제할 수 있습니다. 전역 테이블의 복제본 테이블과 보조 인덱스의 쓰기 용량을 동일하게 설정해 데이터를 적절히 복제하는 것이 중요합니다.
향후 명확성을 위해 언젠가 글로벌 테이블로 바뀔 수 있는 테이블의 이름에 리전을 넣지 않는 것이 유용할 수 있습니다.
주의
각 글로벌 테이블의 테이블 이름은 AWS 계정 내에서 고유해야 합니다.
글로벌 테이블 버전
사용 중인 글로벌 테이블의 버전을 확인하려면 사용 중인 글로벌 테이블 버전 확인을 참조하세요.
용량 관리 요구 사항
전역 테이블에는 다음 두 가지 방법 중 하나로 구성된 처리량 용량이 있어야 합니다.
-
복제한 쓰기 요청 단위(rWRU)로 측정한 온디맨드 용량 모드
-
복제한 쓰기 요청 단위(rWRU)로 측정한 Auto Scaling으로 프로비저닝된 용량 모드
Auto Scaling으로 프로비저닝된 온디맨드 모드 또는 온디맨드 용량 모드를 사용하면 전역 테이블의 모든 리전에 대한 복제된 쓰기를 수행하는 데 충분한 용량을 전역 테이블에 확보하는 데 도움이 됩니다.
참고
리전에서 하나의 테이블 용량 모드에서 다른 용량 모드로 전환하면 모든 복제본의 모드가 전환됩니다.
글로벌 테이블 배포
AWS CloudFormation에서 각 글로벌 테이블은 단일 리전에서 단일 스택에 의해 제어됩니다. 이는 복제본의 수와 무관합니다. 템플릿을 배포하면 CloudFormation은 단일 스택 작업의 일부로 모든 복제본을 생성/업데이트합니다. 이러한 이유로 동일한 AWS::DynamoDB::GlobalTable 리소스를 여러 리전에 배포하면 안 됩니다. 그렇게 하는 것은 오류를 유발하며 지원되지 않습니다.
여러 리전에 애플리케이션 템플릿을 배포하는 경우 조건을 사용하여 하나의 리전에서만 리소스를 생성할 수 있습니다. 또는 AWS::DynamoDB::GlobalTable 리소스를 애플리케이션 스택과 별도의 스택에 정의하고 단일 리전에만 배포되도록 선택할 수 있습니다. 자세한 내용은 CloudFormation의 글로벌 테이블을 참조하세요.
DynamoDB 테이블은 AWS::DynamoDB::Table로 지칭되고 글로벌 테이블은 AWS::DynamoDB::GlobalTable로 지칭됩니다. CloudFormation에 관한 한, 이것은 본질적으로 두 개의 다른 리소스가 됩니다. 따라서 한 가지 방법은 GlobalTable 구문을 사용하여 글로벌일 수 있는 모든 테이블을 만드는 것입니다. 그런 다음 이를 독립 실행형 테이블로 유지하여 시작하고 필요한 경우 나중에 리전에 추가할 수 있습니다.
CloudFormation을 사용하는 동안 일반 테이블을 변환하려는 경우 권장되는 방법은 다음과 같습니다.
삭제 정책을 유지하도록 설정합니다.
스택에서 테이블을 제거합니다.
콘솔에서 테이블을 글로벌 테이블로 변환합니다.
글로벌 테이블을 새 리소스로 스택에 가져옵니다.
참고
교차 계정 복제는 현재 지원되지 않습니다.
글로벌 테이블을 사용하여 잠재적인 리전 중단에 대처
각각 로컬 DynamoDB 엔드포인트에 액세스하는 대체 리전에서 실행 스택의 독립적인 복사본을 보유하거나 신속하게 생성할 수 있습니다.
Route53 또는 AWS Global Accelerator를 사용하여 가장 가까운 정상 리전으로 라우팅합니다. 또는 클라이언트가 사용할 수 있는 여러 엔드포인트를 인식하도록 합니다.
각 리전의 상태 확인을 사용하면 DynamoDB의 성능 저하 여부를 포함하여 스택에 문제가 있는지 신뢰성 있게 판단할 수 있습니다. 예를 들어, DynamoDB 엔드포인트가 작동 중인지 확인하는 ping만 수행하지 말고 실제로 완전한 성공적인 데이터베이스 흐름을 보장하는 호출을 수행합니다.
상태 확인에 실패하는 경우 Route53으로 DNS 항목을 업데이트하거나, Global Accelerator의 경로를 다르게 설정하거나, 클라이언트가 다른 엔드포인트를 선택하도록 하여 트래픽을 다른 리전으로 라우팅할 수 있습니다. 글로벌 테이블은 데이터가 지속적으로 동기화되므로 Recovery Point Objective(RPO)가 우수하고 두 리전에서 모두 테이블을 읽기 및 쓰기 트래픽에 사용할 수 있도록 유지하므로 Recovery Time Objective(RTO)가 우수합니다.
상태 확인에 대한 자세한 내용은 상태 확인 유형을 참조하세요.
참고
DynamoDB는 다른 서비스가 컨트롤 플레인 작업을 구축하는 데 자주 사용하는 핵심 서비스이므로 한 리전에서 다른 서비스가 영향을 받지 않으면서 DynamoDB의 서비스가 저하되는 시나리오는 거의 발생하지 않습니다.
글로벌 테이블 백업
글로벌 테이블을 백업할 때는 한 리전의 테이블을 백업이면 충분하며 모든 리전의 모든 테이블을 백업할 필요는 없습니다. 실수로 삭제되거나 수정된 데이터를 복구하는 것이 목적이라면 한 리전의 PITR이면 충분합니다. 마찬가지로 규정 요건과 같은 기록 목적으로 스냅샷을 보존할 때는 한 리전에 백업하는 것으로 충분합니다. 백업된 데이터는 AWS Backup을 통해 여러 리전으로 복제할 수 있습니다.
복제본 및 쓰기 단위 계산
계획하려면 하나의 리전에서 수행할 쓰기 횟수를 가져와서 다른 리전마다 발생하는 쓰기 횟수에 추가해야 합니다. 하나의 리전에서 수행되는 모든 쓰기는 모든 복제본 리전에서도 수행되어야 하므로 이 작업이 매우 중요합니다. 모든 쓰기를 처리할 용량이 충분하지 않으면 용량 예외가 발생합니다. 또한 리전 간 복제 대기 시간이 증가합니다.
예를 들어, 오하이오의 복제본 테이블의 초당 쓰기는 5회, 버지니아 북부의 복제본 테이블의 초당 쓰기는 10회, 아일랜드의 초당 복제본 테이블의 초당 쓰기는 5회로 예상한다고 가정하겠습니다. 이 경우 20rWCU(각 지역: 오하이오, 버지니아 북부 및 아일랜드의 rWRU)를 사용하는 것으로 예상해야 합니다. 즉, 세 리전에서 모두 총 60rWCU를 사용하는 것으로 예상해야 합니다.
Auto Scaling 및 DynamoDB를 통한 프로비저닝된 용량에 대한 자세한 내용은 DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리 단원을 참조하세요.
참고
테이블이 Auto Scaling과 함께 프로비저닝된 용량 모드로 실행되는 경우 프로비저닝된 쓰기 용량은 각 리전의 Auto Scaling 설정 내에서 유동적으로 허용됩니다.
