DynamoDB Global Tables: 다중 리전 복제 설명
글로벌 테이블은 여러 AWS 리전에 걸쳐 복제된 하나의 DynamoDB 테이블로, 모든 복제본이 쓰기 가능합니다. DynamoDB가 자동으로 동기화를 유지합니다 — 자체 복제를 운영하지 않고도 각 리전에서 저지연 로컬 읽기·쓰기에 더해 리전 간 재해 복구를 얻습니다.
감사 로그 시나리오에서, EU 고객은 자기 데이터가 eu-west-1에 있어야 하는 반면, 나머지는
us-east-1에서 돌아갑니다. 그리고 규정 준수가 핵심인 로그로서, 리전 전면 장애에서도 살아남아야
합니다. 글로벌 테이블은 하나의 기능으로 둘 다에 답합니다.
DynamoDB 글로벌 테이블은 어떻게 동작하나요?
DynamoDB 글로벌 테이블은 여러 AWS 리전에 걸쳐 복제된 하나의 테이블로, 모든 복제본이 읽기·쓰기 가능합니다. DynamoDB가 비동기 복제로 자동 동기화하며, 충돌은 최종 작성자 우선으로 해결합니다. 리전별 저지연 로컬 읽기·쓰기에 더해 리전 간 재해 복구를 얻으며, DynamoDB의 99.999% 가용성 SLA를 뒷받침합니다.
- 멀티 리전, 액티브-액티브. 각 복제본은 완전히 읽기·쓰기 가능하며, 어느 리전의 쓰기든 다른 리전으로 전파됩니다.
- 기본 모드에서 복제는 비동기이며 리전 간 입니다 — 보통 1초 이내지만 즉각적이지는 않습니다. (강력한 일관성 모드도 존재합니다 — 아래 참조.)
- 충돌은 최종 작성자 우선으로 해결됩니다. 같은 아이템에 대한 두 리전의 동시 쓰기는 가장 최근 것으로 조정됩니다.
- 99.999% 가용성 SLA를 뒷받침합니다 — 멀티 리전 글로벌 테이블은 DynamoDB의 최고 가용성 구성입니다.
문제: 한 리전으로는 충분하지 않다
단일 리전 테이블에는 감사 로그가 받아들일 수 없는 두 가지 한계가 있습니다. 첫째, 데이터
레지던시: EU 고객의 이벤트는 EU에 저장되어야 하지만 여러분의 앱은 US에서 돌아갑니다. 둘째,
재해 복구: us-east-1에 장애가 나면 단일 리전 감사 로그는 그동안 읽지도 쓰지도 못합니다 —
무슨 일이 있었는지에 대한 기록이 가장 필요한 바로 그때 말입니다.
둘 중 하나라도 직접 구축하는 것 — 리전 간 복제, 페일오버, 충돌 처리 — 은 크고 오류가 나기 쉬운 프로젝트입니다. 글로벌 테이블은 그것을 구성 선택으로 만듭니다.
복제 메커니즘
테이블에 복제본 리전을 추가하면, DynamoDB가 거기에 복사본을 만들고 모든 복제본을 동기화 상태로 유지합니다.
두 가지 일관성 규칙이 기본(MREC) 동작을 정의합니다:
- 리전 간 복제는 비동기입니다.
us-east-1의 쓰기는 로컬에서 확인된 뒤eu-west-1로 전파됩니다 — 보통 1초 이내지만, 쓰기 직후 다른 리전의 읽기는 아직 그것을 못 볼 수 있습니다. (기본 MREC 모드에서도 강력한 는 작동하지만, 단일 리전 _안에서만_입니다.) - 충돌은 최종 작성자 우선입니다. 같은 아이템이 거의 동시에 두 리전에서 쓰이면, DynamoDB는 가장 최신 타임스탬프를 가진 쓰기를 유지하고 다른 것을 버립니다.
실전 예제: DR도 겸하는 EU 복제본
감사 로그 테이블의 복제본으로 eu-west-1을 추가합니다. 이제:
| write region | item | visible in | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | both regions (~1s lag to EU) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | both regions (~1s lag to US) |
EU 고객의 앱은 로컬 eu-west-1 복제본에 쓰고 그것으로부터 읽습니다 — 저지연이면서 데이터가
리전 내에 상주합니다. 레지던시를 만족시키는 그 복제가 재해 복구도 겸합니다: us-east-1이
다운되면 eu-west-1 복제본이 여전히 전체 로그를 보유하고 트래픽을 서비스합니다. 거기로 페일오버
합니다.
감사 로그는 추가 전용이며 테넌트별로 파티셔닝되어 있으므로, 최종 작성자 우선은 여기서 사실상 비쟁점입니다 — 특정 테넌트의 이벤트는 한 리전에서 쓰이고 이벤트 키가 고유하므로, 두 리전이 같은 아이템에서 경쟁하는 일이 드뭅니다. 이건 운이 아닙니다. 추가 전용 로그가 글로벌 테이블에 가장 깔끔히 맞는 것 중 하나인 이유입니다. 반면 변경 가능한 카운터는 리전 간 동시 쓰기에서 주의가 필요합니다.
DynoTable에서 해보기
복제본을 추가한 뒤에는 데이터가 실제로 새 리전에 도착했고 원천과 일치하는지 — EU 복제본이 정말로
acme의 이벤트를 올바른 속성으로 보유하며 뒤처지지 않았는지 — 확인하고 싶어집니다.
DynoTable은 자체 자격 증명으로 어느 리전에든 연결하므로, 한 창은 us-east-1에, 다른 창은
eu-west-1에 가리키고 같은 테넌트의 아이템을 나란히 비교해 복제를 검증할 수 있습니다.
각 복제본에 실행할 리전별 쿼리를 DynamoDB 표현식 빌더에서 프로토타이핑할 수 있습니다.
함정과 다음 단계
- 리전을 넘어 자기 쓰기를 읽지 마세요. 복제 지연은 한 리전의 쓰기가 다른 리전에 약 1초간 나타나지 않을 수 있음을 뜻합니다. US에 쓰고 곧바로 EU에서 읽으며 그것을 기대하지 마세요. 기본 MREC 모드에서 강력한 일관성 읽기는 단일 리전 안에서만 작동합니다. MRSC는 강력한 읽기를 리전에 걸쳐 확장합니다.
- 최종 작성자 우선은 조용히 데이터를 버립니다. 두 리전에서 동시에 쓰인 변경 가능한 아이템은, 진 쪽이 오류 없이 폐기됩니다. 추가 전용 또는 아이템당 단일 작성자 설계(이 감사 로그처럼)는 그 문제를 피합니다. 공유되는 변경 가능 상태에는 충돌을 인식하는 설계가 필요합니다.
- 모든 복제본은 비용이 듭니다. 각 리전은 전체 복사본을 저장하고 자체 용량과 저장 비용을 청구합니다 — 복제본 하나가 비용을 대략 두 배로 만듭니다. 기본값으로가 아니라 진짜 레지던시나 DR 필요가 있을 때 리전을 추가하세요.
- 백업은 복제본별입니다. 복원된 글로벌 테이블은 독립적인 테이블이 됩니다 — 리전별로 복구를 계획하세요. 백업 & 특정 시점 복구를 보세요.
글로벌 테이블은 리전을 잃는 것을 막습니다. 마지막 운영 관심사는 데이터 를 잃는 것 — 잘못된 배포나 실수로 인한 삭제 — 을 막는 것이며, 백업 & 특정 시점 복구로 합니다.
DynoTable을 내려받아 여러 리전에 연결하고, 글로벌 테이블 복제본들이 같은 데이터를 보유하는지 검증하세요.