기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
글로벌 테이블의 라우팅 전략
글로벌 테이블 배포에서 가장 복잡한 부분은 아마도 요청 라우팅 관리일 것입니다. 요청은 먼저 최종 사용자에서 출발하여 어떤 방식을 통해 선택 및 라우팅되는 리전으로 가야 합니다. 요청은 AWS Lambda 함수, 컨테이너 또는 Amazon Elastic Compute Cloud(Amazon EC2) 노드가 지원하는 로드 밸런서로 구성될 수 있는 컴퓨팅 계층을 포함하여 해당 리전의 일부 서비스 스택과 다른 데이터베이스를 비롯한 다른 서비스를 접합니다. 이 컴퓨팅 계층은 DynamoDB와 통신합니다. 해당 리전의 로컬 엔드포인트를 사용하여 이를 수행해야 합니다. 글로벌 테이블의 데이터는 다른 모든 참여 리전에 복제되며, 각 리전의 DynamoDB 테이블에는 비슷한 서비스 스택이 있습니다.
글로벌 테이블은 다양한 리전의 각 스택에 동일한 데이터의 로컬 사본을 제공합니다. 단일 리전의 단일 스택을 상정한 설계를 고려하여 로컬 DynamoDB 테이블에 문제가 생기면 보조 리전의 DynamoDB 엔드포인트에 원격 호출을 하는 방법을 예상할 수 있습니다. 이는 모범 사례가 아닙니다. 한 리전에서 DynamoDB로 인해 발생하는 문제(또는 스택의 다른 항목이나 DynamoDB에 의존하는 다른 서비스로 인해 발생할 가능성이 더 높음)가 있는 경우 처리를 위해 최종 사용자를 다른 리전으로 라우팅하고 다른 리전의 컴퓨팅 계층을 사용하는 것이 가장 좋습니다.이 계층은 로컬 DynamoDB 엔드포인트와 통신합니다. 이 접근 방식은 문제가 있는 리전 전체를 라우팅합니다. 복원력을 보장하려면 컴퓨팅 계층과 데이터 계층의 복제 등 여러 리전에서 복제해야 합니다.
처리를 위해 최종 사용자 요청을 리전으로 라우팅하는 방법에는 여러 가지가 있습니다. 올바른 선택은 쓰기 모드와 장애 조치 고려 사항에 따라 달라집니다. 이 섹션에서는 클라이언트 기반, 컴퓨팅 계층, Amazon Route 53 및의 네 가지 옵션에 대해 설명합니다 AWS Global Accelerator.
