한 회사가 us-east-1, eu-west-1, ap-southeast-1의 세 리전에 Amazon EC2 인스턴스를 사용하여 글로벌 온라인 게임을 출시합니다. 리더보드, 플레이어 인벤토리 및 이벤트 상태는 리전 전반에 걸쳐 사용 가능해야 합니다. 모든 리전은 모든 리전의 결합된 로드를 처리할 수 있도록 확장할 수 있어야 하며, 사용자는 가장 낮은 지연 시간을 가진 리전으로 자동으로 라우팅되어야 합니다. 다음 중 운영 오버헤드가 가장 적으면서 이러한 요구 사항을 충족하는 설계는 무엇입니까?

이 솔루션은 Auto Scaling 그룹을 사용하여 각 리전의 EC2 인스턴스에 대한 가용성과 확장성을 보장하고, Network Load Balancer(NLB)는 트래픽을 효율적으로 분산합니다. Route 53 지연 시간 기반 라우팅은 사용자를 가장 낮은 지연 시간을 가진 리전으로 자동 라우팅하여 사용자 경험을 최적화합니다. Amazon DynamoDB 글로벌 테이블은 리더보드, 플레이어 인벤토리 및 이벤트 상태와 같은 게임 메타데이터를 여러 리전에서 자동으로 복제하고 동기화하여 높은 가용성과 낮은 지연 시간을 제공하며 운영 오버헤드가 가장 적습니다. 다른 옵션들은 다음과 같은 이유로 최적이 아닙니다. 첫 번째 옵션은 Global Accelerator를 사용하지만, RDS MySQL의 읽기 복제본은 쓰기 작업에 대한 지연 시간 문제를 해결하지 못하고 DynamoDB 글로벌 테이블보다 운영 오버헤드가 더 큽니다. 두 번째 옵션은 Route 53 지리 근접 라우팅을 사용하는데, 이는 지연 시간 기반 라우팅보다 정확도가 떨어질 수 있으며, EC2 인스턴스에서 MySQL 복제를 수동으로 구성하는 것은 운영 오버헤드가 높습니다. 네 번째 옵션은 EC2 Global View와 사용자 지정 DNS 로직을 제안하는데, 이는 복잡하고 운영 오버헤드가 매우 높습니다. Aurora 글로벌 데이터베이스는 좋지만, 사용자 지정 DNS 로직의 복잡성 때문에 이 옵션은 최적이 아닙니다.