# DynamoDB 글로벌 테이블 사용 글로벌 테이블은 Amazon DynamoDB의 국제적인 입지를 기반으로 구축되어 완전관리형 다중 리전 다중 활성 데이터베이스를 제공하며, 이 데이터베이스는 대규모로 확장되는 글로벌 애플리케이션의 신속한 로컬 읽기 및 쓰기 성능을 제공할 수 있습니다. 글로벌 테이블은 선택된 AWS 리전 간에 DynamoDB 테이블을 자동으로 복제합니다. 글로벌 테이블은 기존 DynamoDB API를 사용하므로 애플리케이션을 변경할 필요가 없습니다. 글로벌 테이블 사용에 따른 선결제 비용이나 약정은 없으며 사용한 리소스에 대해서만 비용을 지불합니다. 이 가이드에서는 DynamoDB 글로벌 테이블의 효과적인 사용 방법에 대해 설명합니다. 글로벌 테이블에 대한 주요 정보를 제공하고, 기능의 기본 사용 사례를 설명하며, 두 가지 일관성 모드를 설명하고, 고려해야 할 세 가지 쓰기 모델을 분류하여 소개하며, 구현할 수 있는 네 가지 주요 요청 라우팅 옵션을 살펴보고, 라이브 리전 또는 오프라인 리전에서 대피하는 방법을 설명하며, 처리량 용량 계획에 대해 생각하는 방법을 설명하고, 글로벌 테이블을 배포할 때 고려해야 할 사항에 대한 체크리스트를 제공합니다. 이 가이드에서는 [AWS 다중 리전 기초](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) 백서 및 [AWS를 사용한 데이터 복원력 설계 패턴](https://www.youtube.com/watch?v=7IA48SOX20c) 비디오에서 설명하듯이 AWS 다중 리전 배포의 더 광범위한 컨텍스트를 다룹니다. **Topics** + [DynamoDB 글로벌 테이블 설계에 대한 주요 사실](#bp-global-table-design.prescriptive-guidance.facts) + [MREC에 대한 주요 사실](#bp-global-table-design-MREC-facts) + [MRSC에 대한 주요 사실](#bp-global-table-design-MRSC-facts) + [MREC DynamoDB 글로벌 테이블 사용 사례](#bp-global-table-design.prescriptive-guidance.usecases) + [DynamoDB 글로벌 테이블을 사용한 쓰기 모드](bp-global-table-design.prescriptive-guidance.writemodes.md) + [DynamoDB의 라우팅 전략](bp-global-table-design.prescriptive-guidance.request-routing.md) + [대피 프로세스](bp-global-table-design.prescriptive-guidance.evacuation.md) + [DynamoDB 글로벌 테이블의 처리량 용량 계획](bp-global-table-design.prescriptive-guidance.throughput.md) + [DynamoDB 글로벌 테이블 준비 체크리스트](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md) + [결론 및 리소스](#bp-global-table-design.prescriptive-guidance-resources-conclusion) ## DynamoDB 글로벌 테이블 설계에 대한 주요 사실 + 글로벌 테이블에는 현재 버전인 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)('V2'라고도 함)과 [글로벌 테이블 버전 2017.11.29(레거시)](globaltables.V1.md)('V1'이라고도 함)의 두 가지 버전이 있습니다. 이 가이드에서는 현재 버전에만 중점을 둡니다. + DynamoDB(글로벌 테이블 제외)는 리전에 기반한 서비스입니다. 즉, 가용성이 높고, 전체 가용 영역(AZ) 장애를 포함해 리전의 인프라 장애에 대한 내재적 복원력을 지원합니다. 단일 리전 DynamoDB 테이블은 99.99% 가용성을 지원하도록 설계되었습니다. 자세한 내용은 [DynamoDB 서비스 수준 계약](https://aws.amazon.com/dynamodb/sla/)(SLA)을 참조하세요. + DynamoDB 글로벌 테이블은 두 개 이상의 리전 사이에서 데이터를 복제합니다. 다중 리전 DynamoDB 테이블은 99.999% 가용성을 제공하도록 설계되었습니다. 적절한 계획을 세우면 글로벌 테이블은 리전 장애에 대한 복원력을 지닌 아키텍처를 만드는 데 도움이 될 수 있습니다. + DynamoDB에는 글로벌 엔드포인트가 없습니다. 모든 요청은 리전 엔드포인트에 대해 생성되며, 이 엔드포인트는 해당 리전에 로컬인 글로벌 테이블 인스턴스에 액세스합니다. + DynamoDB에 대한 직접 호출은 여러 리전 사이를 이동할 수 없습니다. 한 리전을 홈 리전으로 지정한 애플리케이션이 해당 리전의 로컬 DynamoDB 엔드포인트에만 직접 액세스하는 것이 모범 사례입니다. 한 리전의 DynamoDB 계층에 있든 주변 스택에서 문제가 감지되면 최종 사용자 트래픽을 다른 리전에서 호스팅된 다른 애플리케이션 엔드포인트로 라우팅해야 합니다. 글로벌 테이블은 모든 리전이 홈 리전에 해당하는 애플리케이션이 동일한 데이터에 액세스할 수 있도록 지원합니다. ### 일관성 모델 글로벌 테이블을 생성할 때 일관성 모드를 구성할 수 있습니다. 글로벌 테이블은 다중 리전 최종 일관성(MREC)과 다중 리전 강력한 일관성(MRSC)(2025년 6월에 도입됨)이라는 두 가지 일관성 모드를 지원합니다. 글로벌 테이블을 생성할 때 일관성 모드를 지정하지 않으면 글로벌 테이블은 기본적으로 MREC로 설정됩니다. 글로벌 테이블에는 서로 다른 일관성 모드로 구성된 복제본이 포함될 수 없습니다. 글로벌 테이블을 생성한 후에는 일관성 모드를 변경할 수 없습니다. ## MREC에 대한 주요 사실 + MRSC를 사용하는 글로벌 테이블은 액티브-액티브 복제 모델도 사용합니다. DynamoDB의 관점에서 볼 때 각 리전의 테이블은 읽기 및 쓰기 요청을 수락할 수 있는 동등한 지위를 갖습니다. 로컬 복제본 테이블은 쓰기 요청을 받은 후 백그라운드에서 다른 원격 참여 리전에 쓰기 작업을 복제합니다. + 항목은 개별적으로 복제됩니다. 단일 트랜잭션 내에서 업데이트된 항목은 함께 복제되지 않을 수 있습니다. + 소스 리전의 각 테이블 파티션은 다른 모든 파티션과 병렬로 쓰기 작업을 복제합니다. 원격 리전 내 쓰기 작업 시퀀스는 소스 리전 내에서 나타나는 쓰기 작업 시퀀스와 일치하지 않을 수 있습니다. 테이블 파티션에 대한 자세한 내용은 블로그 게시물 [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)를 참조하세요. + 글로벌 테이블에 새로 쓰여진 항목은 일반적으로 1초 안에 모든 복제본 테이블에 전파됩니다. 가까운 리전이 대체로 더 빨리 전파됩니다. + Amazon CloudWatch는 각 리전 페어의 `ReplicationLatency` 지표를 제공합니다. 도착하는 항목을 보고 도착 시간을 최초 쓰기 시간과 비교해 평균을 내 계산됩니다. 타이밍은 소스 리전의 CloudWatch 내에 저장됩니다. 평균 및 최대 타이밍을 보는 것은 평균 및 최악의 복제 지연을 결정하는 데 유용할 수 있습니다. 이 지연 시간에는 SLA가 없습니다. + 개별 항목이 서로 다른 두 리전에서 거의 같은 시간에(이 `ReplicationLatency` 기간 내) 업데이트되고 첫 번째 쓰기 작업이 복제되기 전에 두 번째 쓰기 작업이 발생하는 경우 쓰기 충돌이 발생할 수 있습니다. MREC를 사용하는 글로벌 테이블은 쓰기 작업의 타임스탬프를 기반으로 최종 쓰기 우선 메커니즘을 사용하여 이러한 충돌을 해결합니다. 첫 번째 작업은 두 번째 작업에서 '손실'됩니다. 이러한 충돌은 CloudWatch 또는 AWS CloudTrail에 기록되지 않습니다. + 각 항목에는 비공개 시스템 속성으로 보관되는 마지막 쓰기 타임스탬프가 있습니다. 최종 쓰기 우선 접근 방식은 수신 항목의 타임스탬프가 기존 항목의 타임스탬프보다 커야 하는 조건부 쓰기 작업을 사용하여 구현됩니다. + 글로벌 테이블은 모든 항목을 모든 참여 리전에 복제합니다. 다른 복제 범위를 지정하려는 경우 여러 글로벌 테이블을 생성하고 각 테이블에 서로 다른 참여 리전을 할당할 수 있습니다. + 복제본 리전이 오프라인 상태이거나 `ReplicationLatency`가 증가하더라도 로컬 리전은 쓰기 작업을 수락합니다. 로컬 테이블은 각 항목이 성공할 때까지 원격 테이블에 항목 복제를 계속 시도합니다. + 드문 경우이긴 하지만 리전이 완전히 오프라인 상태가 되었다가 나중에 다시 온라인 상태가 되면 보류 중인 아웃바운드 및 인바운드 복제가 모두 재시도됩니다. 테이블을 다시 동기화하기 위한 특별한 작업은 필요하지 않습니다. *최종 쓰기 우선* 메커니즘은 데이터의 최종 일관성을 보장합니다. + 언제든지 DynamoDB MREC 테이블에 새 리전을 추가할 수 있습니다. DynamoDB는 초기 동기화 및 진행 중인 복제를 처리합니다. 리전(원본 리전 포함)을 제거할 수도 있으며, 이 경우 해당 리전의 로컬 테이블이 삭제됩니다. ## MRSC에 대한 주요 사실 + MRSC를 사용하는 글로벌 테이블은 액티브-액티브 복제 모델도 사용합니다. DynamoDB의 관점에서 볼 때 각 리전의 테이블은 읽기 및 쓰기 요청을 수락할 수 있는 동등한 지위를 갖습니다. MRSC 글로벌 테이블 복제본의 항목 변경 사항은 쓰기 작업이 성공적인 응답을 반환하기 전에 하나 이상의 다른 리전에 **동기식으로** 복제됩니다. + 모든 MRSC 복제본에서 강력하게 일관된 읽기 작업은 항상 항목의 최신 버전을 반환합니다. 조건부 쓰기 작업은 항상 항목의 최신 버전을 기준으로 조건 표현식을 평가합니다. 업데이트는 항상 항목의 최신 버전에서 작동합니다. + MRSC 복제본에서 최종적으로 일관된 읽기 작업에는 최근에 다른 리전에서 수행된 변경이 포함되지 않을 수 있으며, 동일한 리전에서 최근에 수행된 변경도 포함되지 않을 수 있습니다. + 다른 리전에서 이미 수정 중인 항목을 수정하려고 하면 `ReplicatedWriteConflictException` 예외와 함께 쓰기 작업이 실패합니다. `ReplicatedWriteConflictException` 예외와 함께 실패한 쓰기 작업은 재시도할 수 있으며 항목이 다른 리전에서 더 이상 수정되고 있지 않는 경우 작업에 성공합니다. + MRSC를 사용하면 쓰기 작업과 강력하게 일관된 읽기 작업의 지연 시간이 길어집니다. 이러한 작업에는 교차 리전 통신이 필요합니다. 이 통신은 액세스 중인 리전과 글로벌 테이블에 참여하는 가장 가까운 리전 간의 왕복 지연 시간에 따라 증가하는 지연 시간을 추가할 수 있습니다. 자세한 내용은 AWS re:Invent 2024 프레젠테이션, [Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA)를 참조하세요. 최종적으로 일관된 읽기 작업에서는 추가 지연 시간이 발생하지 않습니다. 리전에서 이러한 지연 시간을 실험적으로 계산할 수 있는 오픈 소스 [테스터 도구](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester)가 있습니다. + 항목은 개별적으로 복제됩니다. MRSC를 사용하는 글로벌 테이블은 트랜잭션 API를 지원하지 않습니다. + MRSC 글로벌 테이블은 정확히 3개의 리전에 배포되어야 합니다. 복제본 세 개 또는 복제본 두 개와 감시자 하나로 MRSC 글로벌 테이블을 구성할 수 있습니다. 감시자는 글로벌 테이블 복제본에 쓴 최근 데이터를 포함하는 MRSC 글로벌 테이블의 구성 요소입니다. 감시자는 MRSC의 가용성 아키텍처를 지원하면서 전체 복제본에 대한 선택적 대안을 제공합니다. 감시자에 대한 읽기 또는 쓰기 작업은 수행할 수 없습니다. 감시자는 스토리지 또는 쓰기 비용을 발생시키지 않습니다. 감시자는 두 복제본과 다른 리전에 있습니다. + MRSC 글로벌 테이블을 생성하려면 데이터가 없는 기존 DynamoDB 테이블에 복제본 1개와 감시자 또는 복제본 2개를 추가합니다. 기존 MRSC 글로벌 테이블에는 복제본을 추가할 수 없습니다. MRSC 글로벌 테이블에서 단일 복제본 또는 감시자를 삭제할 수 없습니다. MRSC 글로벌 테이블에서 복제본 2개를 삭제하거나 복제본 1개와 감시자를 삭제할 수 있습니다. 두 번째 시나리오에서는 나머지 복제본을 단일 리전 DynamoDB 테이블로 변환합니다. + DescribeTable API의 출력에서 MRSC 글로벌 테이블에 감시자가 구성되었는지와 감시자가 구성된 리전을 확인할 수 있습니다. 감시자는 DynamoDB에서 소유하고 관리하며, 감시자가 구성된 리전의 AWS 계정 계정에는 표시되지 않습니다. + MRSC 글로벌 테이블은 다음 리전 세트에서 사용할 수 있습니다. + 미국 리전 세트: 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오리건) + EU 리전 세트: 유럽(아일랜드), 유럽(런던), 유럽(파리), 유럽(프랑크푸르트) + 아시아 태평양 리전 세트: 아시아 태평양(도쿄), 아시아 태평양(서울) 및 아시아 태평양(오사카). + MRSC 글로벌 테이블은 리전 세트에 걸쳐 있을 수 없습니다. 예를 들어 MRSC 글로벌 테이블에는 미국 및 EU 리전 세트의 복제본이 포함될 수 없습니다. + MRSC 글로벌 테이블에는 Time to Live(TTL)가 지원되지 않습니다. + MRSC 글로벌 테이블에는 로컬 보조 인덱스(LSI)가 지원되지 않습니다. + CloudWatch Contributor Insights 정보는 작업이 발생한 리전에 대해서만 보고됩니다. + 로컬 리전은 쿼럼을 설정하기 위해 복제본 또는 감시를 호스팅하는 두 번째 리전이 있는 한 모든 읽기 및 쓰기 작업을 허용합니다. 두 번째 리전을 사용할 수 없는 경우 로컬 리전은 최종적으로 일관된 읽기만 처리할 수 있습니다. + 드물지만 리전이 완전히 오프라인 상태가 되는 경우 나중에 다시 온라인 상태가 되면 자동으로 따라잡습니다. 포착될 때까지 기록 작업과 강력하게 일관된 읽기 작업은 포착 리전*에만* 오류를 반환하고 다른 리전에 대한 요청은 계속 정상적으로 수행됩니다. 추적 리전에 대한 최종적으로 일관된 읽기 작업은 지금까지 리전으로 전파된 데이터를 반환하며, 리더 노드와 로컬 복제본 간의 일반적인 로컬 일관성 동작이 적용됩니다. 테이블을 다시 동기화하기 위한 특별한 작업은 필요하지 않습니다. ## MREC DynamoDB 글로벌 테이블 사용 사례 MREC 글로벌 테이블은 다음과 같은 이점을 제공합니다. + **지연 시간이 짧은 읽기 작업.** 데이터 사본을 최종 사용자 가까이 두어 읽기 작업 중 네트워크 지연 시간을 줄입니다. 데이터는 `ReplicationLatency` 값만큼 최신 상태로 유지됩니다. + **지연 시간이 짧은 쓰기 작업.** 가까운 리전에 쓰기를 수행하여 네트워크 지연 시간과 쓰기에 걸리는 시간을 줄일 수 있습니다. 충돌이 발생하지 않도록 쓰기 트래픽을 신중하게 라우팅해야 합니다. 라우팅 기법은 [DynamoDB의 라우팅 전략](bp-global-table-design.prescriptive-guidance.request-routing.md)에서 자세히 설명합니다. + **원활한 리전 마이그레이션.** 새 리전을 추가한 다음 이전 리전을 삭제하여 데이터 계층의 가동 중단 없이 한 리전에서 다른 리전으로 배포를 마이그레이션할 수 있습니다. MREC 및 MRSC 글로벌 테이블 모두 다음과 같은 이점을 제공합니다. + **복원력 및 재해 복구 향상.** 리전의 성능이 저하되었거나 전체 중단이 발생한 경우 해당 리전을 대피시킬 수 있습니다. 대피한다는 것은 해당 리전으로 이동하는 일부 또는 모든 요청을 다른 곳으로 이동하는 것을 의미합니다. 글로벌 테이블을 사용하면 [DynamoDB SLA](https://aws.amazon.com/dynamodb/sla/)의 월별 가동 시간 비율이 99.99%에서 99.999%로 증가합니다. MREC 사용 시 초 단위로 측정되는 목표 복구 시점(RPO) 및 목표 복구 시간(RTO)를 지원합니다. MRSC 사용 시 0의 RPO를 지원합니다. 예를 들어 Fidelity Investments는 re:Invent 2022 프레젠테이션에서 주문 관리 시스템에 DynamoDB 글로벌 테이블을 사용하는 방법을 소개했습니다. 이들의 목표는 온프레미스 처리로는 달성할 수 없는 규모에서 지연 시간을 안정적으로 줄이는 동시에 가용 영역 및 리전 장애에 대한 복원력을 유지하는 것이었습니다. 복원력 및 재해 복구가 목표라면 MRSC 테이블의 경우 쓰기 및 강력하게 일관된 읽기 지연 시간이 더 높지만 0의 RPO를 지원합니다. MREC 글로벌 테이블은 복제본 간 복제 지연(일반적으로 복제본 리전에 따라 몇 초 정도 소요)과 동일한 RPO를 지원할 수 있습니다. # DynamoDB 글로벌 테이블을 사용한 쓰기 모드 글로벌 테이블은 테이블 수준에서 항상 액티브-액티브입니다. 그러나 특히 MREC 테이블의 경우 쓰기 요청을 라우팅하는 방법을 제어하여 이를 액티브-패시브로 처리할 수도 있습니다. 예를 들어 MREC 테이블에서 발생할 수 있는 잠재적 쓰기 충돌을 방지하기 위해 쓰기 요청을 단일 리전으로 라우팅하기로 결정할 수 있습니다. 다음 세 개의 섹션에서 설명한 대로 세 가지 기본 관리형 쓰기 패턴이 있습니다. 어떤 쓰기 패턴이 사용 사례에 적합한지 고려해야 합니다. 이 선택은 요청 라우팅, 리전 대피, 재해 복구 처리 방법에 영향을 미칩니다. 이후 섹션의 지침은 애플리케이션의 쓰기 모드에 따라 다릅니다. ## 임의의 리전에 쓰기 모드(기본 리전 없음) 다음 다이어그램에 나온 *임의의 리전에 쓰기* 모드는 완전한 액티브-액티브이며, 쓰기가 발생할 수 있는 위치에 제한을 두지 않습니다. 어느 리전이나 언제든지 쓰기를 수락할 수 있습니다. 가장 간단한 모드이지만 일부 유형의 애플리케이션에서만 사용할 수 있습니다. 이 모드는 모든 MRSC 테이블에 적합합니다. 또한 모든 라이터가 멱등적이고 따라서 안전하게 반복할 수 있어 여러 리전에서 동시 또는 반복 쓰기 작업이 충돌하지 않는 MREC 테이블에 적합합니다. 사용자가 연락처 데이터를 업데이트하는 경우를 예로 들 수 있습니다. 이 모드는 모든 쓰기가 결정적 프라이머리 키 아래의 고유한 삽입인 멱등적 추가 전용 데이터 세트 같은 특수한 경우에도 효과적입니다. 마지막으로 이 모드는 쓰기 충돌 위험이 허용 가능한 수준인 MREC에 적합합니다. ![\[클라이언트의 임의의 리전에 쓰기 작동 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png) *임의의 리전에 쓰기* 모드는 가장 간단하게 구현할 수 있는 아키텍처입니다. 어느 리전이나 언제든지 쓰기 대상이 될 수 있으므로 라우팅이 더 쉽습니다. MRSC 테이블에서는 항목이 항상 동기화되고 MRSC 테이블에서는 최근 쓰기를 보조 리전에 원하는 횟수만큼 재생할 수 있으므로 장애 조치가 더 쉽습니다. 가능하면 이 쓰기 모드에 맞춰 설계해야 합니다. 예를 들어 여러 비디오 스트리밍 서비스에서 북마크, 리뷰, 시청 상태 플래그 등을 추적하기 위해 글로벌 테이블을 사용합니다. 이러한 배포는 MREC 테이블을 사용합니다. 전 세계에 분산된 복제본이 필요하기 때문입니다. 이때 각 복제본은 지연 시간이 짧은 읽기 및 쓰기 작업을 제공합니다. 이러한 배포는 모든 쓰기 작업이 멱등성을 유지하는 한 *임의의 리전에 쓰기* 모드를 사용할 수 있습니다. 이는 새로운 최신 타임 코드 설정, 새 검토 할당 또는 새 감시 상태 설정과 같은 모든 업데이트가 사용자의 새 상태를 직접 할당하고 항목에 대한 올바른 다음 값이 현재 값에 의존하지 않는 경우가 이에 해당됩니다. 혹시 사용자의 쓰기 요청이 다른 리전으로 라우팅되는 경우 마지막 쓰기 작업이 지속되고 글로벌 상태는 마지막 할당에 따라 결정됩니다. 이 모드에서 읽기 작업은 최신 `ReplicationLatency` 값만큼 지연된 후 최종적으로 일관됩니다. 또 다른 예로 한 금융 서비스 회사는 시스템의 일부로 글로벌 테이블을 사용하여 각 고객의 직불 카드 구매 현황을 지속적으로 집계하여 해당 고객의 캐시백 보상을 계산합니다. 고객당 `RunningBalance` 항목을 유지하려고 합니다. 이 쓰기 모드는 당연히 멱등성을 지원하지 않습니다. 트랜잭션이 스트리밍되면 새 올바른 값이 현재 값에 따라 달라지는 `ADD` 표현식을 사용하여 밸런스를 수정하기 때문입니다. 모든 `ADD` 직접 호출은 항상 항목의 최신 값에서 작동하므로 MRSC 테이블을 사용하면 계속 *임의의 리전에 쓸* 수 있습니다. 세 번째 예제에는 온라인 광고 배치 서비스를 제공하는 회사와 관련이 있습니다. 이 회사는 *임의의 리전에 쓰기* 모드의 설계 단순화를 위해 낮은 데이터 손실 위험을 감수할 수 있다고 결정했습니다. 회사에서 광고를 게재하는 경우 어떤 광고를 표시할지 결정하기 위해 충분한 메타데이터를 검색하고 사용자에게 동일한 광고가 반복되지 않도록 광고 노출을 기록하는 데 몇 밀리초밖에 걸리지 않습니다. 글로벌 테이블을 사용하면 전 세계 최종 사용자의 읽기 지연 시간과 쓰기 지연 시간 모두 짧아질 수 있습니다. 단일 항목으로 사용자의 모든 광고 노출을 기록하며, 이 항목을 확장되는 목록으로 표시할 수 있습니다. 항목 컬렉션에 추가하는 대신 하나의 항목을 사용합니다. 그러면 삭제 작업에 대한 비용을 지불하지 않고도 각 쓰기의 일부로 오래된 광고 노출을 제거할 수 있습니다. 이 쓰기 작업은 멱등성을 지원하지 않습니다. 따라서 동일한 최종 사용자가 거의 동시에 여러 리전에서 게재되는 광고를 보는 경우 한 광고 노출에 대한 하나의 쓰기 작업이 다른 작업을 덮어쓸 가능성이 있습니다. 이 경우 사용자가 광고를 가끔씩 한 번만 보게 되는 위험이 존재합니다. 이 정도 수준은 허용 가능하다고 결정했습니다. ## 한 리전에 쓰기(단일 기본) 다음 다이어그램에 표시된 *한 리전에 쓰기*와 같은 모드는 액티브-패시브이며 모든 테이블 쓰기를 단일 활성 리전으로 라우팅합니다. 참고로 DynamoDB에는 단일 활성 리전이라는 개념이 없습니다. DynamoDB 외부의 애플리케이션 라우팅이 이를 관리합니다. *한 리전에 쓰기* 모드는 한 번에 한 리전으로만 쓰기 작업을 전달하도록 보장하여 쓰기 충돌을 방지해야 하는 MREC 테이블에 적합합니다. 이 쓰기 모드는 조건식을 사용하려고 하지만 어떤 이유로든 MRSC를 사용할 수 없는 경우 또는 트랜잭션을 수행해야 하는 경우에 도움이 됩니다. 최신 데이터와 반대되는 작업을 수행하고 있음을 인식하지 못하면 이러한 표현식은 불가능합니다. 따라서 모든 쓰기 요청을 최신 데이터를 보유한 단일 리전으로 전송해야 합니다. MRSC 테이블을 사용하는 경우 편의를 위해 일반적으로 한 리전에 쓰도록 선택할 수 있습니다. 예를 들어 이를 통해 DynamoDB 이외의 인프라 빌드를 최소화할 수 있습니다. MRSC를 사용하면 충돌 해결(이 경우 MREC 테이블이 *한 리전에 쓰기*를 선택하게 됨)을 걱정하지 않고도 언제든지 임의의 리전에 안전하게 쓸 수 있으므로 쓰기 모드는 여전히 임의의 리전에 쓰기를 지원할 수 있습니다. 최종 읽기 일관성은 지연 시간을 줄이기 위해 어떤 복제본 리전으로도 갈 수 있습니다. 강력하게 일관된 읽기는 단일 기본 리전으로 가야 합니다. ![\[한 리전에 쓰기의 작동 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png) 리전 장애에 대응하여 활성 리전을 변경해야 하는 경우가 있습니다. 일부 고객은 해바라기(follow-the-sun) 배포 구현과 같이 정기적인 일정에 따라 현재 활성 리전을 변경합니다. 그러면 활동이 가장 많은 지역(이름에서 알 수 있듯이 보통 주간) 근처에 활성 리전을 배치하고, 따라서 읽기 및 쓰기 작업이 지연 시간이 가장 짧습니다. 또한 매일 리전을 변경하는 코드를 직접 호출하면 부가적인 이점도 있습니다. 이를 통해 재해 복구 전에 테스트가 제대로 수행될 수 있습니다. 비활성 리전은 DynamoDB 주위에 다운스케일된 인프라 세트를 유지할 수 있으며, 이 인프라는 활성 리전이 될 경우에만 구축됩니다. 이 가이드에서는 파일럿 라이트 및 예열 대기 방식 설계를 다루지 않습니다. 자세한 내용은 [AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)를 참조하세요. 지연 시간이 짧은 글로벌 분산 읽기 작업에 글로벌 테이블을 사용하는 경우 *한 리전에 쓰기* 모드가 적합합니다. 예를 들어 전 세계 모든 리전에서 동일한 참조 데이터를 사용할 수 있어야 하는 대규모 소셜 미디어 회사가 있습니다. 데이터를 자주 업데이트하지는 않지만 업데이트할 때는 잠재적 쓰기 충돌을 방지하기 위해 한 리전에만 씁니다. 읽기 작업은 항상 임의의 리전에서 허용됩니다. 또 다른 예로 앞서 나온 금융 서비스 회사에서 일일 캐시백 계산을 구현한 사례를 살펴보겠습니다. 이 회사는 잔액을 계산할 때 *임의의 리전에 쓰기* 모드를 사용하지만 지급액을 추적할 때는 *한 리전에 쓰기* 모드를 사용합니다. 이 작업에는 MRSC 테이블에서 지원되지 않는 트랜잭션이 필요하므로 별도의 MREC 테이블과 *한 리전 모드에 쓰기* 모드에 더 적합합니다. ## 사용자 리전에 쓰기(혼합 기본) 다음 다이어그램에 표시된 *사용자 리전에 쓰기* 모드는 MREC 테이블에서 작동합니다. 서로 다른 홈 리전에 서로 다른 데이터 하위 세트를 할당하고 홈 리전을 통해서만 항목에 대한 쓰기 작업을 허용합니다. 이 모드는 액티브-패시브이지만 항목을 기반으로 활성 리전을 할당합니다. 모든 리전은 중복되지 않는 자체 데이터세트에서 기본 리전에 해당하며, 적절한 위치를 보장하기 위해 쓰기 작업을 보호해야 합니다. 이 모드는 각 최종 사용자에 연결된 데이터를 해당 사용자와 더 가까운 네트워크에 배치할 수 있으므로 쓰기 작업 지연 시간을 줄일 수 있다는 점을 제외하면 *한 리전에 쓰기* 모드와 비슷합니다. 또한 리전 사이에서 주변 인프라가 더 균등하게 분산되며, 모든 리전에 인프라의 일부가 이미 활성화되어 있기 때문에 장애 조치 시나리오 중에 인프라를 빌드하는 데 드는 작업이 줄어듭니다. ![\[클라이언트가 단일 리전에서 각 항목에 쓰는 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png) 여러 방법으로 항목의 홈 리전을 확인할 수 있습니다. + **고유성:** 파티션 키에 임베딩된 특수 속성 또는 값과 같은 데이터의 일부 측면을 통해 홈 리전이 명확해집니다. 이 기법은 블로그 게시물 [리전 고정을 사용하여 Amazon DynamoDB 글로벌 테이블의 항목에 대한 홈 리전 설정](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/)에 설명되어 있습니다. + **협상됨:** 각 데이터세트의 홈 리전은 할당을 관리하는 별도의 글로벌 서비스와 협상하는 것과 같이 외부적 방식으로 협상됩니다. 할당 기간이 한정될 수 있으며, 그 이후에는 재협상해야 합니다. + **테이블 중심:** 하나의 복제 글로벌 테이블을 생성하는 대신 복제 리전 수만큼 글로벌 테이블 수를 생성합니다. 각 테이블의 이름은 해당 테이블의 홈 리전을 나타냅니다. 표준 운영에서는 모든 데이터를 홈 리전에 쓰고 다른 리전들은 읽기 전용 사본을 유지합니다. 장애 조치 중에는 해당 테이블에 대한 쓰기 의무를 다른 리전이 일시적으로 채택합니다. 예를 들어 게임 회사에서 일하고 있다고 가정합니다. 전 세계 모든 게이머의 읽기 및 쓰기 지연 시간이 짧아야 합니다. 각 게이머를 가장 가까운 리전에 할당합니다. 해당 리전에서 해당 게이머의 모든 읽기 및 쓰기 작업을 처리하므로 항상 강력한 쓰기 후 읽기 일관성이 유지됩니다. 하지만 해당 게이머가 여행 중이거나 홈 리전에서 중단이 발생하는 경우 대체 리전에서 전체 데이터 사본을 사용할 수 있으며, 게이머를 다른 홈 리전으로 할당할 수 있습니다. 또 다른 예로 화상 회의 회사에서 일하고 있다고 가정합니다. 각 전화 회의의 메타데이터는 특정 리전에 할당됩니다. 발신자는 가장 가까운 리전을 사용하여 지연 시간을 최소화할 수 있습니다. 리전 중단이 발생하는 경우 글로벌 테이블을 사용하면 시스템이 직접 호출의 처리를 이미 데이터의 복제된 사본이 있는 다른 리전으로 이동할 수 있으므로 빠른 복구가 가능합니다. **요약** + 임의의 리전에 쓰기 모드는 MRSC 테이블 및 MREC 테이블에 대한 멱등성 직접 호출에 적합합니다. + 한 리전에 쓰기 모드는 MREC 테이블에 대한 멱등성이 지원되지 않는 직접 호출에 적합합니다. + 사용자 리전에 쓰기 모드는 클라이언트가 가까운 리전에 쓰도록 지원해야 하는 MREC 테이블에 대한 비멱등성 직접 호출에 적합합니다. # DynamoDB의 라우팅 전략 글로벌 테이블 배포에서 가장 복잡한 부분은 아마도 요청 라우팅 관리일 것입니다. 요청은 먼저 최종 사용자에서 출발하여 어떤 방식을 통해 선택 및 라우팅되는 리전으로 가야 합니다. 요청은 AWS Lambda 함수, 컨테이너 또는 Amazon Elastic Compute Cloud(Amazon EC2) 노드가 지원하는 로드 밸런서와 다른 데이터베이스를 비롯한 기타 서비스로 구성된 컴퓨팅 계층을 포함한 해당 리전의 서비스 스택과 만나게 됩니다. 이 컴퓨팅 계층은 DynamoDB와 통신합니다. 그러려면 해당 리전의 로컬 엔드포인트를 사용해야 합니다. 글로벌 테이블의 데이터는 다른 모든 참여 리전에 복제되며, 각 리전의 DynamoDB 테이블에는 비슷한 서비스 스택이 있습니다. 글로벌 테이블은 다양한 리전의 각 스택에 동일한 데이터의 로컬 사본을 제공합니다. 단일 리전의 단일 스택을 상정한 설계를 고려하여 로컬 DynamoDB 테이블에 문제가 생기면 보조 리전의 DynamoDB 엔드포인트에 원격 호출을 하는 방법을 예상할 수 있습니다. 이는 모범 사례가 아닙니다. 한 리전에서 DynamoDB로 인해 발생하는 문제(또는 스택의 다른 항목이나 DynamoDB에 의존하는 다른 서비스로 인해 발생할 수 있음)가 있는 경우 처리를 위해 최종 사용자를 다른 리전으로 라우팅하고 다른 리전의 컴퓨팅 계층을 사용하는 것이 가장 좋습니다. 이때 이 계층은 로컬 DynamoDB 엔드포인트와 통신합니다. 이 접근 방식은 문제가 있는 리전 전체에서 라우팅을 수행합니다. 복원력을 보장하려면 컴퓨팅 계층과 데이터 계층의 복제를 통한 여러 리전에 걸친 복제가 필요합니다. 처리를 위해 최종 사용자 요청을 리전으로 라우팅하는 대체 기법은 매우 많습니다. 최적의 선택은 쓰기 모드와 장애 조치 고려 사항에 따라 달라집니다. 이 섹션에서는 클라이언트 기반, 컴퓨팅 계층, Route 53, Global Accelerator라는 네 가지 옵션에 대해 설명합니다. ## 클라이언트 기반 요청 라우팅 다음 다이어그램에 나와 있는 클라이언트 기반 요청 라우팅을 사용하면 최종 사용자 클라이언트(애플리케이션, JavaScript가 있는 웹 페이지 또는 다른 클라이언트)는 유효한 애플리케이션 엔드포인트(예: 리터럴 DynamoDB 엔드포인트가 아닌 Amazon API Gateway 엔드포인트)를 추적하고 자체 임베디드 로직을 사용하여 통신할 리전을 선택합니다. 무작위 선택, 관찰된 최단 지연 시간, 관찰된 최고 대역폭 측정 또는 로컬에서 수행된 상태 확인을 기반으로 리전을 선택할 수 있습니다. ![\[클라이언트가 선택한 대상에 쓰기가 작동하는 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png) 클라이언트 기반 요청 라우팅의 이점은 성능 저하가 감지되는 경우 실제 퍼블릭 인터넷 트래픽 조건 등에 맞춰 적응할 수 있다는 점입니다. 클라이언트는 모든 잠재적 엔드포인트를 알고 있어야 하지만 새로운 리전 엔드포인트를 시작하는 경우는 드뭅니다. *임의의 리전에 쓰기* 모드에서 클라이언트는 기본 엔드포인트를 일방적으로 선택할 수 있습니다. 한 리전에 대한 액세스가 손상되면 클라이언트는 다른 엔드포인트로 라우팅할 수 있습니다. *한 리전에 쓰기* 모드에서 클라이언트는 쓰기를 현재 활성 리전으로 라우팅하는 메커니즘이 필요합니다. 이는 현재 어느 리전이 쓰기를 허용하고 있는지 경험적으로 테스트(쓰기 거부를 확인하고 대안으로 변경)하는 것처럼 기본적일 수도 있고, 글로벌 코디네이터를 직접 호출하여 현재 애플리케이션 상태를 쿼리하는 것처럼 복잡할 수도 있습니다(이러한 요구 사항에 맞게 글로벌 상태를 유지하기 위해 5개 리전 쿼럼 기반 시스템을 제공하는 Amazon 애플리케이션 복구 컨트롤러(ARC) 라우팅 제어를 기반으로 구축될 수 있음). 클라이언트는 최종 일관성을 위해 읽기를 임의의 리전으로 보내도 되는지 아니면 강력한 일관성을 위해 활성 리전으로 라우팅해야 하는지 결정할 수 있습니다. 자세한 내용은 [Route 53 작동 방식](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html)을 참조하세요. *사용자 리전에 쓰기* 모드에서 클라이언트는 작업 중인 데이터 세트의 홈 리전을 결정해야 합니다. 예를 들어 클라이언트가 사용자 계정에 해당하고 각 사용자 계정에 홈 리전이 있는 경우, 클라이언트는 글로벌 로그인 시스템에 적절한 엔드포인트를 요청할 수 있습니다. 예를 들어 웹을 통한 사용자의 비즈니스 재무 관리를 지원하는 금융 서비스 회사는 *사용자 리전에 쓰기* 모드로 글로벌 테이블을 사용할 수 있습니다. 각 사용자는 중앙 서비스에 로그인해야 합니다. 이 서비스는 보안 인증 정보와 해당 보안 인증 정보가 작동하는 리전의 엔드포인트를 반환합니다. 보안 인증 정보는 짧은 기간 동안 유효합니다. 그 후 웹 페이지는 새 로그인을 자동으로 협상하여 사용자의 활동을 새 리전으로 리디렉션할 수 있는 기회를 제공합니다. ## 컴퓨팅 계층 요청 라우팅 다음 다이어그램과 같이 컴퓨팅 계층 요청 라우팅의 경우, 컴퓨팅 계층에서 실행되는 코드가 요청을 로컬에서 처리할지, 다른 리전에서 실행되는 해당 코드의 사본에 전달할지 결정합니다. *한 리전에 쓰기* 모드를 사용하면 컴퓨팅 계층은 리전이 활성 리전이 아님을 감지하고 로컬 읽기 작업을 허용하면서 모든 쓰기 작업을 다른 리전으로 전달할 수 있습니다. 이 컴퓨팅 계층 코드는 데이터 토폴로지 및 라우팅 규칙을 인식하고 어떤 리전이 어떤 데이터에 활성 상태인지 지정하는 최신 설정을 기반으로 이를 안정적으로 적용해야 합니다. 해당 리전 내의 외부 소프트웨어 스택은 마이크로서비스가 읽기 및 쓰기 요청을 어떻게 라우팅하는지 몰라도 됩니다. 강력한 설계에서 수신 리전은 자신이 쓰기 작업의 현재 기본 리전인지 여부를 확인합니다. 기본 리전이 아니라면 글로벌 상태를 수정해야 한다는 오류 메시지가 생성됩니다. 또한 기본 리전이 변경 중일 경우 수신 리전은 쓰기 작업을 잠시 버퍼링할 수 있습니다. 어떤 경우든 리전의 컴퓨팅 스택은 해당 로컬 DynamoDB 엔드포인트에만 쓰지만 컴퓨팅 스택은 서로 통신할 수 있습니다. ![\[컴퓨팅 계층 요청 라우팅 다이어그램\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png) Vanguard Group은 [re:Invent 2022](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s)의 발표 내용대로 이 라우팅 프로세스에 글로벌 오케스트레이션 및 상태 도구(GOaST)라는 시스템과 글로벌 다중 리전 라이브러리(GMRlib)라는 라이브러리를 사용합니다. 그리고 해바라기 단일 기본 모델을 사용합니다. GOaST는 이전 섹션에서 설명한 ARC 라우팅 제어와 마찬가지로 글로벌 상태를 유지 관리합니다. 이 회사는 글로벌 테이블을 사용하여 기본 리전에 해당하는 리전과 다음 기본 리전 전환의 예약 시점을 추적합니다. 모든 읽기 및 쓰기 작업은 GOaST에서 조정되는 GMRlib를 통해 진행됩니다. GMRlib를 사용하면 짧은 지연 시간으로 로컬에서 쓰기 작업을 수행할 수 있습니다. 쓰기 작업의 경우 GMRlib는 로컬 리전이 현재 기본 리전인지 확인합니다. 현재 기본 리전인 경우 쓰기 작업이 직접 완료됩니다. 그렇지 않은 경우 GMRlib는 쓰기 작업을 기본 리전의 GMRlib로 전달합니다. 이 수신 라이브러리는 자신도 스스로를 기본 리전으로 간주한다는 것을 확인하고, 그렇지 않은 경우 글로벌 상태의 전파 지연을 나타내는 오류를 발생시킵니다. 이 접근 방식은 원격 DynamoDB 엔드포인트에 직접 쓰지 않으므로 검증에 도움이 됩니다. ## Route 53 요청 라우팅 Amazon Application Recovery Controller(ARC)는 도메인 이름 서비스(DNS) 기술입니다. Route 53에서 클라이언트는 잘 알려진 DNS 도메인 이름을 조회하여 엔드포인트를 요청하고, Route 53은 가장 적절하다고 판단되는 리전 엔드포인트에 해당하는 IP 주소를 반환합니다. 다음 다이어그램에 이 내용이 잘 설명되어 있습니다. Route 53에는 적절한 리전을 판단하는 데 사용하는 라우팅 정책에 대한 긴 목록이 있습니다. 또한 장애 조치 라우팅을 수행하여 상태 확인에 실패한 리전 외부로 트래픽을 라우팅할 수 있습니다. ![\[컴퓨팅 계층 요청 라우팅 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png) *임의의 리전에 쓰기* 모드를 사용하거나 백엔드의 컴퓨팅 계층 요청 라우팅과 결합될 경우, 네트워크와 가장 가까운 리전 또는 지리적으로 가장 가까운 리전 또는 기타 선택 등 복잡한 내부 규칙에 기반하여 리전을 반환할 수 있는 전체 액세스 권한을 Route 53에 부여할 수 있습니다. *한 리전에 쓰기* 모드를 사용하면 현재 활성 리전을 반환하도록 Route 53을 구성할 수 있습니다(Route 53 ARC 사용). 클라이언트가 패시브 리전에 연결하려는 경우(예: 읽기 작업의 경우) 다른 DNS 이름을 조회할 수 있습니다. **참고** 클라이언트는 Route 53의 응답에 있는 IP 주소를 도메인 이름에 TTL(Time to Live) 설정으로 표시된 시간 동안 캐시합니다. TTL이 길수록 모든 클라이언트가 새 엔드포인트를 인식할 수 있는 Recovery Time Objective(RTO)가 연장됩니다. 일반적으로 장애 조치에는 60초 값을 사용합니다. 일부 소프트웨어가 DNS TTL 만료를 완벽하게 준수하지 못하며 운영 체제, 가상 머신 및 애플리케이션과 같은 여러 수준의 DNS 캐싱이 존재할 수 있습니다. *사용자 리전에 쓰기* 모드에서는 컴퓨팅 계층 요청 라우팅도 사용하지 않는 한 Route 53을 사용하지 않는 것이 가장 좋습니다. ## Global Accelerator 요청 라우팅 다음 다이어그램에 나와 있는 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)를 사용하면 클라이언트가 Route 53에서 잘 알려진 도메인 이름을 조회합니다. 하지만 클라이언트는 리전 엔드포인트에 해당하는 IP 주소를 돌려받는 대신 가장 가까운 AWS 엣지 로케이션으로 라우팅되는 애니캐스트 고정 IP 주소를 받습니다. 모든 트래픽은 이 엣지 로케이션에서 출발하여 프라이빗 AWS 네트워크에서 Global Accelerator 내에 유지되는 라우팅 규칙에 따라 선택된 리전의 일부 엔드포인트(예: 로드 밸런서 또는 API Gateway)로 라우팅됩니다. Route 53 규칙에 기반한 라우팅과 비교할 때 Global Accelerator 요청 라우팅은 공용 인터넷의 트래픽 양을 줄이므로 지연 시간이 짧습니다. 또한 Global Accelerator는 라우팅 규칙을 변경할 때 DNS TTL 만료에 의존하지 않으므로 라우팅을 더 빠르게 조정할 수 있습니다. ![\[Global Accelerator를 사용한 클라이언트 쓰기의 작동 방식을 보여 주는 다이어그램.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png) Global Accelerator는 *임의의 리전에 쓰기* 모드를 사용하거나 백엔드의 컴퓨팅 계층 요청 라우팅과 결합할 경우 원활하게 작동합니다. 클라이언트는 가장 가까운 엣지 로케이션에 연결하며, 요청을 받는 리전에 신경 쓸 필요가 없습니다. *한 리전에 쓰기*를 사용하는 경우 Global Accelerator 라우팅 규칙은 현재 활성 리전으로 요청을 보내야 합니다. 글로벌 시스템에서 활성 리전으로 간주되지 않는 리전의 장애를 인위적으로 보고하는 상태 확인을 사용할 수 있습니다. DNS와 마찬가지로 요청이 어느 리전에서나 올 수 있다면 대체 DNS 도메인 이름을 사용하여 읽기 요청을 라우팅할 수 있습니다. *사용자 리전에 쓰기* 모드에서는 컴퓨팅 계층 요청 라우팅을 함께 사용하지 않는 한 Global Accelerator를 사용하지 않는 것이 가장 좋습니다. # 대피 프로세스 리전 대피란, 일반적으로 읽기 및 쓰기 활동 또는 읽기 활동과 같은 활동을 해당 리전 외부로 마이그레이션하는 프로세스입니다. ## 라이브 리전 대피 일상적인 비즈니스 활동의 일환(예: 해바라기 방식을 사용하는 경우 한 리전 모드에 쓰기), 현재 활성 리전을 변경하려는 비즈니스 결정, DynamoDB 외부의 소프트웨어 스택 장애에 대한 대응 또는 리전 내에서 일반적인 지연 시간보다 높은 지연 시간 등의 일반적인 문제가 발생하는 경우와 같이 여러 가지 이유로 라이브 리전을 대피하기로 결정할 수 있습니다. *임의의 리전에 쓰기* 모드에서는 라이브 리전 대피가 간단합니다. 라우팅 시스템을 통해 트래픽을 대체 리전으로 라우팅하고, 대피된 리전의 쓰기 작업을 평소처럼 복제할 수 있습니다. 한 리전에 쓰기 및 사용자 리전 모드에 쓰기는 일반적으로 MREC 테이블과 함께 사용됩니다. 따라서 새 활성 리전에서 쓰기 작업을 시작하기 전에 활성 리전에 대한 모든 쓰기 작업이 완전히 기록되고, 스트림 처리되며, 글로벌로 전파되었는지 확인하여 최신 버전의 데이터에서 향후 쓰기 작업이 처리되도록 해야 합니다. 리전 A는 활성이고 지역 B는 비활성이라고 가정해 보겠습니다(전체 테이블 또는 리전 A에 있는 항목의 경우). 대피를 수행하는 일반적인 메커니즘은 A에 대한 쓰기 작업을 일시 중지하고 이러한 작업이 B로 완전히 전파될 때까지 충분히 기다린 후 B를 활성으로 인식하도록 아키텍처 스택을 업데이트한 다음 B에 쓰기 작업을 재개하는 것입니다. 리전 A의 데이터가 리전 B에 완전히 복제되었음을 100% 확실하게 나타내는 지표는 없습니다. 리전 A가 정상인 경우 리전 A에 대한 쓰기 작업을 일시 중지하고 `ReplicationLatency` 지표의 최근 최대값의 10배를 기다리면 일반적으로 복제가 완료되었는지 확인하는 데 충분합니다. 리전 A가 비정상이고 다른 영역에서 지연 시간이 길어지면 대기 시간을 더 큰 배수로 설정할 수 있습니다. ## 오프라인 리전 대피 고려해야 할 특별한 경우가 있습니다. 리전 A가 예고 없이 완전히 오프라인 상태가 되면 어떻게 되나요? 이는 매우 드물지만 고려해야 하는 사안입니다. 오프라인 MRSC 테이블 대피 MRSC 테이블에서 이런 상황이 발생하면 특별한 조치는 필요하지 않습니다. MRSC 글로벌 테이블은 0의 목표 복구 시점(RPO)을 지원합니다. 오프라인 리전에서 MRSC 테이블에 대한 모든 성공적인 쓰기 작업은 다른 모든 리전 테이블에서 사용할 수 있으므로, 리전이 예고 없이 완전히 오프라인 상태가 되더라도 데이터에서 격차는 발생하지 않습니다. 비즈니스는 다른 리전에 있는 복제본을 계속 사용할 수 있습니다. 오프라인 MREC 테이블 대피 MREC 테이블에서 이와 같은 상황이 나타나는 경우에는 아직 전파되지 않은 리전 A의 모든 쓰기 작업은 보관되었다가 리전 A가 다시 온라인 상태가 된 후에 전파됩니다. 쓰기 작업은 손실되지 않지만 전파는 무기한 지연됩니다. 이 경우 어떻게 진행할지는 애플리케이션이 결정합니다. 비즈니스 연속성을 위해서는 새 기본 리전 B에 쓰기 작업을 계속해야 할 수도 있습니다. 하지만 리전 A로부터 항목에 대한 쓰기 작업 전파가 보류 중인 동안 리전 B의 해당 항목이 업데이트를 수신하는 경우, *최종 쓰기 우선* 모델에서는 전파가 억제됩니다. 리전 B에서의 모든 업데이트는 수신되는 쓰기 요청을 억제할 수 있습니다. *임의의 리전에 쓰기* 모드에서는 리전 A의 항목이 결국 리전 B로 전파될 것으로 믿고 리전 A가 다시 온라인 상태가 될 때까지 항목이 누락될 가능성을 인식하면서 리전 B에서 읽기와 쓰기를 계속할 수 있습니다. 멱등성 쓰기 작업에서와 같이 가능하면 최근 쓰기 트래픽을 재생(예: 업스트림 이벤트 소스 사용)하여 누락될 수 있는 쓰기 작업의 공백을 메우고, 최종 쓰기 우선 충돌 해결이 수신 쓰기 작업의 최종 전파를 억제하도록 하는 방법을 고려해야 합니다. 그 밖의 쓰기 모드에서는 살짝 최신에서 뒤떨어진 데이터로 작업을 계속할 수 있는 정도를 고려해야 합니다. `ReplicationLatency`로 추적되는 짧은 기간 동안의 일부 쓰기 작업은 리전 A가 다시 온라인 상태가 될 때까지 누락됩니다. 비즈니스를 계속 진행할 수 있을까요? 진행 가능한 사용 사례도 있겠지만 추가 완화 메커니즘 없이는 가능하지 않을 수도 있습니다. 예를 들어 리전의 완전 중단 이후에도 중지 없이 사용 가능한 크레딧 잔액을 유지 관리해야 한다고 가정합니다. 잔액을 서로 다른 두 항목(리전 A가 홈 리전인 항목과 리전 B가 홈 리전인 항목)으로 나누고 각각 사용 가능한 잔액의 절반에서 시작할 수 있습니다. 이렇게 하면 *사용자 리전에 쓰기* 모드를 사용하는 것입니다. 각 리전에서 처리되는 트랜잭션 업데이트는 잔액의 로컬 사본에 기록됩니다. 리전 A가 완전히 오프라인 상태가 되더라도 리전 B에서 트랜잭션 처리를 계속 진행할 수 있으며, 쓰기 작업은 리전 B에 보관된 잔액 부분으로만 제한됩니다. 이렇게 잔액을 분할하면 잔액이 낮아지거나 크레딧을 재조정해야 할 때 복잡성이 발생하지만, 보류 중인 쓰기 작업에 불확실성이 있더라도 비즈니스를 안전하게 복구할 수 있는 한 가지 예가 됩니다. 또 다른 예로 웹 양식 데이터를 캡처하는 경우를 가정합니다. [OCC(낙관적 동시성 제어)](DynamoDBMapper.OptimisticLocking.md)를 사용하여 데이터 항목에 버전을 할당하고 최신 버전을 웹 양식에 숨겨진 필드로 포함할 수 있습니다. 제출할 때마다 데이터베이스에 있는 버전이 양식의 작성 기준 버전과 일치하는 경우에만 쓰기 작업이 성공합니다. 버전이 일치하지 않는 경우 데이터베이스에 있는 현재 버전을 기반으로 웹 양식을 새로 고치거나 신중하게 병합할 수 있고, 사용자는 다시 진행할 수 있습니다. OCC 모델은 일반적으로 다른 클라이언트가 데이터를 덮어쓰고 새 버전의 데이터를 생성하지 못하도록 보호하지만, 클라이언트가 이전 버전의 데이터를 발견할 수 있는 장애 조치 중에도 도움이 될 수 있습니다. 타임스탬프를 버전으로 사용하고 있다고 가정해 보겠습니다. 양식이 리전 A에서 12:00에 처음 빌드되었지만 장애 조치 이후 리전 B에 쓰려고 시도하다가 데이터베이스에 있는 최신 버전이 11:59임을 알게 되었다고 가정합니다. 이 시나리오에서 클라이언트는 12:00 버전이 리전 B로 전파될 때까지 기다린 다음 이 버전을 기반으로 쓰거나, 11:59를 기반으로 빌드하고 새 12:01 버전(쓰기 후에 리전 A가 복구된 후 수신 버전을 억제)을 생성할 수 있습니다. 마지막 세 번째 예에서는 한 금융 서비스 회사가 DynamoDB 데이터베이스에 고객 계정 및 금융 거래에 대한 데이터를 보관합니다. 이 회사는 리전 A가 완전히 중단될 경우 고객 계정과 관련된 모든 쓰기 활동을 리전 B에서 완전히 사용할 수 있도록 하거나 리전 A가 다시 온라인 상태가 될 때까지 부분적으로 알려진 고객 계정을 격리하고자 했습니다. 이 회사는 모든 업무를 일시 중지하는 대신 트랜잭션이 전파되지 않은 것으로 판단되는 극히 일부의 계정만 업무를 일시 중지하기로 결정했습니다. 이를 위해 리전 C라고 부르는 세 번째 리전을 사용했습니다. 리전 A에서 쓰기 작업을 처리하기 전에 보류 중인 작업(예: 계정의 새 트랜잭션 수)을 간략하게 요약하여 리전 C에 배치했습니다. 이 요약만으로도 리전 B가 해당 뷰가 최신 상태인지 판단하기에 충분했습니다. 이 조치로 인해 리전 C에서의 쓰기 시점부터 리전 A가 쓰기 작업을 수락하고 지역 B가 쓰기 작업을 수신할 때까지 계정이 사실상 잠겼습니다. 리전 C에 있는 데이터는 장애 조치 프로세스의 일부인 경우를 제외하고는 사용되지 않았습니다. 장애 조치 후 리전 B는 리전 C와 데이터를 교차 검증하여 최신 상태가 아닌 계정이 있는지 확인할 수 있었습니다. 이러한 계정은 리전 A 복구 시 부분 데이터를 리전 B로 전파할 때까지 격리된 것으로 표시됩니다. 리전 C가 실패하면 새 리전 D를 대신 사용할 수 있습니다. 데이터는 리전 C에 아주 잠깐 머물렀고, 몇 분 후에는 진행 중인 쓰기 작업에 대한 충분히 유용한 최신 기록이 리전 D에 있게 됩니다. 리전 B에 장애가 발생할 경우 리전 A는 리전 C와 협력하여 쓰기 요청을 계속 수락할 수 있었습니다. 이 회사는 지연 시간이 더 긴 쓰기(리전 C와 리전 A에 대한 쓰기)를 받아들일 용의가 있었고, 다행히도 계정 상태를 간략하게 요약할 수 있는 데이터 모델이 있었습니다. # DynamoDB 글로벌 테이블의 처리량 용량 계획 한 리전에서 다른 리전으로 트래픽을 마이그레이션하려면 용량과 관련된 DynamoDB 테이블 설정을 신중하게 고려해야 합니다. 다음은 쓰기 용량 관리에 관한 몇 가지 고려 사항입니다. + 글로벌 테이블은 온디맨드 모드이거나 Auto Scaling이 활성화된 상태로 프로비저닝되어야 합니다. + Auto Scaling으로 프로비저닝된 경우 쓰기 설정(최소, 최대, 목표 사용률)이 여러 리전에 복제됩니다. 오토 스케일링 설정은 동기화되지만 실제로 프로비저닝되는 쓰기 용량은 리전 간에 독립적으로 변동될 수 있습니다. + 프로비저닝된 쓰기 용량이 다르게 보일 수 있는 한 가지 이유는 TTL 기능 때문입니다. DynamoDB에서 TTL을 활성화할 때 값이 항목의 만료 시간을 나타내는 속성 이름을 초 단위로 Unix epoch 시간 형식으로 지정할 수 있습니다. 이 시간이 지나면 DynamoDB가 쓰기 비용 없이 항목을 삭제할 수 있습니다. 글로벌 테이블을 사용하는 경우 한 리전에서 TTL을 구성하면 글로벌 테이블과 연결된 다른 리전에 설정이 자동으로 복제됩니다. TTL 규칙을 통해 항목을 삭제할 수 있는 경우 모든 리전에서 이 작업을 수행할 수 있습니다. 삭제 작업은 원본 테이블의 쓰기 단위를 소비하지 않고 수행되지만 복제본 테이블은 해당 삭제 작업의 복제된 쓰기를 받게 되며 복제된 쓰기 단위 비용이 발생합니다. TTL은 MRSC 테이블에서 지원되지 않습니다. + Auto Scaling을 사용하는 경우 프로비저닝된 최대 쓰기 용량 설정이 모든 쓰기 작업과 모든 잠재적 TTL 삭제 작업을 처리할 수 있을 만큼 충분히 높아야 합니다. Auto Scaling은 쓰기 사용량에 따라 각 리전을 조정합니다. 온디맨드 테이블에는 프로비저닝된 최대 쓰기 용량 설정이 없지만 *테이블 수준 최대 쓰기 처리량 제한*이 온디맨드 테이블이 허용하는 최대 지속 쓰기 용량을 지정합니다. 기본 제한은 40,000이지만 조정할 수 있습니다. 온디맨드 테이블에 필요할 수 있는 모든 쓰기 작업(TTL 쓰기 작업 포함)을 처리할 수 있을 만큼 이 제한을 충분히 높게 설정하는 것이 좋습니다. 글로벌 테이블을 설정할 때는 모든 참여 리전에서 이 값이 동일해야 합니다. 다음은 읽기 용량 관리에 관한 몇 가지 고려 사항입니다. + 리전마다 읽기 패턴이 독립적일 수 있다고 가정하기 때문에 읽기 용량 관리 설정이 리전마다 다를 수 있습니다. 테이블에 처음 글로벌 복제본을 추가하면 소스 리전의 용량이 전파됩니다. 생성 후에 읽기 용량 설정을 조정할 수 있으며, 이 설정은 반대쪽으로 전송되지 않습니다. + DynamoDB Auto Scaling을 사용할 때는 프로비저닝된 최대 읽기 용량 설정이 모든 리전에서 모든 읽기 작업을 처리할 수 있을 만큼 충분히 높아야 합니다. 표준 운영 중에는 읽기 용량이 여러 지역에 분산될 수 있지만 장애 조치 중에는 테이블이 증가된 읽기 워크로드에 맞게 자동으로 조정될 수 있어야 합니다. 온디맨드 테이블에는 프로비저닝된 최대 읽기 용량 설정이 없지만 *테이블 수준 최대 읽기 처리량 제한*이 온디맨드 테이블이 허용하는 최대 지속 읽기 용량을 지정합니다. 기본 제한은 40,000이지만 조정할 수 있습니다. 모든 읽기 작업이 이 단일 리전으로 라우팅되는 경우 테이블에 필요할 수 있는 모든 읽기 작업을 처리할 수 있을 만큼 이 제한을 충분히 높게 설정하는 것이 좋습니다. + 한 리전의 테이블이 일반적으로 읽기 트래픽을 수신하지 않지만 장애 조치 후 대량의 읽기 트래픽을 흡수해야 할 수도 있는 경우, 더 높은 수준의 읽기 트래픽을 허용하도록 용량을 미리 워밍할 수 있습니다. ARC에 있는 [준비 상태 확인](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html) 기능은 Route 53을 사용하여 요청을 라우팅하는지 여부에 관계없이 DynamoDB 리전에 유사한 테이블 설정과 계정 할당량이 있는지 확인하는 데 유용할 수 있습니다. 이러한 준비 상태 확인은 계정 수준의 할당량을 조정하여 일치하도록 하는 데도 도움이 될 수 있습니다. # DynamoDB 글로벌 테이블 준비 체크리스트 글로벌 테이블을 배포할 때 의사 결정 및 작업에 다음 체크리스트를 사용하세요. + 사용 사례가 MRSC 또는 MREC 일관성 모드 중 무엇에서 더 많은 이점을 얻을 수 있는지 확인합니다. 지연 시간이 길고 다른 장단점이 있더라도 강력한 일관성이 필요한가요? + 글로벌 테이블에 참여해야 하는 리전과 리전 수를 결정합니다. MRSC를 사용하려는 경우 세 번째 리전을 복제본 또는 감시자로 지정할지 결정합니다. + 애플리케이션의 쓰기 모드를 결정합니다. 이는 일관성 모드와 동일하지 않습니다. 자세한 내용은 [DynamoDB 글로벌 테이블을 사용한 쓰기 모드](bp-global-table-design.prescriptive-guidance.writemodes.md) 섹션을 참조하세요. + 쓰기 모드에 따라 [DynamoDB의 라우팅 전략](bp-global-table-design.prescriptive-guidance.request-routing.md) 전략을 계획합니다. + 일관성 모드, 쓰기 모드 및 라우팅 전략에 따라 [ 대피 프로세스 글로벌 테이블을 사용한 리전 대피 리전 대피란, 일반적으로 읽기 및 쓰기 활동 또는 읽기 활동과 같은 활동을 해당 리전 외부로 마이그레이션하는 프로세스입니다. 라이브 리전 대피라이브 리전 라이브 리전 대피 일상적인 비즈니스 활동의 일환(예: 해바라기 방식을 사용하는 경우 한 리전 모드에 쓰기), 현재 활성 리전을 변경하려는 비즈니스 결정, DynamoDB 외부의 소프트웨어 스택 장애에 대한 대응 또는 리전 내에서 일반적인 지연 시간보다 높은 지연 시간 등의 일반적인 문제가 발생하는 경우와 같이 여러 가지 이유로 라이브 리전을 대피하기로 결정할 수 있습니다. *임의의 리전에 쓰기* 모드에서는 라이브 리전 대피가 간단합니다. 라우팅 시스템을 통해 트래픽을 대체 리전으로 라우팅하고, 대피된 리전의 쓰기 작업을 평소처럼 복제할 수 있습니다. 한 리전에 쓰기 및 사용자 리전 모드에 쓰기는 일반적으로 MREC 테이블과 함께 사용됩니다. 따라서 새 활성 리전에서 쓰기 작업을 시작하기 전에 활성 리전에 대한 모든 쓰기 작업이 완전히 기록되고, 스트림 처리되며, 글로벌로 전파되었는지 확인하여 최신 버전의 데이터에서 향후 쓰기 작업이 처리되도록 해야 합니다. 리전 A는 활성이고 지역 B는 비활성이라고 가정해 보겠습니다(전체 테이블 또는 리전 A에 있는 항목의 경우). 대피를 수행하는 일반적인 메커니즘은 A에 대한 쓰기 작업을 일시 중지하고 이러한 작업이 B로 완전히 전파될 때까지 충분히 기다린 후 B를 활성으로 인식하도록 아키텍처 스택을 업데이트한 다음 B에 쓰기 작업을 재개하는 것입니다. 리전 A의 데이터가 리전 B에 완전히 복제되었음을 100% 확실하게 나타내는 지표는 없습니다. 리전 A가 정상인 경우 리전 A에 대한 쓰기 작업을 일시 중지하고 `ReplicationLatency` 지표의 최근 최대값의 10배를 기다리면 일반적으로 복제가 완료되었는지 확인하는 데 충분합니다. 리전 A가 비정상이고 다른 영역에서 지연 시간이 길어지면 대기 시간을 더 큰 배수로 설정할 수 있습니다. 오프라인 리전 대피오프라인 리전 오프라인 리전 대피 고려해야 할 특별한 경우가 있습니다. 리전 A가 예고 없이 완전히 오프라인 상태가 되면 어떻게 되나요? 이는 매우 드물지만 고려해야 하는 사안입니다. 오프라인 MRSC 테이블 대피 MRSC 테이블에서 이런 상황이 발생하면 특별한 조치는 필요하지 않습니다. MRSC 글로벌 테이블은 0의 목표 복구 시점(RPO)을 지원합니다. 오프라인 리전에서 MRSC 테이블에 대한 모든 성공적인 쓰기 작업은 다른 모든 리전 테이블에서 사용할 수 있으므로, 리전이 예고 없이 완전히 오프라인 상태가 되더라도 데이터에서 격차는 발생하지 않습니다. 비즈니스는 다른 리전에 있는 복제본을 계속 사용할 수 있습니다. 오프라인 MREC 테이블 대피 MREC 테이블에서 이와 같은 상황이 나타나는 경우에는 아직 전파되지 않은 리전 A의 모든 쓰기 작업은 보관되었다가 리전 A가 다시 온라인 상태가 된 후에 전파됩니다. 쓰기 작업은 손실되지 않지만 전파는 무기한 지연됩니다. 이 경우 어떻게 진행할지는 애플리케이션이 결정합니다. 비즈니스 연속성을 위해서는 새 기본 리전 B에 쓰기 작업을 계속해야 할 수도 있습니다. 하지만 리전 A로부터 항목에 대한 쓰기 작업 전파가 보류 중인 동안 리전 B의 해당 항목이 업데이트를 수신하는 경우, *최종 쓰기 우선* 모델에서는 전파가 억제됩니다. 리전 B에서의 모든 업데이트는 수신되는 쓰기 요청을 억제할 수 있습니다. *임의의 리전에 쓰기* 모드에서는 리전 A의 항목이 결국 리전 B로 전파될 것으로 믿고 리전 A가 다시 온라인 상태가 될 때까지 항목이 누락될 가능성을 인식하면서 리전 B에서 읽기와 쓰기를 계속할 수 있습니다. 멱등성 쓰기 작업에서와 같이 가능하면 최근 쓰기 트래픽을 재생(예: 업스트림 이벤트 소스 사용)하여 누락될 수 있는 쓰기 작업의 공백을 메우고, 최종 쓰기 우선 충돌 해결이 수신 쓰기 작업의 최종 전파를 억제하도록 하는 방법을 고려해야 합니다. 그 밖의 쓰기 모드에서는 살짝 최신에서 뒤떨어진 데이터로 작업을 계속할 수 있는 정도를 고려해야 합니다. `ReplicationLatency`로 추적되는 짧은 기간 동안의 일부 쓰기 작업은 리전 A가 다시 온라인 상태가 될 때까지 누락됩니다. 비즈니스를 계속 진행할 수 있을까요? 진행 가능한 사용 사례도 있겠지만 추가 완화 메커니즘 없이는 가능하지 않을 수도 있습니다. 예를 들어 리전의 완전 중단 이후에도 중지 없이 사용 가능한 크레딧 잔액을 유지 관리해야 한다고 가정합니다. 잔액을 서로 다른 두 항목(리전 A가 홈 리전인 항목과 리전 B가 홈 리전인 항목)으로 나누고 각각 사용 가능한 잔액의 절반에서 시작할 수 있습니다. 이렇게 하면 *사용자 리전에 쓰기* 모드를 사용하는 것입니다. 각 리전에서 처리되는 트랜잭션 업데이트는 잔액의 로컬 사본에 기록됩니다. 리전 A가 완전히 오프라인 상태가 되더라도 리전 B에서 트랜잭션 처리를 계속 진행할 수 있으며, 쓰기 작업은 리전 B에 보관된 잔액 부분으로만 제한됩니다. 이렇게 잔액을 분할하면 잔액이 낮아지거나 크레딧을 재조정해야 할 때 복잡성이 발생하지만, 보류 중인 쓰기 작업에 불확실성이 있더라도 비즈니스를 안전하게 복구할 수 있는 한 가지 예가 됩니다. 또 다른 예로 웹 양식 데이터를 캡처하는 경우를 가정합니다. [OCC(낙관적 동시성 제어)](DynamoDBMapper.OptimisticLocking.md)를 사용하여 데이터 항목에 버전을 할당하고 최신 버전을 웹 양식에 숨겨진 필드로 포함할 수 있습니다. 제출할 때마다 데이터베이스에 있는 버전이 양식의 작성 기준 버전과 일치하는 경우에만 쓰기 작업이 성공합니다. 버전이 일치하지 않는 경우 데이터베이스에 있는 현재 버전을 기반으로 웹 양식을 새로 고치거나 신중하게 병합할 수 있고, 사용자는 다시 진행할 수 있습니다. OCC 모델은 일반적으로 다른 클라이언트가 데이터를 덮어쓰고 새 버전의 데이터를 생성하지 못하도록 보호하지만, 클라이언트가 이전 버전의 데이터를 발견할 수 있는 장애 조치 중에도 도움이 될 수 있습니다. 타임스탬프를 버전으로 사용하고 있다고 가정해 보겠습니다. 양식이 리전 A에서 12:00에 처음 빌드되었지만 장애 조치 이후 리전 B에 쓰려고 시도하다가 데이터베이스에 있는 최신 버전이 11:59임을 알게 되었다고 가정합니다. 이 시나리오에서 클라이언트는 12:00 버전이 리전 B로 전파될 때까지 기다린 다음 이 버전을 기반으로 쓰거나, 11:59를 기반으로 빌드하고 새 12:01 버전(쓰기 후에 리전 A가 복구된 후 수신 버전을 억제)을 생성할 수 있습니다. 마지막 세 번째 예에서는 한 금융 서비스 회사가 DynamoDB 데이터베이스에 고객 계정 및 금융 거래에 대한 데이터를 보관합니다. 이 회사는 리전 A가 완전히 중단될 경우 고객 계정과 관련된 모든 쓰기 활동을 리전 B에서 완전히 사용할 수 있도록 하거나 리전 A가 다시 온라인 상태가 될 때까지 부분적으로 알려진 고객 계정을 격리하고자 했습니다. 이 회사는 모든 업무를 일시 중지하는 대신 트랜잭션이 전파되지 않은 것으로 판단되는 극히 일부의 계정만 업무를 일시 중지하기로 결정했습니다. 이를 위해 리전 C라고 부르는 세 번째 리전을 사용했습니다. 리전 A에서 쓰기 작업을 처리하기 전에 보류 중인 작업(예: 계정의 새 트랜잭션 수)을 간략하게 요약하여 리전 C에 배치했습니다. 이 요약만으로도 리전 B가 해당 뷰가 최신 상태인지 판단하기에 충분했습니다. 이 조치로 인해 리전 C에서의 쓰기 시점부터 리전 A가 쓰기 작업을 수락하고 지역 B가 쓰기 작업을 수신할 때까지 계정이 사실상 잠겼습니다. 리전 C에 있는 데이터는 장애 조치 프로세스의 일부인 경우를 제외하고는 사용되지 않았습니다. 장애 조치 후 리전 B는 리전 C와 데이터를 교차 검증하여 최신 상태가 아닌 계정이 있는지 확인할 수 있었습니다. 이러한 계정은 리전 A 복구 시 부분 데이터를 리전 B로 전파할 때까지 격리된 것으로 표시됩니다. 리전 C가 실패하면 새 리전 D를 대신 사용할 수 있습니다. 데이터는 리전 C에 아주 잠깐 머물렀고, 몇 분 후에는 진행 중인 쓰기 작업에 대한 충분히 유용한 최신 기록이 리전 D에 있게 됩니다. 리전 B에 장애가 발생할 경우 리전 A는 리전 C와 협력하여 쓰기 요청을 계속 수락할 수 있었습니다. 이 회사는 지연 시간이 더 긴 쓰기(리전 C와 리전 A에 대한 쓰기)를 받아들일 용의가 있었고, 다행히도 계정 상태를 간략하게 요약할 수 있는 데이터 모델이 있었습니다. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title), [대피 프로세스](bp-global-table-design.prescriptive-guidance.evacuation.md)을 정의합니다. + 각 리전의 상태, 지연 시간, 오류에 대한 지표를 캡처합니다. DynamoDB 지표 목록은 AWS 블로그 게시물 [Monitoring Amazon DynamoDB for Operational Awareness](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)에 있는 관찰해야 할 지표 목록을 참조하세요. 또한 [합성 카나리아](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)(장애를 감지하도록 설계된 인위적 요청으로, 탄광에 있는 카나리아에서 유래)를 사용하고 고객 트래픽을 실시간으로 관찰해야 합니다. 모든 문제가 DynamoDB 지표에 나타나는 것은 아닙니다. + MREC를 사용하는 경우 `ReplicationLatency`에서 지속적인 증가에 대한 경보를 설정합니다. 증가는 글로벌 테이블의 쓰기 설정이 리전마다 다른 잘못된 구성을 나타낼 수 있습니다. 이는 복제된 요청 실패와 지연 시간 증가로 이어질 수 있습니다. 리전 중단이 있음을 나타낼 수도 있습니다. [좋은 예](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)는 최근 평균이 180,000밀리초를 초과할 경우 알림을 생성하는 것입니다. `ReplicationLatency`가 0으로 떨어지는 것을 관찰할 수도 있습니다. 이는 복제가 중단되었음을 나타냅니다. + 각 글로벌 테이블에 충분한 최대 읽기 및 쓰기 설정을 할당합니다. + 리전 대피 사유를 미리 식별합니다. 결정에 사람의 판단이 수반되는 경우 모든 고려 사항을 문서화합니다. 이 작업은 압박을 받지 않는 상태에서 사전에 신중하게 수행해야 합니다. + 리전 대피 시 취해야 하는 모든 조치를 위한 런북을 유지 관리합니다. 일반적으로 글로벌 테이블에 필요한 작업은 거의 없지만 나머지 스택을 이동하는 작업은 복잡할 수 있습니다. **참고** 장애 조치 절차를 사용하는 경우 리전 장애 중에 일부 컨트롤 플레인 작업이 저하될 수 있으므로 데이터 플레인 작업에만 의존하고 컨트롤 플레인 작업에는 의존하지 않는 것이 모범 사례입니다. 자세한 내용은 AWS 블로그 게시물 [Build resilient applications with Amazon DynamoDB global tables: Part 4](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/)를 참조하세요. + 리전 대피를 포함하여 런북의 모든 측면을 정기적으로 테스트합니다. 테스트되지 않은 런북은 신뢰할 수 없는 런북입니다. + [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)를 사용하여 전체 애플리케이션(글로벌 테이블 포함)의 복원력을 평가하는 방법을 고려합니다. Resilience Hub의 대시보드를 통해 전체 애플리케이션 포트폴리오 복원력 상태를 종합적으로 파악할 수 있습니다. + ARC 준비 상태 확인을 사용하여 애플리케이션의 현재 구성을 평가하고 모범 사례에서 벗어난 부분을 추적하는 것을 고려해 보세요. + Route 53 또는 Global Accelerator와 함께 사용할 상태 확인을 작성할 때 전체 데이터베이스 흐름을 포함하는 일련의 직접 호출을 수행합니다. DynamoDB 엔드포인트가 가동되었는지만 확인하도록 검사를 제한하면 AWS Identity and Access Management(IAM) 구성 오류, 코드 배포 문제, DynamoDB 외부 스택의 장애, 평균 읽기 또는 쓰기 지연 시간보다 높은 지연 시간 등과 같은 많은 장애 모드를 처리할 수 없습니다. ## 글로벌 테이블 배포에 대한 자주 묻는 질문(FAQ) **글로벌 테이블의 요금은 어떻게 되나요?** + 기존 DynamoDB 테이블에 대한 쓰기 작업 요금은 쓰기 용량 단위(WCU, 프로비저닝된 테이블의 경우) 또는 쓰기 요청 단위(WRU, 온디맨드 테이블의 경우)를 기준으로 합니다. 5KB 항목을 쓰면 5단위의 요금이 부과됩니다. 글로벌 테이블에 대한 쓰기 요금은 프로비저닝된 테이블의 경우 복제된 쓰기 용량 단위(rWCU) 또는 온디맨드 테이블의 경우 복제된 쓰기 요청 단위로 책정됩니다. rWCU 및 rWRU 요금은 WCU 및 WRU와 같습니다. + rWCU 및 rWRU 요금은 항목을 직접 쓰거나 복제를 통해 쓰는 모든 리전에서 발생합니다. 리전 간 데이터 전송 요금이 적용됩니다. + 글로벌 보조 인덱스(GSI)에 대한 쓰기 작업은 로컬 쓰기 작업으로 간주되며, 일반 쓰기 단위를 사용합니다. + 현재 rWCU 또는 rWRU에 대해 예약 용량을 사용할 수 없습니다. GSI가 쓰기 단위를 소비하는 테이블의 경우 WCU에 대해 예약 용량을 구매하는 것이 여전히 유리할 수 있습니다. + 글로벌 테이블에 새 리전을 추가하면 DynamoDB는 새 리전을 자동으로 부트스트랩하고, 테이블 복원과 마찬가지로 테이블의 GB 크기를 기준으로 요금을 청구합니다. 리전 간 데이터 전송 요금도 적용됩니다. **글로벌 테이블은 어떤 리전을 지원하나요?** [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)은 MREC 테이블에 대해 모든 AWS 리전을 지원하고 MRSC 테이블에 대해 다음 리전 세트를 지원합니다. + 미국 리전 세트: 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오리건) + EU 리전 세트: 유럽(아일랜드), 유럽(런던), 유럽(파리), 유럽(프랑크푸르트) + 아시아 태평양 리전 세트: 아시아 태평양(도쿄), 아시아 태평양(서울) 및 아시아 태평양(오사카). **글로벌 테이블에서는 GSI를 어떻게 처리하나요?** [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)에서는 한 리전에서 생성한 GSI가 다른 참여 리전에도 자동으로 생성되고 자동으로 백필됩니다. **글로벌 테이블의 복제를 중지하려면 어떻게 해야 하나요?** + 다른 테이블을 삭제하는 것과 같은 방식으로 복제본 테이블을 삭제할 수 있습니다. 글로벌 테이블을 삭제하면 해당 리전으로의 복제가 중지되고 해당 리전에 보관된 테이블 사본이 삭제됩니다. 하지만 테이블의 사본을 독립적 엔터티로 유지하는 동안에는 복제를 중지할 수 없으며 복제를 일시 중지할 수도 없습니다. + MRSC 테이블은 정확히 3개의 리전에 배포되어야 합니다. 복제본을 삭제하려면 MRSC 테이블이 로컬 테이블이 되도록 모든 복제본과 감시자를 삭제해야 합니다. **DynamoDB Streams는 글로벌 테이블과 어떻게 상호 작용하나요?** + 각 글로벌 테이블은 시작 위치에 관계없이 모든 쓰기 작업을 기반으로 독립적인 스트림을 생성합니다. 이 DynamoDB 스트림을 한 리전 또는 모든 리전에서 독립적으로 사용하도록 선택할 수 있습니다. 로컬 쓰기 작업은 처리하되 복제된 쓰기 작업은 처리하지 않으려는 경우 쓰기 리전을 식별하는 고유한 리전 속성을 각 항목에 추가할 수 있습니다. 그런 다음 Lambda 이벤트 필터를 사용하여 로컬 리전에서의 쓰기 작업만을 위한 Lambda 함수를 호출할 수 있습니다. 이렇게 하면 삽입 및 업데이트 작업에 도움이 되지만 삭제 작업에는 도움이 되지 않습니다. + 다중 리전 최종 일관성(MREC 테이블)을 위해 구성된 글로벌 테이블은 복제본 테이블의 DynamoDB 스트림에서 변경 사항을 읽고 해당 변경 사항을 다른 모든 복제본 테이블에 적용하여 변경 사항을 복제합니다. 따라서 DynamoDB는 MREC 글로벌 테이블의 모든 복제본에서 기본적으로 활성화되며 해당 복제본에서 비활성화할 수 없습니다. MREC 복제 프로세스는 단기간에 여러 변경 사항을 복제된 단일 쓰기 작업으로 결합할 수 있습니다. 따라서 각 복제본의 스트림에는 약간 다른 레코드가 포함될 수 있습니다. MREC 복제본의 DynamoDB Streams 레코드는 항상 항목별로 정렬되지만, 항목 간 정렬은 복제본마다 다를 수 있습니다. + 다중 리전 강력한 일관성(MRSC 테이블)을 위해 구성된 글로벌 테이블은 복제에 DynamoDB Streams를 사용하지 않으므로 이 기능은 MRSC 복제본에서 기본적으로 활성화되지 않습니다. MRSC 복제본에서 DynamoDB Streams를 활성화할 수 있습니다. MREC 복제본의 DynamoDB Streams 레코드는 모든 복제본에서 동일하며 항상 항목별로 정렬되지만, 항목 간 정렬은 복제본 사이에서 다를 수 있습니다. **글로벌 테이블은 트랜잭션을 어떻게 처리하나요?** + MRSC 테이블에서 트랜잭션 작업을 수행하면 오류가 발생합니다. + MREC 테이블에서 트랜잭션 작업은 쓰기 작업이 원래 이루어진 리전에서만 원자성, 일관성, 격리성 및 내구성(ACID) 보장을 제공합니다. 전역 테이블에서는 트랜잭션이 리전 간에 지원되지 않습니다. 예를 들어 미국 동부(오하이오) 및 미국 서부(오리건) 리전에 복제본이 있는 MREC 글로벌 테이블이 있고 미국 동부(오하이오)에서 `TransactWriteItems` 작업을 수행할 경우, 변경 내용이 복제될 때 미국 서부(오리건)에서 부분적으로 완료된 트랜잭션을 관찰할 수 있습니다. 변경 사항은 소스 리전에서 커밋된 이후에만 다른 리전에 복제됩니다. **글로벌 테이블은 DynamoDB Accelerator 캐시(DAX)와 어떻게 상호 작용하나요?** 글로벌 테이블은 DynamoDB를 직접 업데이트하여 DAX를 우회하므로 DAX는 오래된 데이터를 보유하고 있다는 사실을 인식하지 못합니다. DAX 캐시는 캐시의 TTL이 만료되는 경우에만 새로 고쳐집니다. **테이블의 태그가 전파되나요?** 아니요, 태그는 자동으로 전파되지 않습니다. **테이블을 모든 리전에 백업해야 하나요 아니면 한 리전에만 백업해야 하나요?** 대답은 백업의 목적에 따라 달라집니다. + 데이터 내구성을 보장하려는 경우 DynamoDB는 이미 그러한 보호 장치를 제공합니다. 이 서비스는 내구성을 보장합니다. + 기록 레코드의 스냅샷을 보관하려는 경우(예: 규정 요구 사항 충족) 한 리전에 백업하는 것으로 충분합니다. AWS Backup를 사용하여 백업을 추가 리전에 복사할 수 있습니다. + 실수로 삭제되거나 수정된 데이터를 복구하려면 한 리전에서 [DynamoDB 시점 복구(PITR)](PointInTimeRecovery_Howitworks.md)를 사용하세요. **을 사용하여 글로벌 테이블을 배포하려면 어떻게 해야 하나요?CloudFormation** + CloudFormation은 DynamoDB 테이블과 글로벌 테이블을 두 개의 개별 리소스인 `AWS::DynamoDB::Table`과 `AWS::DynamoDB::GlobalTable`로 나타냅니다. 한 가지 방법은 `GlobalTable` 구성을 사용하여 글로벌 테이블일 수 있는 모든 테이블을 생성하고, 처음에는 해당 테이블을 독립형 테이블로 유지하다가 나중에 필요에 따라 리전을 추가하는 것입니다. + CloudFormation에서 각 글로벌 테이블은 복제본 수에 관계없이 단일 리전에서 단일 스택에 의해 제어됩니다. 템플릿을 배포하면 CloudFormation은 단일 스택 작업의 일부로 모든 복제본을 생성하고 업데이트합니다. 동일한 [AWS::DynamoDB::GlobalTable](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 리소스를 여러 리전에 배포하면 안 됩니다. 이런 배포는 오류를 유발하며 지원되지 않습니다. 여러 리전에 애플리케이션 템플릿을 배포하는 경우 조건을 사용하여 단일 리전에서 `AWS::DynamoDB::GlobalTable` 리소스를 생성할 수 있습니다. 또는 `AWS::DynamoDB::GlobalTable` 리소스를 애플리케이션 스택과 별도의 스택에 정의하고 단일 리전에 배포되도록 선택할 수 있습니다. + 일반 테이블이 있고 이 테이블을 CloudFormation이 계속 관리하는 글로벌 테이블로 변환하려는 경우, 삭제 정책을 `Retain`으로 설정하고, 스택에서 테이블을 제거하고, 콘솔에서 테이블을 글로벌 테이블로 변환한 다음 글로벌 테이블을 스택에 새 리소스로 가져옵니다. 자세한 내용은 [AWS GitHub 리포지토리](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk)를 참조하세요. + 교차 계정 복제는 현재 지원되지 않습니다. ## 결론 및 리소스 DynamoDB 글로벌 테이블에는 제어 기능이 거의 없지만, 신중하게 고려해야 합니다. 쓰기 모드, 라우팅 모델, 대피 프로세스를 결정해야 합니다. 글로벌 상태 유지를 위해서는 모든 리전에서 애플리케이션을 계측하고 경로를 조정하거나 대피를 수행할 준비가 되어 있어야 합니다. 그러면 99.999% 가용성을 위해 설계된 전 세계에 분산된 데이터세트(지연 시간이 짧은 읽기 및 쓰기 작업 지원)의 이점을 활용할 수 있습니다. DynamoDB 글로벌 테이블에 대한 자세한 내용은 다음 리소스를 참조하세요. + [DynamoDB 문서화](https://docs.aws.amazon.com/dynamodb/) + [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) + [Readiness check in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html)(AWS 설명서) + [Route 53 라우팅 정책](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) + [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) + [DynamoDB 서비스 수준 계약](https://aws.amazon.com/dynamodb/sla/) + [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)(AWS 백서) + [Data resiliency design patterns with AWS](https://www.youtube.com/watch?v=7IA48SOX20c)(AWS re:Invent 2022 프레젠테이션) + [How Fidelity Investments and Reltio modernized with Amazon DynamoDB](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s)(AWS re:Invent 2022 프레젠테이션) + [Multi-Region design patterns and best practices](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s)(AWS re:Invent 2022 프레젠테이션) + [AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)(AWS 블로그 게시물) + [리전 고정을 사용하여 Amazon DynamoDB 글로벌 테이블의 항목에 대한 홈 리전 설정](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/)(AWS 블로그 게시물) + [Monitoring Amazon DynamoDB for operational awareness](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/)(AWS 블로그 게시물) + [Scaling DynamoDB: How partitions, hot keys, and split for heat impact performance](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)(AWS 블로그 게시물) + [Multi-Region strong consistency with DynamoDB global tables](https://www.youtube.com/watch?v=R-nTs8ZD8mA)(AWS re:Invent 2024 프레젠테이션)