글로벌 테이블을 사용한 요청 라우팅
글로벌 테이블 배포에서 가장 복잡한 부분은 아마도 요청 라우팅 관리일 것입니다. 요청은 먼저 최종 사용자에서 출발하여 어떤 방식을 통해 선택 및 라우팅되는 리전으로 가야 합니다. 요청은 AWS Lambda 함수, 컨테이너 또는 Amazon Elastic Compute Cloud(Amazon EC2) 노드가 지원하는 로드 밸런서와 다른 데이터베이스를 비롯한 기타 서비스로 구성된 컴퓨팅 계층을 포함한 해당 리전의 서비스 스택과 만나게 됩니다. 이 컴퓨팅 계층은 DynamoDB와 통신합니다. 그러려면 해당 리전의 로컬 엔드포인트를 사용해야 합니다. 글로벌 테이블의 데이터는 다른 모든 참여 리전에 복제되며, 각 리전의 DynamoDB 테이블에는 비슷한 서비스 스택이 있습니다.
글로벌 테이블은 다양한 리전의 각 스택에 동일한 데이터의 로컬 사본을 제공합니다. 단일 리전의 단일 스택을 상정한 설계를 고려하여 로컬 DynamoDB 테이블에 문제가 생기면 보조 리전의 DynamoDB 엔드포인트에 원격 호출을 하는 방법을 예상할 수 있습니다. 이것은 모범 사례가 아닙니다. 리전 간 이동과 관련된 지연 시간은 로컬 액세스보다 100배 더 길 수 있습니다. 5개의 요청이 오고가는 것은 로컬에서 수행할 때는 몇 밀리초가 걸리지만 전 세계를 가로지를 때는 몇 초가 걸릴 수 있습니다. 처리를 위해 최종 사용자를 다른 리전으로 라우팅하는 것이 더 좋습니다. 복원력을 보장하려면 컴퓨팅 계층과 데이터 계층의 복제를 통한 여러 리전에 걸친 복제가 필요합니다.
처리를 위해 최종 사용자 요청을 리전으로 라우팅하는 대체 기법은 매우 많습니다. 최적의 선택은 쓰기 모드와 장애 조치 고려 사항에 따라 달라집니다. 이 섹션에서는 클라이언트 기반, 컴퓨팅 계층, Route 53, Global Accelerator라는 네 가지 옵션에 대해 설명합니다.
클라이언트 기반 요청 라우팅
클라이언트 기반 요청 라우팅에서는 애플리케이션, JavaScript가 있는 웹 페이지, 또 다른 클라이언트 같은 최종 사용자 클라이언트가 유효한 애플리케이션 엔드포인트를 추적합니다. 이 경우에는 문자 그대로의 DynamoDB 엔드포인트가 아니라 Amazon API Gateway 같은 애플리케이션 엔드포인트입니다. 최종 사용자 클라이언트는 자체 내장 로직을 사용하여 통신할 리전을 선택합니다. 무작위 선택, 관찰된 최단 지연 시간, 관찰된 최고 대역폭 측정 또는 로컬에서 수행된 상태 확인을 기반으로 리전을 선택할 수 있습니다.
클라이언트 기반 요청 라우팅의 장점은 성능 저하가 감지될 경우 실제 공용 인터넷 트래픽 상황 등에 맞춰 리전을 전환할 수 있다는 것입니다. 클라이언트는 모든 잠재적 엔드포인트를 알고 있어야 하지만 새로운 리전 엔드포인트를 시작하는 경우는 드뭅니다.
임의의 리전에 쓰기 모드에서 클라이언트는 선호하는 엔드포인트를 일방적으로 선택할 수 있습니다. 한 리전에 대한 액세스가 손상되면 클라이언트는 다른 엔드포인트로 라우팅할 수 있습니다.
한 리전에 쓰기 모드에서 클라이언트는 쓰기를 현재 활성 리전으로 라우팅하는 메커니즘이 필요합니다. 이는 현재 어느 리전이 쓰기를 허용하고 있는지 경험적으로 테스트(쓰기 거부를 확인하고 대안으로 변경)하는 것처럼 기본적일 수도 있고, 글로벌 코디네이터를 호출하여 현재 애플리케이션 상태를 쿼리하는 것처럼 복잡할 수도 있습니다(이러한 요구 사항에 맞게 글로벌 상태를 유지하기 위해 5개 리전 쿼럼 기반 시스템을 제공하는 Route 53 애플리케이션 복구 컨트롤러(ARC) 라우팅 제어를 기반으로 구축될 수 있음). 클라이언트는 최종 일관성을 위해 읽기를 임의의 리전으로 보내도 되는지 아니면 강력한 일관성을 위해 활성 리전으로 라우팅해야 하는지 결정할 수 있습니다. 자세한 내용은 Route 53 작동 방식을 참조하세요.
사용자 리전에 쓰기 모드에서 클라이언트는 작업 중인 데이터 세트의 홈 리전을 결정해야 합니다. 예를 들어 클라이언트가 사용자 계정에 해당하고 각 사용자 계정에 홈 리전이 있는 경우, 클라이언트는 글로벌 로그인 시스템에 적절한 엔드포인트를 요청할 수 있습니다.
예를 들어 웹을 통한 사용자의 비즈니스 재무 관리를 지원하는 금융 서비스 회사는 사용자 리전에 쓰기 모드로 글로벌 테이블을 사용할 수 있습니다. 각 사용자는 중앙 서비스에 로그인해야 합니다. 이 서비스는 보안 인증 정보와 해당 보안 인증 정보가 작동하는 리전의 엔드포인트를 반환합니다. 보안 인증 정보는 짧은 기간 동안 유효합니다. 그 후 웹 페이지는 새 로그인을 자동으로 협상하여 사용자의 활동을 새 리전으로 리디렉션할 수 있는 기회를 제공합니다.
컴퓨팅 계층 요청 라우팅
컴퓨팅 계층 요청 라우팅의 경우, 컴퓨팅 계층에서 실행되는 코드가 요청을 로컬에서 처리할지, 다른 리전에서 실행되는 해당 코드의 사본에 전달할지 결정합니다. 한 리전에 쓰기 모드를 사용하면 컴퓨팅 계층은 리전이 활성 리전이 아님을 감지하고 로컬 읽기 작업을 허용하면서 모든 쓰기 작업을 다른 리전으로 전달할 수 있습니다. 이 컴퓨팅 계층 코드는 데이터 토폴로지 및 라우팅 규칙을 인식하고 어떤 리전이 어떤 데이터에 활성 상태인지 지정하는 최신 설정을 기반으로 이를 안정적으로 적용해야 합니다. 해당 리전 내의 외부 소프트웨어 스택은 마이크로서비스가 읽기 및 쓰기 요청을 어떻게 라우팅하는지 몰라도 됩니다. 강력한 설계에서 수신 리전은 자신이 쓰기 작업의 현재 기본 리전인지 여부를 확인합니다. 기본 리전이 아니라면 글로벌 상태를 수정해야 한다는 오류 메시지가 생성됩니다. 또한 기본 리전이 변경 중일 경우 수신 리전은 쓰기 작업을 잠시 버퍼링할 수 있습니다. 어떤 경우든 리전의 컴퓨팅 스택은 해당 로컬 DynamoDB 엔드포인트에만 쓰지만 컴퓨팅 스택은 서로 통신할 수 있습니다.
이 시나리오에서는 금융 서비스 회사가 follow-the-sun 단일 기본 모델을 사용한다고 가정해 보겠습니다. 이 회사는 이 라우팅 프로세스를 위한 시스템과 라이브러리를 사용합니다. 전체 시스템은 AWS의 ARC 라우팅 제어와 비슷하게 글로벌 상태를 유지 관리합니다. 이 회사는 글로벌 테이블을 사용하여 어느 리전이 기본 리전이고 다음 기본 리전 전환이 언제로 예약되어 있는지 추적합니다. 모든 읽기 및 쓰기 작업은 시스템에 맞게 조정되는 라이브러리를 거칩니다. 라이브러리를 통해 짧은 지연 시간으로 로컬에서 쓰기 작업을 수행할 수 있습니다. 쓰기 작업의 경우 애플리케이션은 로컬 리전이 현재 기본 리전인지 확인합니다. 현재 기본 리전인 경우 쓰기 작업이 직접 완료됩니다. 그렇지 않은 경우 라이브러리는 쓰기 작업을 현재 기본 리전에 있는 라이브러리로 전달합니다. 이 수신 라이브러리는 자신도 스스로를 기본 리전으로 간주한다는 것을 확인하고, 그렇지 않은 경우 글로벌 상태의 전파 지연을 나타내는 오류를 발생시킵니다. 이 접근 방식은 원격 DynamoDB 엔드포인트에 직접 쓰지 않으므로 검증에 도움이 됩니다.
Route 53 요청 라우팅
Application Recovery Controller(ARC)는 도메인 이름 서비스(DNS) 기술입니다. Route 53에서 클라이언트는 잘 알려진 DNS 도메인 이름을 조회하여 엔드포인트를 요청하고, Route 53은 가장 적절하다고 판단되는 리전 엔드포인트에 해당하는 IP 주소를 반환합니다. Route 53에는 적절한 리전을 결정하는 데 사용하는 라우팅 정책 목록이 있습니다. 또한 Route 53은 장애 조치 라우팅을 수행하여 상태 확인에 실패한 리전 외부로 트래픽을 라우팅할 수 있습니다.
임의의 리전에 쓰기 모드를 사용하거나 백엔드의 컴퓨팅 계층 요청 라우팅과 결합될 경우, 네트워크와 가장 가까운 리전 또는 지리적으로 가장 가까운 리전 또는 기타 선택 등 복잡한 내부 규칙에 기반하여 리전을 반환할 수 있는 전체 액세스 권한을 Route 53에 부여할 수 있습니다.
한 리전에 쓰기 모드를 사용하면 현재 활성 리전을 반환하도록 Route 53을 구성할 수 있습니다(Route 53 ARC 사용).
참고
클라이언트는 Route 53의 응답에 있는 IP 주소를 도메인 이름에 TTL(Time to Live) 설정으로 표시된 시간 동안 캐시합니다. TTL이 길수록 모든 클라이언트가 새 엔드포인트를 인식할 수 있는 Recovery Time Objective(RTO)가 연장됩니다. 일반적으로 장애 조치에는 60초 값을 사용합니다. 모든 소프트웨어가 DNS TTL 만료를 완벽하게 준수하는 것은 아닙니다.
사용자 리전에 쓰기 모드에서는 컴퓨팅 계층 요청 라우팅도 사용하지 않는 한 Route 53을 사용하지 않는 것이 가장 좋습니다.
Global Accelerator 요청 라우팅
클라이언트는 AWS Global Accelerator
Global Accelerator는 임의의 리전에 쓰기 모드를 사용하거나 백엔드의 컴퓨팅 계층 요청 라우팅과 결합할 경우 원활하게 작동합니다. 클라이언트는 가장 가까운 엣지 로케이션에 연결하며, 요청을 받는 리전에 신경 쓸 필요가 없습니다.
한 리전에 쓰기를 사용하는 경우 Global Accelerator 라우팅 규칙은 현재 활성 리전으로 요청을 보내야 합니다. 글로벌 시스템에서 활성 리전으로 간주되지 않는 리전의 장애를 인위적으로 보고하는 상태 확인을 사용할 수 있습니다. DNS와 마찬가지로 요청이 어느 리전에서나 올 수 있다면 대체 DNS 도메인 이름을 사용하여 읽기 요청을 라우팅할 수 있습니다.
사용자 리전에 쓰기 모드에서는 컴퓨팅 계층 요청 라우팅을 함께 사용하지 않는 한 Global Accelerator를 사용하지 않는 것이 가장 좋습니다.
