DynamoDB Global Tables

글로벌 테이블은 여러 AWS 리전에 복제된 하나의 DynamoDB 테이블로, 모든 레플리카에 쓰기가 가능합니다. DynamoDB가 자동으로 동기화를 유지해주므로 — 직접 복제를 운영하지 않고도 각 리전에서 지연이 낮은 로컬 읽기/쓰기와 리전 간 재해 복구를 함께 얻습니다.

감사 로그 시나리오에서, EU 고객은 자신의 데이터가 eu-west-1에 존재해야 한다고 요구하고, 나머지는 us-east-1에서 동작합니다. 그리고 규정 준수가 핵심인 로그로서 리전 전체 장애에서도 살아남아야 합니다. 글로벌 테이블은 이 두 가지를 하나의 기능으로 해결합니다.

DynamoDB 글로벌 테이블이란?

DynamoDB 글로벌 테이블은 여러 AWS 리전에 복제된 하나의 테이블로, 모든 레플리카에서 읽기와 쓰기가 가능합니다. DynamoDB는 최종적 일관성을 갖는 비동기 복제로 이를 자동으로 동기화하며, 충돌은 최종-쓰기-우선(last-writer-wins)으로 해결합니다. 각 리전에서 지연이 낮은 로컬 읽기/쓰기와 함께 리전 간 재해 복구를 얻으며, 이는 DynamoDB의 99.999% 가용성 SLA를 뒷받침합니다.

• 멀티 리전, 액티브-액티브. 각 레플리카는 완전히 읽고 쓸 수 있으며, 어느 리전에서든 쓰기가 다른 리전으로 전파됩니다.
• 복제는 비동기적이며 리전 간 최종적 일관성을 가집니다 — 보통 1초 이내지만 즉각적이지는 않습니다.
• 충돌은 last-writer-wins로 해결됩니다. 두 리전에서 같은 항목에 대한 동시 쓰기는 가장 최근의 쓰기로 조정됩니다.
• 99.999% 가용성 SLA를 뒷받침합니다 — 멀티 리전 글로벌 테이블은 DynamoDB의 최고 가용성 구성입니다.

문제: 하나의 리전으로는 충분하지 않다

단일 리전 테이블에는 감사 로그가 받아들일 수 없는 두 가지 한계가 있습니다. 첫째, 데이터 거주지: EU 고객의 이벤트는 EU에 저장되어야 하지만, 앱은 US에서 동작합니다. 둘째, 재해 복구: us-east-1에 장애가 발생하면 단일 리전 감사 로그는 그동안 읽을 수도 쓸 수도 없게 됩니다 — 무슨 일이 일어났는지에 대한 기록이 가장 필요한 바로 그 순간에 말입니다.

리전 간 복제, 장애 조치, 충돌 처리 등 이 둘 중 어느 것이든 직접 구축하는 것은 크고 실수하기 쉬운 프로젝트입니다. 글로벌 테이블은 이를 구성 선택의 문제로 바꿔줍니다.

글로벌 테이블의 작동 방식

테이블에 레플리카 리전을 추가하면, DynamoDB가 그곳에 사본을 만들고 모든 레플리카를 동기화 상태로 유지합니다. AWS DynamoDB FAQ에 따르면, 글로벌 테이블은 최대 99.999% 가용성으로 멀티 리전 복제를 제공하며, 각 리전의 레플리카가 로컬 읽기와 쓰기를 처리합니다.

두 가지 일관성 규칙이 동작을 규정합니다:

• 리전 간 복제는 비동기적입니다. us-east-1의 쓰기는 로컬에서 확인된 뒤 eu-west-1로 전파되며 — 보통 1초 이내지만, 쓰기 직후 다른 리전에서의 읽기는 아직 그것을 못 볼 수 있습니다. (강력한 일관성 읽기는 여전히 동작하지만, 단일 리전 내에서만 가능합니다.)
• 충돌은 last-writer-wins입니다. 같은 항목이 거의 동시에 두 리전에서 쓰여지면, DynamoDB는 가장 최근 타임스탬프의 쓰기를 유지하고 다른 것은 버립니다.

실전 예시: 재해 복구이기도 한 EU 레플리카

audit-log 테이블의 레플리카로 eu-west-1을 추가합니다. 이제:

EU 고객의 앱은 로컬 eu-west-1 레플리카에 쓰고 그것에서 읽습니다 — 낮은 지연과 리전 내 데이터 거주지를 동시에 얻습니다. 거주지를 충족시키는 바로 그 복제가 재해 복구의 역할도 겸합니다: us-east-1이 다운되면, eu-west-1 레플리카가 여전히 전체 로그를 보유하고 트래픽을 처리하므로, 그쪽으로 장애 조치하면 됩니다.

감사 로그는 추가 전용(append-only)이며 테넌트별로 파티셔닝되어 있으므로, 여기서 last-writer-wins는 사실상 문제가 되지 않습니다 — 특정 테넌트의 이벤트는 한 리전에서 쓰여지고 이벤트 키는 고유하므로, 두 리전이 같은 항목을 두고 경쟁하는 일은 드뭅니다. 이것은 운이 좋은 게 아니라, 추가 전용 로그가 글로벌 테이블에 가장 깔끔하게 맞는 사례 중 하나인 이유입니다. 반대로 가변 카운터라면 동시 리전 간 쓰기 하에서 주의가 필요합니다.

DynoTable에서 해보기

레플리카를 추가한 뒤에는 데이터가 실제로 새 리전에 도착했고 원본과 일치하는지 — EU 레플리카가 정말로 acme의 이벤트를 올바른 속성과 함께 보유하고 있으며 뒤처지지 않았는지 — 확인하고 싶을 것입니다.

DynoTable은 각자의 자격 증명으로 어느 리전에든 연결되므로, 한 창은 us-east-1을, 다른 창은 eu-west-1을 가리키고 같은 테넌트의 항목을 나란히 비교하여 복제를 검증할 수 있습니다.

각 레플리카에 대해 실행할 리전별 쿼리를 DynamoDB Expression Builder에서 미리 프로토타이핑할 수 있습니다.

함정과 다음 단계

• 리전 간에 자신의 쓰기를 곧바로 읽지 마세요. 복제 지연 때문에 한 리전의 쓰기가 다른 리전에 약 1초 동안 나타나지 않을 수 있습니다. US에 쓰고 곧바로 EU에서 읽으며 그것을 기대하지 마세요. 강력한 일관성은 단일 리전에서만 가능합니다.
• last-writer-wins는 조용히 데이터를 버립니다. 두 리전에서 동시에 쓰여지는 가변 항목의 경우, 진 쪽은 오류 없이 폐기됩니다. (이 감사 로그처럼) 추가 전용 또는 항목별 단일 작성자 설계는 이 문제를 피합니다. 공유된 가변 상태는 충돌을 인지하는 설계가 필요합니다.
• 모든 레플리카는 비용이 듭니다. 각 리전은 전체 사본을 저장하고 자체 용량과 스토리지를 청구합니다 — 레플리카 하나가 대략 비용을 두 배로 만듭니다. 실제 거주지나 재해 복구 필요가 있을 때 리전을 추가하세요. 기본값으로 추가하지 마세요.
• 백업은 레플리카별입니다. 복원된 글로벌 테이블은 독립적인 테이블이 됩니다 — 리전별로 복구를 계획하세요. 백업 및 특정 시점 복구를 참고하세요.

글로벌 테이블은 리전을 잃는 것을 막아줍니다. 마지막 운영 관심사는 데이터를 — 잘못된 배포나 실수로 인한 삭제를 — 잃는 것을 막는 것이며, 백업 및 특정 시점 복구가 그 역할을 합니다.

여러 리전에 연결하여 글로벌 테이블 레플리카가 같은 데이터를 보유하는지 검증하려면 DynoTable을 다운로드하세요.