글로벌 테이블을 사용한 리전 대피

리전 대피란 읽기 및 쓰기 활동을 해당 리전 외부로 마이그레이션하는 프로세스입니다. 대부분은 쓰기 활동이며 읽기 활동인 경우도 있습니다.

라이브 리전 대피

여러 이유로 라이브 리전 대피 결정을 내릴 수 있습니다. 대피는 follow-the-sun 한 리전에 쓰기 모드를 사용하는 경우처럼 일반적인 비즈니스 활동의 일부일 수 있습니다. DynamoDB 외부 소프트웨어 스택의 장애에 대응하여 현재 활성 리전을 변경하기로 하는 비즈니스 결정이나 리전 내에서 발생한 평소보다 긴 지연 시간 같은 일반적인 문제 때문에 대피가 이루어질 수도 있습니다.

임의의 리전에 쓰기 모드에서는 라이브 리전 대피가 간단합니다. 라우팅 시스템을 통해 트래픽을 대체 리전으로 라우팅하고, 대피된 리전에서 이미 이루어진 쓰기 작업을 평소처럼 복제할 수 있습니다.

한 리전에 쓰기 및 사용자 리전에 쓰기 모드에서는 새 활성 리전에서 쓰기를 시작하기 전에 활성 리전에 대한 모든 쓰기가 완전히 기록되고, 스트림이 처리되고, 전역으로 전파되었는지 확인해야 합니다. 이는 향후 쓰기가 최신 버전의 데이터를 기반으로 이루어지도록 하는 데 필요합니다.

리전 A는 활성이고 지역 B는 비활성이라고 가정해 보겠습니다(전체 테이블 또는 리전 A에 있는 항목의 경우). 대피를 수행하는 일반적인 메커니즘은 A에 대한 쓰기 작업을 일시 중지하고 이러한 작업이 B로 완전히 전파될 때까지 충분히 기다린 후 B를 활성으로 인식하도록 아키텍처 스택을 업데이트한 다음 B에 쓰기 작업을 재개하는 것입니다. 리전 A의 데이터가 리전 B에 완전히 복제되었음을 100% 확실하게 나타내는 지표는 없습니다. 리전 A가 정상인 경우 리전 A에 대한 쓰기 작업을 일시 중지하고 ReplicationLatency 지표의 최근 최대값의 10배를 기다리면 일반적으로 복제가 완료되었는지 확인하는 데 충분합니다. 리전 A가 비정상이고 다른 영역에서 지연 시간이 길어지면 대기 시간을 더 큰 배수로 설정할 수 있습니다.

오프라인 리전 대피

고려해야 할 특별한 경우가 있습니다. 리전 A가 예고 없이 완전히 오프라인 상태가 되면 어떻게 될까요? 그럴 가능성은 극히 낮지만 그래도 고려하는 것이 현명합니다. 이런 경우에는 아직 전파되지 않은 리전 A의 모든 쓰기 작업은 보관되었다가 리전 A가 다시 온라인 상태가 된 후에 전파됩니다. 쓰기 작업은 손실되지 않지만 전파는 무기한 지연됩니다.

이 경우 어떻게 진행할지는 애플리케이션이 결정합니다. 비즈니스 연속성을 위해서는 새 기본 리전 B에 쓰기 작업을 계속해야 할 수도 있습니다. 하지만 리전 A로부터 항목에 대한 쓰기 작업 전파가 보류 중인 동안 리전 B의 해당 항목이 업데이트를 수신하는 경우, 최종 쓰기 우선 모델에서는 전파가 억제됩니다. 리전 B에서의 모든 업데이트는 수신되는 쓰기 요청을 억제할 수 있습니다.

임의의 리전에 쓰기 모드에서는 리전 A의 항목이 결국 리전 B로 전파될 것으로 믿고 리전 A가 다시 온라인 상태가 될 때까지 항목이 누락될 가능성을 인식하면서 리전 B에서 읽기와 쓰기를 계속할 수 있습니다. 가능하면 최근 쓰기 트래픽을 재생(예: 업스트림 이벤트 소스 사용)하여 누락될 수 있는 쓰기 작업의 공백을 메우고, 최종 쓰기 우선 충돌 해결이 수신 쓰기 작업의 최종 전파를 억제하도록 하는 방법을 고려해야 합니다.

그 밖의 쓰기 모드에서는 살짝 최신에서 뒤떨어진 데이터로 작업을 계속할 수 있는 정도를 고려해야 합니다. ReplicationLatency로 추적되는 짧은 기간 동안의 일부 쓰기 작업은 리전 A가 다시 온라인 상태가 될 때까지 누락됩니다. 비즈니스를 계속 진행할 수 있을까요? 진행 가능한 사용 사례도 있겠지만 추가 완화 메커니즘 없이는 가능하지 않을 수도 있습니다.

예를 들어 리전 장애 이후에도 중단 없이 사용 가능한 크레딧 잔액을 유지해야 한다고 가정해 보겠습니다. 잔액을 리전 A에 있는 항목과 리전 B에 있는 항목으로 둘로 나누고 각 항목이 사용 가능한 잔액의 절반으로 시작하도록 할 수 있습니다. 이렇게 하면 사용자 리전에 쓰기 모드를 사용하는 것입니다. 각 리전에서 처리되는 트랜잭션 업데이트는 잔액의 로컬 사본에 기록됩니다. 리전 A가 완전히 오프라인 상태가 되더라도 리전 B에서 트랜잭션 처리를 계속 진행할 수 있으며, 쓰기 작업은 리전 B에 보관된 잔액 부분으로만 제한됩니다. 이렇게 잔액을 분할하면 잔액이 낮아지거나 크레딧을 재조정해야 할 때 복잡성이 발생하지만, 보류 중인 쓰기 작업에 불확실성이 있더라도 비즈니스를 안전하게 복구할 수 있는 한 가지 예가 됩니다.

또 다른 예로 웹 양식 데이터를 캡처하는 경우를 가정해 보겠습니다. OCC(낙관적 동시성 제어)를 사용하여 데이터 항목에 버전을 할당하고 최신 버전을 웹 양식에 숨겨진 필드로 포함할 수 있습니다. 제출할 때마다 데이터베이스에 있는 버전이 양식의 작성 기준 버전과 일치하는 경우에만 쓰기 작업이 성공합니다. 버전이 일치하지 않는 경우 데이터베이스에 있는 현재 버전을 기반으로 웹 양식을 새로 고치거나 신중하게 병합할 수 있고, 사용자는 다시 진행할 수 있습니다. OCC 모델은 일반적으로 다른 클라이언트가 데이터를 덮어쓰고 새 버전의 데이터를 생성하지 못하도록 보호하지만, 클라이언트가 이전 버전의 데이터를 발견할 수 있는 장애 조치 중에도 도움이 될 수 있습니다.

타임스탬프를 버전으로 사용하고 있다고 가정해 보겠습니다. 양식이 12:00에 리전 A를 기준으로 처음 작성되었지만 장애 조치 이후 리전 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에 대한 쓰기)를 받아들일 용의가 있었고, 다행히도 계정 상태를 간략하게 요약할 수 있는 데이터 모델이 있었습니다.