전역 테이블: 작동 방식
중요
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 글로벌 테이블 버전 2019.11.21(현재)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 사용 중인 DynamoDB 글로벌 테이블 버전 확인 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 글로벌 테이블 업그레이드 섹션을 참조하세요.
다음 단원에서는 Amazon DynamoDB의 전역 테이블에 대한 동작과 개념에 대해 설명합니다.
버전 2017.11.29(레거시)의 전역 테이블 개념
전역 테이블이란 하나의 AWS 계정에서 소유한 한 개 이상의 복제 테이블 모음입니다.
복제 테이블(줄여서 복제본이라고도 함)은 전역 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 전역 테이블은 AWS 리전당 한 개의 복제 테이블을 가질 수 있습니다.
다음은 전역 테이블을 만드는 방법을 개념적으로 간단히 설명한 것입니다.
-
AWS 리전에서 DynamoDB Streams를 활성화하여 일반 DynamoDB 테이블을 생성합니다.
-
데이터를 복제하려는 다른 리전 모두에 대해 1단계를 반복합니다.
-
생성한 테이블을 기반으로 DynamoDB 전역 테이블을 정의합니다.
AWS Management Console은 이러한 작업을 자동화하므로 전역 테이블을 빠르고 쉽게 만들 수 있습니다. 자세한 내용은 전역 테이블 생성 단원을 참조하십시오.
생성된 DynamoDB 전역 테이블은 리전당 한 개씩 여러 개의 복제 테이블로 구성되며, DynamoDB는 이를 단일 단위로 처리합니다. 모든 복제본은 동일한 테이블 이름과 동일한 프라이머리 키 스키마를 갖습니다. 애플리케이션이 한 리전의 복제 테이블에 데이터를 쓰면 DynamoDB가 이 쓰기를 다른 AWS 리전에 있는 다른 복제 테이블에 자동으로 전파합니다.
중요
전역 테이블은 테이블 데이터를 동기화 상태로 유지하기 위해 모든 항목에 대한 다음 속성을 자동으로 만듭니다.
-
aws:rep:deleting -
aws:rep:updatetime -
aws:rep:updateregion
이 속성을 변경하거나 같은 이름의 속성을 생성해서는 안 됩니다.
복제본 테이블을 전역 테이블에 추가하여 추가 리전에서 사용할 수 있습니다. (이렇게 하려면 전역 테이블이 비어 있어야 합니다. 즉, 복제 테이블 중 어느 테이블에도 데이터가 없어야 합니다.)
전역 테이블에서 복제본 테이블을 제거할 수도 있습니다. 이렇게 하면 해당 테이블은 전역 테이블과 연결이 끊어집니다. 따라서 전역 테이블과 더 이상 상호 작용을 수행하지 않으며 전역 테이블과 데이터도 주고받지 않습니다.
주의
복제본을 제거하는 것은 원자 프로세스가 아님에 유의하세요. 일관된 동작과 알려진 상태인지 확인하려면 사전에 제거할 복제본에서 애플리케이션 쓰기 트래픽을 전환해 볼 수도 있습니다. 복제본을 제거한 후 모든 복제본 리전 엔드포인트에 복제본이 연결 해제된 것으로 표시될 때까지 기다렸다가 자체 격리된 리전 테이블에 추가 쓰기를 수행합니다.
일반적인 작업
글로벌 테이블에 대한 일반적인 작업은 다음과 같이 작동합니다.
일반 테이블과 마찬가지로 글로벌 테이블의 복제본 테이블을 삭제할 수 있습니다. 그러면 해당 리전으로의 복제가 중지되고 해당 리전에 보관된 테이블 복사본이 삭제됩니다. 복제를 분리할 수 없으며 테이블의 복사본이 독립 엔터티로 존재하도록 할 수 없습니다.
참고
새 리전을 시작하는 데 사용한 후 최소 24시간이 지나야 소스 테이블을 삭제할 수 있습니다. 너무 빨리 삭제하려고 하면 오류가 발생할 수 있습니다.
충돌은 애플리케이션이 서로 다른 리전에서 동시에 동일한 항목을 업데이트할 경우 발생합니다. 최종 일관성을 보장하기 위해 DynamoDB 글로벌 테이블은 '최종 쓰기 우선' 방법을 사용하여 동시 업데이트 간에 조정합니다. 모든 복제본은 최종 업데이트에 합의하며 모두 동일한 데이터를 갖는 상태가 됩니다.
참고
충돌을 방지하는 몇 가지 방법은 다음과 같습니다.
IAM 정책을 사용하여 한 리전의 테이블에 대한 쓰기만 허용합니다.
IAM 정책을 사용하여 사용자를 한 리전으로만 라우팅하고 다른 리전은 유휴 대기 상태로 유지하거나, 홀수 사용자를 한 리전으로, 짝수 사용자를 다른 리전으로 번갈아 라우팅합니다.
Bookmark = Bookmark + 1과 같은 멱등성이 없는 업데이트의 사용을 피하고 가급적 Bookmark=25와 같은 정적 업데이트를 사용합니다.
전역 테이블 모니터링
CloudWatch를 사용하여 ReplicationLatency 지표를 관찰할 수 있습니다. 이 지표는 한 복제 테이블에 대한 DynamoDB Streams에 나타나는 업데이트된 항목과 글로벌 테이블의 다른 복제본에 나타나는 항목 간의 경과 시간을 추적합니다. ReplicationLatency는 밀리초 단위로 표현되며, 모든 소스-리전 및 대상-리전 쌍에 대해 내보내집니다. 이 지표는 글로벌 테이블 v2에서 제공하는 유일한 CloudWatch 지표입니다.
발생하게 되는 지연 시간은 선택한 리전 간의 거리와 기타 변수에 따라 달라집니다. 리전에 대한 0.5초~2.5초 범위의 지연 시간은 동일한 지리적 영역 내에서 일반적일 수 있습니다.
TTL(Time To Live)
TTL(Time To Live)을 사용하여 해당 값이 항목의 만료 시간을 나타내는 속성 이름을 지정할 수 있습니다. 이 값은 Unix epoch가 시작된 이후 초 단위의 숫자로 지정됩니다.
글로벌 테이블 레거시 버전에서는 TTL 삭제가 다른 복제본에 자동으로 복제되지 않습니다. TTL 규칙을 통해 항목을 삭제하면 쓰기 단위를 사용하지 않고 해당 작업이 수행됩니다.
소스 및 대상 테이블의 프로비저닝된 쓰기 용량이 매우 낮은 경우 TTL 삭제에 쓰기 용량이 필요하므로 제한이 발생할 수 있습니다.
글로벌 테이블을 사용한 스트림 및 트랜잭션
각 글로벌 테이블은 해당 쓰기의 시작 지점에 관계없이 모든 쓰기를 기반으로 독립적인 스트림을 생성합니다. 이 DynamoDB 스트림을 한 리전 또는 모든 리전에서 독립적으로 사용하도록 선택할 수 있습니다.
로컬 쓰기는 처리하되 복제된 쓰기는 처리하지 않으려는 경우 각 항목에 고유한 리전 속성을 추가할 수 있습니다. 그런 다음 Lambda 이벤트 필터를 사용하여 로컬 리전의 쓰기용으로만 Lambda를 호출할 수 있습니다.
트랜잭션 작업은 원래 쓰기 작업이 실행된 리전에서만 ACID(원자성, 일관성, 격리 및 내구성) 보장을 제공합니다. 글로벌 테이블에서는 트랜잭션이 리전 간에 지원되지 않습니다.
예를 들어 미국 동부(오하이오) 및 미국 서부(오레곤) 리전에 복제본이 있는 글로벌 테이블에 대해 미국 동부(오하이오)에서 TransactWriteItems 작업을 수행할 경우 변경 내용이 복제될 때 미국 서부(오레곤)에서 부분적으로 완료된 트랜잭션을 관찰할 수 있습니다. 변경 내용은 소스 리전에서 커밋된 이후에만 다른 리전에 복제됩니다.
참고
글로벌 테이블은 DynamoDB를 직접 업데이트하여 DynamoDB Accelerator에 '쓰기'합니다. 따라서 DAX는 기한이 지난 데이터를 보유하고 있다는 사실을 인식하지 못합니다. DAX 캐시는 캐시의 TTL이 만료되는 경우에만 새로 고쳐집니다.
글로벌 테이블의 태그는 자동으로 전파되지 않습니다.
읽기 및 쓰기 처리량
글로벌 테이블은 다음과 같은 방식으로 읽기 및 쓰기 처리량을 관리합니다.
쓰기 용량은 리전의 모든 테이블 인스턴스에서 동일해야 합니다.
버전 2019.11.21(현재)에서는 테이블이 Auto Scaling을 지원하도록 설정되거나 온디맨드 모드인 경우 쓰기 용량이 자동으로 동기화된 상태로 유지됩니다. 각 리전에서 프로비저닝된 현재 쓰기 용량은 동기화된 Auto Scaling 설정 내에서 독립적으로 증가 및 감소합니다. 테이블이 온디맨드 모드로 전환되면 해당 모드가 다른 복제본과 동기화됩니다.
읽기가 동일하지 않을 수 있으므로 읽기 용량은 리전마다 다를 수 있습니다. 테이블에 글로벌 복제본을 추가하면 소스 리전의 용량이 전파됩니다. 생성 후 하나의 복제본에 대한 읽기 용량을 조정할 수 있으며 이 새로운 설정은 다른 쪽으로 전송되지 않습니다.
정합성 및 충돌 해결
복제본 테이블의 항목이 변경되면 동일한 전역 테이블에 있는 다른 모든 복제본에 복제됩니다. 전역 테이블에 새로 쓰여진 항목은 일반적으로 몇 초만에 모든 복제본 테이블에 전파됩니다.
전역 테이블에서 각 복제 테이블에는 동일한 데이터 항목 집합이 저장됩니다. DynamoDB는 일부 항목만의 부분 복제를 지원하지 않습니다.
애플리케이션은 다른 복제본 테이블에 대해 데이터를 읽고 쓸 수 있습니다. DynamoDB는 리전 전체에서 최종 읽기 일관성을 지원하지만 리전 전체에서 강력히 일관된 읽기는 지원하지 않습니다. 애플리케이션이 최종적으로 일관된 읽기만 사용하고 하나의 AWS 리전에 대해 읽기만 발행할 경우 수정 없이 수행됩니다. 하지만 애플리케이션이 강력히 일관된 읽기를 요구하면 동일 리전에서 강력히 일관된 읽기와 쓰기를 모두 수행해야 합니다. 그렇지 않고 한 리전에 쓰기를 하고 다른 리전에서 읽기를 할 경우, 다른 리전에서 최근에 수행된 결과가 반영되지 않은 기한 경과 데이터가 읽기 응답에 포함될 수 있습니다.
충돌은 애플리케이션이 서로 다른 리전에서 동시에 동일한 항목을 업데이트할 경우 발생합니다. 최종 일관성을 보장하기 위해 DynamoDB 전역 테이블은 동시 업데이트에 대해 최종 쓰기 우선 적용 조정을 사용하며, DynamoDB는 최선을 다해 최종 쓰기를 결정합니다. 이러한 충돌 해결 방법을 사용하여 모든 복제본은 최종 업데이트에 합의하며 모두 동일한 데이터를 갖는 상태가 됩니다.
가용성과 내구성
한 AWS 리전이 분리되거나 저하되면, 애플리케이션이 다른 리전으로 리디렉션하여 다른 복제 테이블에서 읽기 및 쓰기를 수행할 수 있습니다. 요청을 언제 다른 리전으로 재지정할지를 결정하는 사용자 지정 비즈니스 로직을 적용할 수 있습니다.
리전이 분리되거나 저하되면 DynamoDB는 수행된 쓰기 기록을 유지하지만 모든 복제 테이블로 전파하지는 않습니다. 리전이 다시 온라인 상태로 되면 DynamoDB는 해당 리전에서 보류 중인 쓰기 전파를 재개하여 다른 리전의 복제 테이블로 전파합니다. 다시 온라인 상태로 된 리전에 대한 다른 복제본 테이블의 쓰기 전파도 재개됩니다. 이전에 성공한 모든 쓰기 작업은 리전이 격리된 기간에 관계없이 결국 전파됩니다.
