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