글로벌 테이블을 배포할 때 의사 결정 및 작업에 다음 체크리스트를 사용하세요.
글로벌 테이블에 참여해야 하는 리전과 리전 수를 결정합니다.
애플리케이션의 쓰기 모드를 결정합니다. 자세한 내용은 DynamoDB 글로벌 테이블을 사용한 쓰기 모드 섹션을 참조하세요.
쓰기 모드에 따라 DynamoDB 글로벌 테이블을 사용한 요청 라우팅 전략을 계획합니다.
각 리전의 상태, 지연 시간, 오류에 대한 지표를 캡처합니다. DynamoDB 지표 목록은 AWS 블로그 게시물 Monitoring Amazon DynamoDB for Operational Awareness
에 있는 관찰해야 할 지표 목록을 참조하세요. 또한 합성 카나리아(장애를 감지하도록 설계된 인위적 요청으로, 탄광에 있는 카나리아에서 유래)를 사용하고 고객 트래픽을 실시간으로 관찰해야 합니다. 모든 문제가 DynamoDB 지표에 나타나는 것은 아닙니다. ReplicationLatency의 지속적 증가에 대한 경보를 설정하세요. 증가는 글로벌 테이블의 쓰기 설정이 리전마다 다른 잘못된 구성을 나타낼 수 있습니다. 이는 복제된 요청 실패와 지연 시간 증가로 이어질 수 있습니다. 리전 중단이 있음을 나타낼 수도 있습니다. 좋은 예는 최근 평균이 180,000밀리초를 초과할 경우 알림을 생성하는 것입니다. ReplicationLatency가 0으로 떨어지는 것을 관찰할 수도 있습니다. 이는 복제가 중단되었음을 나타냅니다.각 글로벌 테이블에 충분한 최대 읽기 및 쓰기 설정을 할당합니다.
리전 대피 사유를 미리 식별합니다. 결정에 사람의 판단이 수반되는 경우 모든 고려 사항을 문서화합니다. 이 작업은 압박을 받지 않는 상태에서 사전에 신중하게 수행해야 합니다.
리전 대피 시 취해야 하는 모든 조치를 위한 런북을 유지 관리합니다. 일반적으로 글로벌 테이블에 필요한 작업은 거의 없지만 나머지 스택을 이동하는 작업은 복잡할 수 있습니다.
참고
리전 장애 중에는 일부 컨트롤 플레인 작업이 저하될 수 있으므로 데이터 플레인 작업에만 의존하고 컨트롤 플레인 작업에는 의존하지 않는 것이 모범 사례입니다.
자세한 내용은 AWS 블로그 게시물 Build resilient applications with Amazon DynamoDB global tables: Part 4
를 참조하세요. 리전 대피를 포함하여 런북의 모든 측면을 정기적으로 테스트합니다. 테스트되지 않은 런북은 신뢰할 수 없는 런북입니다.
Resilience Hub를 사용하여 전체 애플리케이션(글로벌 테이블 포함)의 복원력을 평가하는 것을 고려해 보세요. Resilience Hub의 대시보드를 통해 전체 애플리케이션 포트폴리오 복원력 상태를 종합적으로 파악할 수 있습니다.
ARC 준비 상태 확인을 사용하여 애플리케이션의 현재 구성을 평가하고 모범 사례에서 벗어난 부분을 추적하는 것을 고려해 보세요.
Route 53 또는 Global Accelerator와 함께 사용할 상태 확인을 작성할 때는 DynamoDB 엔드포인트가 작동 중이라는 핑만으로는 충분하지 않습니다. IAM 구성 오류, 코드 배포 문제, DynamoDB 외부 스택 장애, 평균보다 높은 읽기 또는 쓰기 지연 시간 등 다양한 장애 모드는 포함되지 않기 때문입니다. 전체 데이터베이스 흐름을 실행하는 일련의 호출을 수행하는 것이 가장 좋습니다.
글로벌 테이블 배포에 대한 자주 묻는 질문(FAQ)
DynamoDB 글로벌 테이블의 전반적 사용에 유용한 원칙에는 어떤 것이 있나요?
DynamoDB 글로벌 테이블에는 제어 노브가 거의 없지만 여전히 여러 가지를 고려해야 합니다. 쓰기 모드, 라우팅 모델, 대피 프로세스를 결정해야 합니다. 글로벌 상태 유지를 위해서는 모든 리전에서 애플리케이션을 계측하고 경로를 조정하거나 대피를 수행할 준비가 되어 있어야 합니다. 그 보상으로 읽기 및 쓰기 지연 시간이 짧고 99.999% SLA(서비스 수준 계약)를 갖춘 전 세계에 분산된 데이터 세트를 보유할 수 있습니다.
글로벌 테이블의 요금은 어떻게 되나요?
기존 DynamoDB 테이블에 대한 쓰기 요금은 쓰기 용량 단위(WCU, 프로비저닝된 테이블의 경우) 또는 쓰기 요청 단위(WRU, 온디맨드 테이블의 경우)로 책정됩니다. 5KB 항목을 쓰면 5단위의 요금이 부과됩니다. 글로벌 테이블에 대한 쓰기 요금은 복제된 쓰기 용량 단위(rWCU, 프로비저닝된 테이블의 경우) 또는 복제된 쓰기 요청 단위(rWRU, 온디맨드 테이블의 경우)로 책정됩니다.
rWCU와 rWRU에는 복제를 관리하는 데 필요한 스트리밍 인프라 비용이 포함됩니다.
복제된 쓰기 단위 요금은 항목을 직접 쓰거나 복제하여 쓰는 모든 리전에서 발생합니다.
글로벌 보조 인덱스(GSI)에 쓰기는 로컬 쓰기로 간주되며, 일반 쓰기 단위를 사용합니다.
현재 rWCU에는 예약 용량을 사용할 수 없습니다. GSI가 쓰기 단위를 소비하는 테이블의 경우 예약 용량을 구매하는 것이 여전히 유용할 수 있습니다.
글로벌 테이블에 새 리전 추가 시 초기 부트스트랩에는 복원된 데이터 GB당 복원 요금에 리전 간 데이터 전송 요금이 추가로 부과됩니다.
글로벌 테이블은 어떤 리전을 지원하나요?
글로벌 테이블 버전 2019.11.21(현재)는 대부분의 리전에서 사용할 수 있습니다. 복제본을 추가할 때 DynamoDB 콘솔의 리전 드롭다운 목록에서 최신 목록을 볼 수 있습니다.
글로벌 테이블에서는 GSI를 어떻게 처리하나요?
글로벌 테이블 버전 2019.11.21(현재)에서는 한 리전에서 생성한 GSI가 다른 참여 리전에도 자동으로 생성되고 자동으로 백필됩니다.
글로벌 테이블의 복제를 중지하려면 어떻게 해야 하나요?
다른 테이블을 삭제하는 것과 같은 방식으로 복제본 테이블을 삭제할 수 있습니다. 글로벌 테이블을 삭제하면 해당 리전으로의 복제가 중지되고 해당 리전에 보관된 테이블 사본이 삭제됩니다. 하지만 테이블의 사본을 독립적 엔터티로 유지하는 동안에는 복제를 중지할 수 없으며 복제를 일시 중지할 수도 없습니다.
DynamoDB Streams는 글로벌 테이블과 어떻게 상호 작용하나요?
각 글로벌 테이블은 시작 위치에 관계없이 모든 쓰기를 기반으로 독립적인 스트림을 생성합니다. 이 DynamoDB 스트림을 한 리전 또는 모든 리전에서 독립적으로 사용하도록 선택할 수 있습니다. 로컬 쓰기 작업은 처리하되 복제된 쓰기 작업은 처리하지 않으려는 경우 쓰기 리전을 식별하는 고유한 리전 속성을 각 항목에 추가할 수 있습니다. 그런 다음 Lambda 이벤트 필터를 사용하여 로컬 리전에서의 쓰기 작업만을 위한 Lambda 함수를 호출할 수 있습니다. 이렇게 하면 삽입 및 업데이트 작업에 도움이 되지만 안타깝게도 삭제 작업에는 도움이 되지 않습니다.
글로벌 테이블은 트랜잭션을 어떻게 처리하나요?
트랜잭션 작업은 쓰기 작업이 원래 이루어진 리전에서만 ACID(원자성, 일관성, 격리 및 내구성) 보장을 제공합니다. 전역 테이블에서는 트랜잭션이 리전 간에 지원되지 않습니다. 예를 들어 미국 동부(오하이오) 및 미국 서부(오레곤) 리전에 복제본이 있는 글로벌 테이블이 있고 미국 동부(오하이오)에서 TransactWriteItems 작업을 수행할 경우, 변경 내용이 복제될 때 미국 서부(오레곤)에서 부분적으로 완료된 트랜잭션을 관찰할 수 있습니다. 변경 사항은 소스 리전에서 커밋된 이후에만 다른 리전에 복제됩니다.
글로벌 테이블은 DynamoDB Accelerator 캐시(DAX)와 어떻게 상호 작용하나요?
글로벌 테이블은 DynamoDB를 직접 업데이트하여 DAX를 우회하므로 DAX는 오래된 데이터를 보유하고 있다는 사실을 인식하지 못합니다. DAX 캐시는 캐시의 TTL이 만료되는 경우에만 새로 고쳐집니다.
테이블의 태그가 전파되나요?
아니요, 태그는 자동으로 전파되지 않습니다.
테이블을 모든 리전에 백업해야 하나요 아니면 한 리전에만 백업해야 하나요?
대답은 백업의 목적에 따라 달라집니다. 데이터 내구성을 보장하려는 경우 DynamoDB는 이미 그러한 보호 장치를 제공합니다. 이 서비스는 내구성을 보장합니다. 기록 레코드의 스냅샷을 보관하려는 경우(예: 규정 요구 사항 충족) 한 리전에 백업하는 것으로 충분합니다. AWS Backup를 사용하여 백업을 추가 리전에 복사할 수 있습니다. 실수로 삭제되거나 수정된 데이터를 복구하려면 한 리전에서 DynamoDB 시점 복구(PITR)를 사용하세요.
AWS CloudFormation을 사용하여 글로벌 테이블을 배포하려면 어떻게 해야 하나요?
CloudFormation은 DynamoDB 테이블과 글로벌 테이블을 두 개의 개별 리소스인 AWS::DynamoDB::Table과 AWS::DynamoDB::GlobalTable로 나타냅니다. 한 가지 방법은 GlobalTable 구문을 사용하여 잠재적으로 글로벌일 수 있는 모든 테이블을 생성하는 것입니다. 그러면 처음에는 이를 독립 실행형 테이블로 유지하고 필요한 경우 나중에 리전에 추가할 수 있습니다.
CloudFormation에서 각 글로벌 테이블은 복제본 수에 관계없이 단일 리전에서 단일 스택에 의해 제어됩니다. 템플릿을 배포하면 CloudFormation은 단일 스택 작업의 일부로 모든 복제본을 생성하고 업데이트합니다. 동일한 AWS::DynamoDB::GlobalTable 리소스를 여러 리전에 배포하면 안 됩니다. 이런 배포는 오류를 유발하며 지원되지 않습니다. 여러 리전에 애플리케이션 템플릿을 배포하는 경우 조건을 사용하여 단일 리전에서 AWS::DynamoDB::GlobalTable 리소스를 생성할 수 있습니다. 또는 AWS::DynamoDB::GlobalTable 리소스를 애플리케이션 스택과 별도의 스택에 정의하고 단일 리전에 배포되도록 선택할 수 있습니다.
일반 테이블이 있고 이 테이블을 CloudFormation이 계속 관리하는 글로벌 테이블로 변환하려는 경우, 삭제 정책을 유지로 설정하고, 스택에서 테이블을 제거하고, 콘솔에서 테이블을 글로벌 테이블로 변환한 다음 글로벌 테이블을 스택에 새 리소스로 가져옵니다.
교차 계정 복제는 현재 지원되지 않습니다.
