# 글로벌 테이블 버전 2017.11.29(레거시)
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
**Topics**
+ [전역 테이블: 작동 방식](globaltables_HowItWorks.md)
+ [전역 테이블 관리 모범 사례 및 요구 사항](globaltables_reqs_bestpractices.md)
+ [글로벌 테이블 생성(버전 2017.11.29)](globaltables.tutorial.md)
+ [전역 테이블 모니터링](globaltables_monitoring.md)
+ [전역 테이블에 IAM 사용](gt_IAM.md)
# 전역 테이블: 작동 방식
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
다음 단원에서는 Amazon DynamoDB의 전역 테이블에 대한 동작과 개념에 대해 설명합니다.
## 버전 2017.11.29(레거시)의 전역 테이블 개념
*전역 테이블*이란 하나의 AWS 계정에서 소유한 한 개 이상의 복제 테이블 모음입니다.
*복제 테이블*(줄여서 *복제본*이라고도 함)은 전역 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 전역 테이블은 AWS 리전당 한 개의 복제 테이블을 가질 수 있습니다.
다음은 전역 테이블을 만드는 방법을 개념적으로 간단히 설명한 것입니다.
1. AWS 리전에서 DynamoDB Streams를 활성화하여 일반 DynamoDB 테이블을 생성합니다.
1. 데이터를 복제하려는 다른 리전 모두에 대해 1단계를 반복합니다.
1. 생성한 테이블을 기반으로 DynamoDB 전역 테이블을 정의합니다.
AWS Management Console은 이러한 작업을 자동화하므로 전역 테이블을 빠르고 쉽게 만들 수 있습니다. 자세한 내용은 [글로벌 테이블 생성(버전 2017.11.29)](globaltables.tutorial.md) 섹션을 참조하세요.
생성된 DynamoDB 전역 테이블은 리전당 한 개씩 여러 개의 복제 테이블로 구성되며, DynamoDB는 이를 단일 단위로 처리합니다. 모든 복제본은 동일한 테이블 이름과 동일한 프라이머리 키 스키마를 갖습니다. 애플리케이션이 한 리전의 복제 테이블에 데이터를 쓰면 DynamoDB가 이 쓰기를 다른 AWS 리전에 있는 다른 복제 테이블에 자동으로 전파합니다.
**중요**
전역 테이블은 테이블 데이터를 동기화 상태로 유지하기 위해 모든 항목에 대한 다음 속성을 자동으로 만듭니다.
`aws:rep:deleting`
`aws:rep:updatetime`
`aws:rep:updateregion`
이 속성을 변경하거나 같은 이름의 속성을 생성해서는 안 됩니다.
복제본 테이블을 전역 테이블에 추가하여 추가 리전에서 사용할 수 있습니다. (이렇게 하려면 전역 테이블이 비어 있어야 합니다. 즉, 복제 테이블 중 어느 테이블에도 데이터가 없어야 합니다.)
전역 테이블에서 복제본 테이블을 제거할 수도 있습니다. 이렇게 하면 해당 테이블은 전역 테이블과 연결이 끊어집니다. 따라서 전역 테이블과 더 이상 상호 작용을 수행하지 않으며 전역 테이블과 데이터도 주고받지 않습니다.
**주의**
복제본을 제거하는 것은 원자 프로세스가 아님에 유의하세요. 일관된 동작과 알려진 상태인지 확인하려면 사전에 제거할 복제본에서 애플리케이션 쓰기 트래픽을 전환해 볼 수도 있습니다. 복제본을 제거한 후 모든 복제본 리전 엔드포인트에 복제본이 연결 해제된 것으로 표시될 때까지 기다렸다가 자체 격리된 리전 테이블에 추가 쓰기를 수행합니다.
## 일반적인 작업
글로벌 테이블에 대한 일반적인 작업은 다음과 같이 작동합니다.
일반 테이블과 마찬가지로 글로벌 테이블의 복제본 테이블을 삭제할 수 있습니다. 그러면 해당 리전으로의 복제가 중지되고 해당 리전에 보관된 테이블 복사본이 삭제됩니다. 복제를 분리할 수 없으며 테이블의 복사본이 독립 엔터티로 존재하도록 할 수 없습니다.
**참고**
새 리전을 시작하는 데 사용한 후 최소 24시간이 지나야 소스 테이블을 삭제할 수 있습니다. 너무 빨리 삭제하려고 하면 오류가 발생할 수 있습니다.
충돌은 애플리케이션이 서로 다른 리전에서 동시에 동일한 항목을 업데이트할 경우 발생합니다. 최종 일관성을 보장하기 위해 DynamoDB 글로벌 테이블은 '최종 쓰기 우선' 방법을 사용하여 동시 업데이트 간에 조정합니다. 모든 복제본은 최종 업데이트에 합의하며 모두 동일한 데이터를 갖는 상태가 됩니다.
**참고**
충돌을 방지하는 몇 가지 방법은 다음과 같습니다.
IAM 정책을 사용하여 한 리전의 테이블에 대한 쓰기만 허용합니다.
IAM 정책을 사용하여 사용자를 한 리전으로만 라우팅하고 다른 리전은 유휴 대기 상태로 유지하거나, 홀수 사용자를 한 리전으로, 짝수 사용자를 다른 리전으로 번갈아 라우팅합니다.
Bookmark = Bookmark \$1 1과 같은 멱등성이 없는 업데이트의 사용을 피하고 가급적 Bookmark=25와 같은 정적 업데이트를 사용합니다.
## 전역 테이블 모니터링
CloudWatch를 사용하여 `ReplicationLatency` 지표를 관찰할 수 있습니다. 이 지표는 한 복제 테이블에 대한 DynamoDB Streams에 나타나는 업데이트된 항목과 글로벌 테이블의 다른 복제본에 나타나는 항목 간의 경과 시간을 추적합니다. `ReplicationLatency`는 밀리초 단위로 표현되며, 모든 소스-리전 및 대상-리전 쌍에 대해 내보내집니다. 이 지표는 글로벌 테이블 v2에서 제공하는 유일한 CloudWatch 지표입니다.
발생하게 되는 지연 시간은 선택한 리전 간의 거리와 기타 변수에 따라 달라집니다. 리전에 대한 0.5초\$12.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는 해당 리전에서 보류 중인 쓰기 전파를 재개하여 다른 리전의 복제 테이블로 전파합니다. 다시 온라인 상태로 된 리전에 대한 다른 복제본 테이블의 쓰기 전파도 재개됩니다. 이전에 성공한 모든 쓰기 작업은 리전이 격리된 기간에 관계없이 결국 전파됩니다.
# 전역 테이블 관리 모범 사례 및 요구 사항
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
Amazon DynamoDB 전역 테이블을 사용하여 AWS 리전 간에 테이블 데이터를 복제할 수 있습니다. 전역 테이블의 복제본 테이블과 보조 인덱스의 쓰기 용량을 동일하게 설정해 데이터를 적절히 복제하는 것이 중요합니다.
**Topics**
+ [글로벌 테이블 버전](#globaltables_version.tables)
+ [새 복제본 테이블 추가 요구 사항](#globaltables_reqs_bestpractices.requirements)
+ [용량 관리 모범 사례 및 요구 사항](#globaltables_reqs_bestpractices.tables)
## 글로벌 테이블 버전
DynamoDB 글로벌 테이블에는 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)과 [글로벌 테이블 버전 2017.11.29(레거시)](globaltables.V1.md)의 두 가지 버전이 있습니다. 가능하면 글로벌 테이블 버전 2019.11.21(현재)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 글로벌 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [전역 테이블 업그레이드](V2globaltables_versions.md#upgrading-to-current-version) 섹션을 참조하세요.
## 새 복제본 테이블 추가 요구 사항
새 복제본 테이블을 전역 테이블에 추가하려면 다음 조건이 모두 충족되어야 합니다.
+ 테이블은 모든 다른 복제본과 동일한 파티션 키를 갖습니다.
+ 테이블에는 지정된 동일한 쓰기 용량 관리 설정이 있어야 합니다.
+ 테이블은 모든 다른 복제본과 동일한 이름을 갖습니다.
+ 테이블에는 DynamoDB Streams가 활성화되어야 하며, 스트림에 항목의 새 이미지와 이전 이미지가 모두 포함되어야 합니다.
+ 전역 테이블의 신규 또는 기존 복제본 테이블은 데이터를 포함할 수 없습니다.
글로벌 보조 인덱스가 지정되어 있으면, 다음 조건을 충족해야 합니다.
+ 글로벌 보조 인덱스의 이름이 같아야 합니다.
+ 전역 보조 인덱스의 파티션 키와 정렬 키(존재하는 경우)가 같아야 합니다.
**중요**
쓰기 용량 설정은 전역 테이블의 복제본 테이블과 해당 보조 인덱스에 대해 일관되게 설정해야 합니다. 전역 테이블에 대한 쓰기 용량 설정을 업데이트하려면 DynamoDB 콘솔이나 `UpdateGlobalTableSettings` API 작업을 사용하는 것이 좋습니다. `UpdateGlobalTableSettings`는 쓰기 용량 설정에 대한 변경 사항을 전역 테이블에 있는 모든 복제 테이블과 해당 보조 인덱스에 자동으로 적용합니다. `UpdateTable`, `RegisterScalableTarget` 및 `PutScalingPolicy` 작업을 사용할 경우 각 복제본 테이블과 해당 보조 인덱스에 개별적으로 변경 사항을 적용해야 합니다. 자세한 내용은 [Amazon DynamoDB API 참조](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/)의 [UpdateGlobalTableSettings](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateGlobalTableSettings.html)를 참조하세요.
프로비저닝된 쓰기 용량 설정을 관리하기 위해 Auto Scaling을 활성화하는 것이 좋습니다. 쓰기 용량 설정을 수동으로 관리하고 싶다면, 동일하게 복제한 WCU(쓰기 용량 단위)를 모든 복제본 테이블에 프로비저닝해야 합니다. 또한 여러 전역 테이블의 일치하는 보조 인덱스에 동일하게 복제한 WCU(쓰기 용량 단위)를 프로비저닝해야 합니다.
또한 적절한 AWS Identity and Access Management(IAM) 권한이 있어야 합니다. 자세한 내용은 [전역 테이블에 IAM 사용](gt_IAM.md) 섹션을 참조하세요.
## 용량 관리 모범 사례 및 요구 사항
DynamoDB에서 복제 테이블에 대한 용량 설정을 관리할 때 다음을 고려하세요.
### DynamoDB Auto Scaling 사용
프로비저닝된 모드를 사용하는 복제 테이블의 처리량 용량 설정을 관리하려면 DynamoDB Auto Scaling을 사용하는 것이 좋습니다. DynamoDB Auto Scaling은 실제 애플리케이션 워크로드를 기반으로 각 복제 테이블에 대한 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)를 자동으로 조정합니다. 자세한 내용은 [DynamoDB Auto Scaling을 사용하여 자동으로 처리량 용량 관리](AutoScaling.md) 섹션을 참조하세요.
AWS Management Console을 사용하여 복제본 테이블을 생성하는 경우, 각 복제본 테이블에 대해 RCU(읽기 용량 유닛) 및 WCU(쓰기 용량 유닛)를 관리하기 위한 기본 Auto Scaling 설정과 함께 Auto Scaling이 기본적으로 활성화됩니다.
DynamoDB 콘솔이나 `UpdateGlobalTableSettings` 호출을 사용하여 복제 테이블 또는 보조 인덱스에 대한 Auto Scaling 설정을 변경할 경우, 전역 테이블에 있는 모든 복제 테이블과 해당 보조 인덱스에 변경 사항이 자동으로 적용됩니다. 이러한 변경 사항이 기존 Auto Scaling 설정을 덮어씁니다. 따라서 전역 테이블에 있는 복제본 테이블과 보조 인덱스에 대해 할당된 쓰기 용량 설정이 일관되게 유지됩니다. `UpdateTable`, `RegisterScalableTarget`, `PutScalingPolicy` 호출 등을 사용할 경우 각 복제본 테이블과 해당 보조 인덱스에 개별적으로 변경 사항을 적용해야 합니다.
**참고**
Auto Scaling에서 애플리케이션의 용량 변경이 만족스럽지 않거나(예측할 수 없는 워크로드) 설정(최소값, 최대값 또는 사용률 임계값)을 구성하지 않으려면 온디맨드 모드를 사용하여 전역 테이블에 대한 용량을 관리할 수 있습니다. 자세한 내용은 [온디맨드 모드](capacity-mode.md#capacity-mode-on-demand) 섹션을 참조하세요.
전역 테이블에 대한 온디맨드 모드를 활성화한 경우 복제된 쓰기 요청 단위(rWCUs) 소비량이 rWCUs 프로비저닝 방법과 일치하게 됩니다. 예를 들어 두 추가 리전에 복제되는 로컬 테이블에 10번 쓸 경우 쓰기 요청 단위를 60회 사용하게 됩니다(10 \$1 10 \$1 10 = 30, 30 x 2 = 60). 사용된 60개의 쓰기 요청 단위에는 글로벌 테이블 버전 2017.11.29(레거시)에서 `aws:rep:deleting`, `aws:rep:updatetime` 및 `aws:rep:updateregion` 속성을 업데이트하는 데 사용된 추가 쓰기가 포함됩니다.
### 수동으로 용량 관리
DynamoDB Auto Scaling을 사용하지 않기로 결정하는 경우, 각 복제 테이블과 보조 인덱스에서 읽기 용량 설정과 쓰기 용량 설정을 수동으로 설정해야 합니다.
모든 복제본 테이블에 대해 각 리전에서 프로비저닝된 rWCU(복제된 쓰기 용량 단위)는 모든 리전에서 애플리케이션 쓰기에 필요한 총 rWCU 수에 2를 곱해야 합니다. 이는 로컬 리전에서 발생하는 애플리케이션 쓰기, 다른 리전에서 발생하는 복제된 애플리케이션 쓰기를 수용합니다. 예를 들어, 오하이오의 복제본 테이블의 초당 쓰기를 5건으로, 버지니아 북부 복제본 테이블의 초당 쓰기를 5건으로 설정하고 싶다면, 각 복제본 테이블에 20개 rWCU를 프로비저닝해야 합니다(5 \$1 5 = 10, 10 x 2 = 20).
전역 테이블에 대한 쓰기 용량 설정을 업데이트하려면 DynamoDB 콘솔이나 `UpdateGlobalTableSettings` API 작업을 사용하는 것이 좋습니다. `UpdateGlobalTableSettings`는 쓰기 용량 설정에 대한 변경 사항을 전역 테이블에 있는 모든 복제 테이블과 해당 보조 인덱스에 자동으로 적용합니다. `UpdateTable`, `RegisterScalableTarget` 및 `PutScalingPolicy` 작업을 사용할 경우 각 복제본 테이블과 해당 보조 인덱스에 개별적으로 변경 사항을 적용해야 합니다. 자세한 내용은 [Amazon DynamoDB API 참조](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/)를 확인하세요.
**참고**
DynamoDB의 전역 테이블에 대한 설정(`UpdateGlobalTableSettings`)을 업데이트하려면 `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy` 및 `application-autoscaling:DeregisterScalableTarget` 권한이 있어야 합니다. 자세한 내용은 [전역 테이블에 IAM 사용](gt_IAM.md) 섹션을 참조하세요.
# 글로벌 테이블 생성(버전 2017.11.29)
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
이 단원에서는 Amazon DynamoDB 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 전역 테이블을 생성하는 방법을 설명합니다.
**Topics**
+ [전역 테이블 생성(콘솔)](#creategt_console)
+ [전역 테이블 생성(AWS CLI)](#creategt_cli)
## 전역 테이블 생성(콘솔)
다음 단계에 따라 콘솔을 사용하여 전역 테이블을 생성합니다. 다음 예제에서는 미국 및 유럽의 복제본 테이블로 전역 테이블을 생성합니다.
1. [https://console.aws.amazon.com/dynamodb/home](https://console.aws.amazon.com/dynamodb/home)에서 DynamoDB 콘솔을 엽니다. 이 예제의 경우, us-east-2(미국 동부 오하이오) 리전을 선택합니다.
1. 콘솔 왼쪽의 탐색 창에서 **테이블**을 선택합니다.
1. **Create Table(테이블 생성)**을 선택합니다.
**테이블 이름**에 **Music**을(를) 입력합니다.
**기본 키**에 **Artist**를 입력합니다. **정렬 키 추가**를 선택하고 **SongTitle**를 입력합니다(**Artist**와 **SongTitle**은 모두 문자열이어야 함).
테이블을 생성하려면 [**Create**]를 선택합니다. 이 테이블은 새로운 전역 테이블에서 첫 번째 복제본 테이블 역할을 합니다. 이는 나중에 추가하는 다른 복제본 테이블의 프로토타입입니다.
1. **글로벌 테이블** 탭을 선택한 다음 **버전 2017.11.29(레거시) 복제본 생성**을 선택합니다.
![\[버전 2017.11.29(레거시) 복제본 생성 버튼을 보여주는 콘솔 스크린샷입니다.\]](http://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/images/GlobalTables-old.png)
1. **사용 가능한 복제 리전(Available replication Regions)** 드롭다운에서 **미국 서부(오레곤)(US West (Oregon)**를 선택합니다.
콘솔에서 선택한 리전에 이름이 동일한 테이블이 없는지 확인합니다. 이름이 동일한 테이블이 있는 경우 해당 리전에서 새 복제본 테이블을 생성하려면 먼저 기존 테이블을 삭제해야 합니다.
1. **복제본 생성(Create Replica)**을 선택합니다. 그러면 미국 서부(오레곤)에서 테이블 생성 프로세스가 시작됩니다.
선택한 테이블(그리고 다른 복제본 테이블)의 **전역 테이블** 탭에 해당 테이블이 여러 리전에 복제되었다는 메시지가 표시됩니다.
1. 이제 다른 리전을 추가하여 전역 테이블이 미국과 유럽에 걸쳐 복제되고 동기화되도록 합니다. 이렇게 하려면 5단계를 반복하되, 이번에는 **US West (Oregon)(미국 서부(오레곤))** 대신 **EU(프랑크푸르트)(EU (Frankfurt))**를 지정합니다.
1. 미국 동부(오하이오) 리전에서 AWS Management Console을 계속 사용해야 합니다. 왼쪽 탐색 메뉴의 **항목(Items)**에서 **음악(Music)** 테이블을 선택한 다음 **항목 만들기(Create Item)**를 선택합니다.
1. [**Artist**]에 **item\$11**를 입력합니다.
1. [**SongTitle**]에 **Song Value 1**를 입력합니다.
1. 해당 항목을 쓰려면 **항목 만들기(Create item)**를 선택합니다.
1. 잠시 후에 이 항목이 전역 테이블의 세 리전 모두에 복제됩니다. 제대로 되었는지 확인하려면 콘솔에서 오른쪽 상단 모서리에 있는 리전 선택기로 이동하고 **Europe (Frankfurt)(유럽(프랑크푸르트))**를 선택합니다. 유럽(프랑크푸르트)의 `Music` 테이블에 새 항목이 포함되어 있어야 합니다.
1. 9단계를 반복하고 **미국 서부(오레곤)(US West (Oregon))**을 선택하여 해당 리전의 복제를 확인합니다.
## 전역 테이블 생성(AWS CLI)
다음 단계에 따라 `Music`를 사용하여 AWS CLI 전역 테이블을 생성합니다. 다음 예제에서는 미국 및 유럽의 복제본 테이블로 전역 테이블을 생성합니다.
1. 미국 동부(오하이오)에서 DynamoDB Streams를 활성화하고(`NEW_AND_OLD_IMAGES`) 새 테이블(`Music`)을 생성합니다.
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region us-east-2
```
1. 동일한 `Music` 테이블을 미국 동부(버지니아 북부)에서 생성합니다.
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region us-east-1
```
1. `Music` 및 `us-east-2` 리전의 복제본 테이블로 구성된 전역 테이블(`us-east-1`)을 생성합니다.
```
aws dynamodb create-global-table \
--global-table-name Music \
--replication-group RegionName=us-east-2 RegionName=us-east-1 \
--region us-east-2
```
**참고**
전역 테이블 이름(`Music`)은 각 복제본 테이블의 이름(`Music`)과 일치해야 합니다. 자세한 내용은 [글로벌 테이블에 대한 모범 사례](globaltables-bestpractices.md) 섹션을 참조하세요.
1. 1단계 및 2단계에서 생성한 테이블과 동일한 설정을 사용하여 유럽(아일랜드)에 다른 테이블을 생성합니다.
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions \
AttributeName=Artist,AttributeType=S \
AttributeName=SongTitle,AttributeType=S \
--key-schema \
AttributeName=Artist,KeyType=HASH \
AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region eu-west-1
```
이 단계를 수행한 후에는 `Music` 전역 테이블에 새 테이블을 추가합니다.
```
aws dynamodb update-global-table \
--global-table-name Music \
--replica-updates 'Create={RegionName=eu-west-1}' \
--region us-east-2
```
1. 복제가 작동하는지 확인하려면 미국 동부(오하이오)의 `Music` 테이블에 새 항목을 추가합니다.
```
aws dynamodb put-item \
--table-name Music \
--item '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region us-east-2
```
1. 몇 초 기다린 후 항목이 미국 동부(버지니아 북부) 및 유럽(아일랜드)에 성공적으로 복제되었는지 확인합니다.
```
aws dynamodb get-item \
--table-name Music \
--key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region us-east-1
```
```
aws dynamodb get-item \
--table-name Music \
--key '{"Artist": {"S":"item_1"},"SongTitle": {"S":"Song Value 1"}}' \
--region eu-west-1
```
# 전역 테이블 모니터링
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
Amazon CloudWatch를 사용하여 전역 테이블의 동작과 성능을 모니터링할 수 있습니다. Amazon DynamoDB는 전역 테이블의 각 복제본에 대해 `ReplicationLatency` 및 `PendingReplicationCount` 지표를 게시합니다.
+ **`ReplicationLatency`** - 한 복제 테이블에 대한 DynamoDB Streams에 나타나는 업데이트된 항목과 전역 테이블의 다른 복제본에 나타나는 항목 간의 경과 시간입니다. `ReplicationLatency`는 밀리초 단위로 표현되며, 모든 원본 및 대상-리전 쌍에 대해 내보내집니다.
정상 작동 중에는 `ReplicationLatency`가 상당히 일정해야 합니다. `ReplicationLatency` 값이 상승하면 한 복제본의 업데이트 내용이 다른 복제본 테이블로 시기 적절하게 전파되지 않는다는 것을 나타낼 수 있습니다. 시간이 지날수록 다른 복제본 테이블이 더 이상 지속적으로 업데이트 내용을 받지 않기 때문에 *뒤처질* 수 있습니다. 이 경우에는 각 복제본 테이블에 대해 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)가 동일한지 확인해야 합니다. 또한 WCU 설정을 선택할 때 [글로벌 테이블 버전용량 관리 모범 사례 및 요구 사항](globaltables_reqs_bestpractices.md#globaltables_reqs_bestpractices.tables)의 권장 사항을 따라야 합니다.
`ReplicationLatency`는 AWS 리전의 성능이 저하되고 해당 리전에 복제 테이블이 있는 경우에 증가할 수 있습니다. 이 경우 애플리케이션의 읽기 및 쓰기 작업을 다른 AWS 리전으로 일시적으로 리디렉션할 수 있습니다.
+ **`PendingReplicationCount`** - 한 복제 테이블에 쓰여졌지만 전역 테이블의 다른 복제본에는 아직 쓰여지지 않은 항목 업데이트 수입니다. `PendingReplicationCount`는 항목 수로 표현되며, 모든 원본 및 대상-리전 쌍에 대해 내보내집니다.
정상 작동 중에는 `PendingReplicationCount`가 매우 작아야 합니다. `PendingReplicationCount`가 오랜 시간 동안 증가하면 복제본 테이블의 프로비저닝된 쓰기 용량 설정이 현재 워크로드에 충분한지 여부를 조사해야 합니다.
`PendingReplicationCount`는 AWS 리전의 성능이 저하되고 해당 리전에 복제 테이블이 있는 경우에 증가할 수 있습니다. 이 경우 애플리케이션의 읽기 및 쓰기 작업을 다른 AWS 리전으로 일시적으로 리디렉션할 수 있습니다.
자세한 내용은 [DynamoDB 지표 및 차원](metrics-dimensions.md) 섹션을 참조하세요.
# 전역 테이블에 IAM 사용
**중요**
이 설명서는 버전 2017.11.29(레거시)의 글로벌 테이블에 대한 것이므로 새 글로벌 테이블의 경우 사용하지 않아야 합니다. 가능하면 [글로벌 테이블 버전 2019.11.21(현재)](GlobalTables.md)을 사용해야 합니다. 이는 2017.11.29(레거시)보다 유연성과 효율성이 뛰어나고 쓰기 용량을 적게 소비합니다.
사용 중인 버전을 확인하려면 [글로벌 테이블 버전 확인](V2globaltables_versions.md#globaltables.DetermineVersion) 섹션을 참조하세요. 기존 전역 테이블을 버전 2017.11.29(레거시)에서 버전 2019.11.21(현재)로 업데이트하는 경우 [DynamoDB 글로벌 테이블 버전](V2globaltables_versions.md) 섹션을 참조하세요.
전역 테이블을 처음으로 생성하는 경우, Amazon DynamoDB는 사용자를 위한 AWS Identity and Access Management(IAM) 서비스 연결 역할을 자동으로 생성합니다. 이름이 [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBReplicationServiceRolePolicy)인 이 역할은 DynamoDB가 사용자를 대신하여 전역 테이블에 대한 교차 리전 복제를 관리하도록 허용합니다. 이 서비스 연결 역할을 삭제하지 마세요. 삭제하면 모든 전역 테이블이 더 이상 작동하지 않습니다.
서비스 연결 역할에 대한 자세한 내용은 *IAM 사용 설명서*의 [서비스 연결 역할 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)을 참조하세요
DynamoDB에서 전역 테이블을 생성하고 관리하려면 다음의 각 항목에 액세스할 수 있는 `dynamodb:CreateGlobalTable` 권한이 있어야 합니다.
+ 추가하려는 복제본 테이블.
+ 이미 전역 테이블의 요소인 각각의 기존 복제본.
+ 전역 테이블 자체.
DynamoDB의 전역 테이블에 대한 설정(`UpdateGlobalTableSettings`)을 업데이트하려면 `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy` 및 `application-autoscaling:DeregisterScalableTarget` 권한이 있어야 합니다.
기존 조정 정책을 업데이트할 때 `application-autoscaling:DeleteScalingPolicy` 및 `application-autoscaling:DeregisterScalableTarget` 권한이 필요합니다. 이렇게 하면 새로운 정책을 테이블이나 보조 인덱스에 연결하기 전에 전역 테이블 서비스가 기존의 조정 정책을 제거할 수 있습니다.
IAM 정책을 사용하여 하나의 복제 테이블에 대한 액세스 권한을 관리하는 경우, 해당 전역 테이블의 모든 다른 복제본에 동일한 정책을 적용해야 합니다. 이렇게 하면 모든 복제본 테이블에서 일관된 권한 모델을 유지할 수 있습니다.
전역 테이블의 모든 복제본에 동일한 IAM 정책을 사용함으로써, 전역 테이블 데이터에 대한 읽기 및 쓰기 액세스 권한을 의도치 않게 부여하는 것을 방지할 수도 있습니다. 예를 들어, 전역 테이블의 한 복제본에만 액세스할 수 있는 사용자를 고려합니다. 해당 사용자가 이 복제본에 쓸 수 있는 경우, DynamoDB는 다른 모든 복제 테이블에 쓰기를 전파합니다. 실제로 사용자는 전역 테이블의 모든 다른 복제본에 (간접적으로) 쓸 수 있습니다. 이 시나리오는 모든 복제본 테이블에 일관된 IAM 정책을 사용하여 방지할 수 있습니다.
## 예: CreateGlobalTable 작업 허용
전역 테이블에 복제본을 추가할 수 있으려면 전역 테이블과 해당하는 각 복제본 테이블에 대한 `dynamodb:CreateGlobalTable` 권한이 있어야 합니다.
다음 IAM 정책은 모든 테이블에서의 `CreateGlobalTable` 작업을 허용할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["dynamodb:CreateGlobalTable"],
"Resource": "*"
}
]
}
```
------
## 예: UpdateGlobalTable, DescribeLimits, application-autoscaling:DeleteScalingPolicy 및 application-autoscaling:DeregisterScalableTarget 작업 허용
DynamoDB의 전역 테이블에 대한 설정(`UpdateGlobalTableSettings`)을 업데이트하려면 `dynamodb:UpdateGlobalTable`, `dynamodb:DescribeLimits`, `application-autoscaling:DeleteScalingPolicy` 및 `application-autoscaling:DeregisterScalableTarget` 권한이 있어야 합니다.
다음 IAM 정책은 모든 테이블에서의 `UpdateGlobalTableSettings` 작업을 허용할 수 있는 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateGlobalTable",
"dynamodb:DescribeLimits",
"application-autoscaling:DeleteScalingPolicy",
"application-autoscaling:DeregisterScalableTarget"
],
"Resource": "*"
}
]
}
```
------
## 예: 특정 리전에만 허용된 복제본이 있는 특정 전역 테이블 이름에 대한 CreateGlobalTable 작업 허용
다음 IAM 정책은 2개의 리전에 복제본이 있는 `CreateGlobalTable`라는 글로벌 테이블을 생성하는 `Customers` 작업을 허용하기 위해 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:CreateGlobalTable",
"Resource": [
"arn:aws:dynamodb::123456789012:global-table/Customers",
"arn:aws:dynamodb:us-east-1:123456789012:table/Customers",
"arn:aws:dynamodb:us-west-1:123456789012:table/Customers"
]
}
]
}
```
------