DynamoDB 글로벌 테이블 설계 모범 사례

글로벌 테이블에는 현재 버전인 글로벌 테이블 버전 2019.11.21(현재)('V2'라고도 함)과 글로벌 테이블 버전 2017.11.29(레거시)('V1'이라고도 함)의 두 가지 버전이 있습니다. 이 가이드에서는 현재 버전인 V2에만 초점을 맞춥니다.

글로벌 테이블을 사용하지 않는 DynamoDB는 리전 서비스입니다. 이 서비스는 가용성이 높으며, 전체 가용 영역(AZ) 장애를 포함한 리전의 인프라 장애에 대한 내재적 복원력이 뛰어납니다. 단일 리전 DynamoDB 테이블에는 99.99%의 가용성 https://aws.amazon.com/dynamodb/sla/서비스 수준 계약(SLA)이 적용됩니다.

글로벌 테이블을 사용하면 DynamoDB에서 테이블이 둘 이상의 리전 간에 데이터를 복제할 수 있습니다. 다중 리전 DynamoDB 테이블에는 99.999%의 가용성 SLA가 있습니다. 적절한 계획을 세우면 글로벌 테이블은 복원력이 뛰어나고 리전 장애에 강한 아키텍처를 만드는 데 도움이 될 수 있습니다.

글로벌 테이블은 액티브-액티브 복제 모델을 사용합니다. DynamoDB의 관점에서 볼 때 각 리전의 테이블은 읽기 및 쓰기 요청을 수락할 수 있는 동등한 지위를 갖습니다. 로컬 복제본 테이블은 쓰기 요청을 받은 후 백그라운드에서 다른 참여 리전에 쓰기를 복제합니다.

항목은 개별적으로 복제됩니다. 단일 트랜잭션 내에서 업데이트된 항목은 함께 복제되지 않을 수 있습니다.

소스 리전의 각 테이블 파티션은 다른 모든 파티션과 병렬로 쓰기를 복제합니다. 원격 리전 내의 쓰기 순서는 소스 리전 내에서 발생한 쓰기 순서와 일치하지 않을 수 있습니다. 테이블 파티션에 대한 자세한 내용은 블로그 게시물 Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance를 참조하세요.

글로벌 테이블에 새로 쓰여진 항목은 일반적으로 1초 안에 모든 복제본 테이블에 전파됩니다. 가까운 리전이 대체로 더 빨리 전파됩니다.

Amazon CloudWatch는 각 리전 페어의 ReplicationLatency 지표를 제공합니다. 이 지표는 도착하는 항목을 보고 도착 시간을 최초 쓰기 시간과 비교하여 평균을 내 계산됩니다. 타이밍은 소스 리전의 CloudWatch 내에 저장됩니다. 평균 및 최대 타이밍을 보면 평균 복제 지연과 최악의 경우 복제 지연을 파악하는 데 도움이 될 수 있습니다. 이 지연 시간에는 SLA가 없습니다.

동일한 항목이 서로 다른 두 리전에서 거의 같은 시간에(이 ReplicationLatency 기간 내에서) 업데이트되고 첫 번째 쓰기가 복제되기 전에 두 번째 쓰기가 발생하는 경우, 쓰기 충돌이 발생할 수 있습니다. 글로벌 테이블은 쓰기 타임스탬프를 기반으로 최종 쓰기 우선 메커니즘을 사용하여 이러한 충돌을 해결합니다. 첫 번째 쓰기는 두 번째 쓰기에 우선순위가 밀립니다. 이러한 충돌은 CloudWatch 또는 AWS CloudTrail에 기록되지 않습니다.

각 항목에는 비공개 시스템 속성으로 보관되는 마지막 쓰기 타임스탬프가 있습니다. 최종 쓰기 우선 접근 방식은 수신 항목의 타임스탬프가 기존 항목의 타임스탬프보다 커야 하는 조건부 쓰기를 사용하여 구현됩니다.

글로벌 테이블은 모든 항목을 모든 참여 리전에 복제합니다. 다른 복제 범위를 지정하려는 경우, 다른 테이블을 생성하고 각 테이블에 서로 다른 참여 리전을 지정할 수 있습니다.

복제본 리전이 오프라인 상태이거나 ReplicationLatency가 증가하더라도 로컬 리전에 대한 쓰기가 허용됩니다. 로컬 테이블은 각 항목이 성공할 때까지 원격 테이블에 항목 복제를 계속 시도합니다.

드문 경우이긴 하지만 리전이 완전히 오프라인 상태가 되었다가 나중에 온라인 상태가 되면 보류 중인 아웃바운드 및 인바운드 복제가 모두 재시도됩니다. 테이블을 다시 동기화하기 위한 특별한 작업은 필요하지 않습니다. 최종 쓰기 우선 메커니즘은 최종적인 데이터 일관성을 보장합니다.

언제든지 DynamoDB 테이블에 새 리전을 추가할 수 있습니다. DynamoDB는 초기 동기화와 진행 중인 복제를 처리합니다. 원래 리전이더라도 리전이 제거되면 해당 리전의 테이블만 삭제됩니다.

DynamoDB에는 글로벌 엔드포인트가 없습니다. 모든 요청은 리전 엔드포인트로 전송되며, 이 엔드포인트는 해당 리전에 로컬인 글로벌 테이블 인스턴스에 액세스합니다.

DynamoDB에 대한 호출이 리전을 넘나들어서는 안 됩니다. 모범 사례는 어느 한 리전의 컴퓨팅 계층이 해당 리전의 로컬 DynamoDB 엔드포인트에만 직접 액세스하는 것입니다. 문제가 DynamoDB 계층에 있든 주변 스택에 있든 관계없이 리전 내에서 문제가 감지되면 최종 사용자 트래픽을 다른 리전에서 호스팅되는 다른 컴퓨팅 계층으로 라우팅해야 합니다. 글로벌 테이블 복제 덕에 로컬에서 작업할 수 있는 동일한 데이터의 로컬 사본이 다른 리전에 이미 있게 됩니다. 경우에 따라 한 리전의 컴퓨팅 계층이 처리를 위해 다른 리전의 컴퓨팅 계층으로 요청을 전달할 수 있지만 이 계층이 원격 DynamoDB 엔드포인트에 직접 액세스해서는 안 됩니다. 이 특정 사용 사례에 대한 자세한 내용은 컴퓨팅 계층 요청 라우팅을 참조하세요.

읽기 지연 시간 단축. 데이터 사본을 최종 사용자 가까이 두어 읽기 중 네트워크 지연 시간을 줄일 수 있습니다. 캐시는 ReplicationLatency 값만큼 최신 상태로 유지됩니다.

쓰기 지연 시간 단축. 가까운 리전에 쓰기를 수행하여 네트워크 지연 시간과 쓰기에 걸리는 시간을 줄일 수 있습니다. 충돌이 발생하지 않도록 쓰기 트래픽을 신중하게 라우팅해야 합니다. 라우팅 기법은 DynamoDB 글로벌 테이블을 사용한 요청 라우팅에서 자세히 설명합니다.

복원력 및 재해 복구 향상. 리전에 성능 저하 또는 완전 중단이 발생하는 경우, 초 단위로 측정되는 Recovery Point Objective(RPO)와 Recovery Time Objective(RTO)를 사용하여 리전을 대피(해당 리전으로 전송되는 요청의 일부 또는 전부를 이동)시킬 수 있습니다. 또한 글로벌 테이블을 사용하면 DynamoDB SLA가 99.99%에서 99.999%로 증가합니다.

원활한 리전 마이그레이션. 새 리전을 추가한 다음 이전 리전을 삭제하여 데이터 계층의 가동 중단 없이 한 리전에서 다른 리전으로 배포를 마이그레이션할 수 있습니다. 예를 들어 DynamoDB 글로벌 테이블을 주문 관리 시스템에 사용하면 안정적으로 지연 시간이 짧은 대규모 처리가 가능하며 동시에 AZ 및 리전 장애에 대한 복원력을 유지할 수 있습니다.