DynamoDB 글로벌 테이블을 사용한 쓰기 모드

글로벌 테이블은 테이블 수준에서 항상 액티브-액티브입니다. 그러나 특히 MREC 테이블의 경우 쓰기 요청을 라우팅하는 방법을 제어하여 이를 액티브-패시브로 처리할 수도 있습니다. 예를 들어 MREC 테이블에서 발생할 수 있는 잠재적 쓰기 충돌을 방지하기 위해 쓰기 요청을 단일 리전으로 라우팅하기로 결정할 수 있습니다.

다음 세 개의 섹션에서 설명한 대로 세 가지 기본 관리형 쓰기 패턴이 있습니다. 어떤 쓰기 패턴이 사용 사례에 적합한지 고려해야 합니다. 이 선택은 요청 라우팅, 리전 대피, 재해 복구 처리 방법에 영향을 미칩니다. 이후 섹션의 지침은 애플리케이션의 쓰기 모드에 따라 다릅니다.

임의의 리전에 쓰기 모드(기본 리전 없음)

다음 다이어그램에 나온 임의의 리전에 쓰기 모드는 완전한 액티브-액티브이며, 쓰기가 발생할 수 있는 위치에 제한을 두지 않습니다. 어느 리전이나 언제든지 쓰기를 수락할 수 있습니다. 가장 간단한 모드이지만 일부 유형의 애플리케이션에서만 사용할 수 있습니다. 이 모드는 모든 MRSC 테이블에 적합합니다. 또한 모든 라이터가 멱등적이고 따라서 안전하게 반복할 수 있어 여러 리전에서 동시 또는 반복 쓰기 작업이 충돌하지 않는 MREC 테이블에 적합합니다. 사용자가 연락처 데이터를 업데이트하는 경우를 예로 들 수 있습니다. 이 모드는 모든 쓰기가 결정적 프라이머리 키 아래의 고유한 삽입인 멱등적 추가 전용 데이터 세트 같은 특수한 경우에도 효과적입니다. 마지막으로 이 모드는 쓰기 충돌 위험이 허용 가능한 수준인 MREC에 적합합니다.

임의의 리전에 쓰기 모드는 가장 간단하게 구현할 수 있는 아키텍처입니다. 어느 리전이나 언제든지 쓰기 대상이 될 수 있으므로 라우팅이 더 쉽습니다. MRSC 테이블에서는 항목이 항상 동기화되고 MRSC 테이블에서는 최근 쓰기를 보조 리전에 원하는 횟수만큼 재생할 수 있으므로 장애 조치가 더 쉽습니다. 가능하면 이 쓰기 모드에 맞춰 설계해야 합니다.

예를 들어 여러 비디오 스트리밍 서비스에서 북마크, 리뷰, 시청 상태 플래그 등을 추적하기 위해 글로벌 테이블을 사용합니다. 이러한 배포는 MREC 테이블을 사용합니다. 전 세계에 분산된 복제본이 필요하기 때문입니다. 이때 각 복제본은 지연 시간이 짧은 읽기 및 쓰기 작업을 제공합니다. 이러한 배포는 모든 쓰기 작업이 멱등성을 유지하는 한 임의의 리전에 쓰기 모드를 사용할 수 있습니다. 이는 새로운 최신 타임 코드 설정, 새 검토 할당 또는 새 감시 상태 설정과 같은 모든 업데이트가 사용자의 새 상태를 직접 할당하고 항목에 대한 올바른 다음 값이 현재 값에 의존하지 않는 경우가 이에 해당됩니다. 혹시 사용자의 쓰기 요청이 다른 리전으로 라우팅되는 경우 마지막 쓰기 작업이 지속되고 글로벌 상태는 마지막 할당에 따라 결정됩니다. 이 모드에서 읽기 작업은 최신 ReplicationLatency 값만큼 지연된 후 최종적으로 일관됩니다.

또 다른 예로 한 금융 서비스 회사는 시스템의 일부로 글로벌 테이블을 사용하여 각 고객의 직불 카드 구매 현황을 지속적으로 집계하여 해당 고객의 캐시백 보상을 계산합니다. 고객당 RunningBalance 항목을 유지하려고 합니다. 이 쓰기 모드는 당연히 멱등성을 지원하지 않습니다. 트랜잭션이 스트리밍되면 새 올바른 값이 현재 값에 따라 달라지는 ADD 표현식을 사용하여 밸런스를 수정하기 때문입니다. 모든 ADD 직접 호출은 항상 항목의 최신 값에서 작동하므로 MRSC 테이블을 사용하면 계속 임의의 리전에 쓸 수 있습니다.

세 번째 예제에는 온라인 광고 배치 서비스를 제공하는 회사와 관련이 있습니다. 이 회사는 임의의 리전에 쓰기 모드의 설계 단순화를 위해 낮은 데이터 손실 위험을 감수할 수 있다고 결정했습니다. 회사에서 광고를 게재하는 경우 어떤 광고를 표시할지 결정하기 위해 충분한 메타데이터를 검색하고 사용자에게 동일한 광고가 반복되지 않도록 광고 노출을 기록하는 데 몇 밀리초밖에 걸리지 않습니다. 글로벌 테이블을 사용하면 전 세계 최종 사용자의 읽기 지연 시간과 쓰기 지연 시간 모두 짧아질 수 있습니다. 단일 항목으로 사용자의 모든 광고 노출을 기록하며, 이 항목을 확장되는 목록으로 표시할 수 있습니다. 항목 컬렉션에 추가하는 대신 하나의 항목을 사용합니다. 그러면 삭제 작업에 대한 비용을 지불하지 않고도 각 쓰기의 일부로 오래된 광고 노출을 제거할 수 있습니다. 이 쓰기 작업은 멱등성을 지원하지 않습니다. 따라서 동일한 최종 사용자가 거의 동시에 여러 리전에서 게재되는 광고를 보는 경우 한 광고 노출에 대한 하나의 쓰기 작업이 다른 작업을 덮어쓸 가능성이 있습니다. 이 경우 사용자가 광고를 가끔씩 한 번만 보게 되는 위험이 존재합니다. 이 정도 수준은 허용 가능하다고 결정했습니다.

한 리전에 쓰기(단일 기본)

다음 다이어그램에 표시된 한 리전에 쓰기와 같은 모드는 액티브-패시브이며 모든 테이블 쓰기를 단일 활성 리전으로 라우팅합니다. 참고로 DynamoDB에는 단일 활성 리전이라는 개념이 없습니다. DynamoDB 외부의 애플리케이션 라우팅이 이를 관리합니다. 한 리전에 쓰기 모드는 한 번에 한 리전으로만 쓰기 작업을 전달하도록 보장하여 쓰기 충돌을 방지해야 하는 MREC 테이블에 적합합니다. 이 쓰기 모드는 조건식을 사용하려고 하지만 어떤 이유로든 MRSC를 사용할 수 없는 경우 또는 트랜잭션을 수행해야 하는 경우에 도움이 됩니다. 최신 데이터와 반대되는 작업을 수행하고 있음을 인식하지 못하면 이러한 표현식은 불가능합니다. 따라서 모든 쓰기 요청을 최신 데이터를 보유한 단일 리전으로 전송해야 합니다.

MRSC 테이블을 사용하는 경우 편의를 위해 일반적으로 한 리전에 쓰도록 선택할 수 있습니다. 예를 들어 이를 통해 DynamoDB 이외의 인프라 빌드를 최소화할 수 있습니다. MRSC를 사용하면 충돌 해결(이 경우 MREC 테이블이 한 리전에 쓰기를 선택하게 됨)을 걱정하지 않고도 언제든지 임의의 리전에 안전하게 쓸 수 있으므로 쓰기 모드는 여전히 임의의 리전에 쓰기를 지원할 수 있습니다.

최종 읽기 일관성은 지연 시간을 줄이기 위해 어떤 복제본 리전으로도 갈 수 있습니다. 강력하게 일관된 읽기는 단일 기본 리전으로 가야 합니다.

리전 장애에 대응하여 활성 리전을 변경해야 하는 경우가 있습니다. 일부 고객은 해바라기(follow-the-sun) 배포 구현과 같이 정기적인 일정에 따라 현재 활성 리전을 변경합니다. 그러면 활동이 가장 많은 지역(이름에서 알 수 있듯이 보통 주간) 근처에 활성 리전을 배치하고, 따라서 읽기 및 쓰기 작업이 지연 시간이 가장 짧습니다. 또한 매일 리전을 변경하는 코드를 직접 호출하면 부가적인 이점도 있습니다. 이를 통해 재해 복구 전에 테스트가 제대로 수행될 수 있습니다.

비활성 리전은 DynamoDB 주위에 다운스케일된 인프라 세트를 유지할 수 있으며, 이 인프라는 활성 리전이 될 경우에만 구축됩니다. 이 가이드에서는 파일럿 라이트 및 예열 대기 방식 설계를 다루지 않습니다. 자세한 내용은 AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이를 참조하세요.

지연 시간이 짧은 글로벌 분산 읽기 작업에 글로벌 테이블을 사용하는 경우 한 리전에 쓰기 모드가 적합합니다. 예를 들어 전 세계 모든 리전에서 동일한 참조 데이터를 사용할 수 있어야 하는 대규모 소셜 미디어 회사가 있습니다. 데이터를 자주 업데이트하지는 않지만 업데이트할 때는 잠재적 쓰기 충돌을 방지하기 위해 한 리전에만 씁니다. 읽기 작업은 항상 임의의 리전에서 허용됩니다.

또 다른 예로 앞서 나온 금융 서비스 회사에서 일일 캐시백 계산을 구현한 사례를 살펴보겠습니다. 이 회사는 잔액을 계산할 때 임의의 리전에 쓰기 모드를 사용하지만 지급액을 추적할 때는 한 리전에 쓰기 모드를 사용합니다. 이 작업에는 MRSC 테이블에서 지원되지 않는 트랜잭션이 필요하므로 별도의 MREC 테이블과 한 리전 모드에 쓰기 모드에 더 적합합니다.

사용자 리전에 쓰기(혼합 기본)

다음 다이어그램에 표시된 사용자 리전에 쓰기 모드는 MREC 테이블에서 작동합니다. 서로 다른 홈 리전에 서로 다른 데이터 하위 세트를 할당하고 홈 리전을 통해서만 항목에 대한 쓰기 작업을 허용합니다. 이 모드는 액티브-패시브이지만 항목을 기반으로 활성 리전을 할당합니다. 모든 리전은 중복되지 않는 자체 데이터세트에서 기본 리전에 해당하며, 적절한 위치를 보장하기 위해 쓰기 작업을 보호해야 합니다.

이 모드는 각 최종 사용자에 연결된 데이터를 해당 사용자와 더 가까운 네트워크에 배치할 수 있으므로 쓰기 작업 지연 시간을 줄일 수 있다는 점을 제외하면 한 리전에 쓰기 모드와 비슷합니다. 또한 리전 사이에서 주변 인프라가 더 균등하게 분산되며, 모든 리전에 인프라의 일부가 이미 활성화되어 있기 때문에 장애 조치 시나리오 중에 인프라를 빌드하는 데 드는 작업이 줄어듭니다.

여러 방법으로 항목의 홈 리전을 확인할 수 있습니다.

예를 들어 게임 회사에서 일하고 있다고 가정합니다. 전 세계 모든 게이머의 읽기 및 쓰기 지연 시간이 짧아야 합니다. 각 게이머를 가장 가까운 리전에 할당합니다. 해당 리전에서 해당 게이머의 모든 읽기 및 쓰기 작업을 처리하므로 항상 강력한 쓰기 후 읽기 일관성이 유지됩니다. 하지만 해당 게이머가 여행 중이거나 홈 리전에서 중단이 발생하는 경우 대체 리전에서 전체 데이터 사본을 사용할 수 있으며, 게이머를 다른 홈 리전으로 할당할 수 있습니다.

또 다른 예로 화상 회의 회사에서 일하고 있다고 가정합니다. 각 전화 회의의 메타데이터는 특정 리전에 할당됩니다. 발신자는 가장 가까운 리전을 사용하여 지연 시간을 최소화할 수 있습니다. 리전 중단이 발생하는 경우 글로벌 테이블을 사용하면 시스템이 직접 호출의 처리를 이미 데이터의 복제된 사본이 있는 다른 리전으로 이동할 수 있으므로 빠른 복구가 가능합니다.