Amazon Route 53

도메인을 한 엔드포인트에만 고정해 두면 장애가 났을 때 우회할 수 없고, 사용자 지역에 따라 다른 경로를 주기도 어렵습니다. DNS를 단순 주소록처럼만 쓰면 트래픽 제어를 가장 앞단에서 놓치게 됩니다.

초기에는 DNS가 도메인을 고정 IP에 매핑하는 정도면 충분했습니다. 서버가 한두 대였고, 장애가 나면 운영자가 레코드를 수동으로 바꿔도 괜찮았습니다. 멀티 리전 아키텍처가 보편화되면서 상황이 달라졌습니다. 리전 하나가 내려가면 운영자가 직접 DNS 레코드를 수정하고, TTL이 만료될 때까지 수십 분을 기다려야 했습니다. 그 사이 사용자는 죽은 엔드포인트로 계속 요청을 보냅니다. MTTR이 DNS 전파 시간에 묶이는 겁니다. 블루/그린 배포를 하려 해도 가중치를 수동으로 조절하고 확인하는 과정이 느렸고, 리전별 지연 시간 차이를 DNS 수준에서 반영할 방법도 마땅치 않았습니다. 이런 운영 압력이 쌓이면서, 헬스 체크 결과에 따라 라우팅을 자동으로 전환하고 지연 시간·지리·가중치 같은 정책을 DNS 계층에서 직접 제어하는 서비스가 필요해졌습니다. Route 53은 그 자리를 채웁니다.

Route 53의 핵심 구성은 호스티드 존(Hosted Zone)과 레코드입니다. 호스티드 존은 하나의 도메인(예: example.com)에 대한 DNS 레코드를 모아 놓은 컨테이너입니다. 이 안에 A, CNAME, AAAA 같은 레코드를 만들어 도메인 이름을 실제 주소로 연결합니다. 별칭 레코드(Alias Record)는 Route 53 고유의 기능입니다. 일반 CNAME은 도메인 루트(example.com)에 쓸 수 없고 추가 DNS 쿼리 비용이 드는데, 별칭 레코드는 ELB, CloudFront, S3 같은 AWS 엔드포인트를 루트 도메인에도 직접 매핑하면서 쿼리 비용이 없습니다. 이 레코드들에 라우팅 정책을 결합합니다. 지연 시간 기반(latency)은 응답 시간이 가장 짧은 리전으로 보내고, 가중치 기반(weighted)은 설정한 비율대로 트래픽을 나눕니다. 장애 조치(failover)는 헬스 체크가 실패한 대상을 우회해 백업으로 자동 전환합니다.

Route 53과 CloudFront는 둘 다 사용자의 첫 요청에 관여하지만 계층이 다릅니다. Route 53은 DNS 응답으로 어디로 보낼지를 정하고, CloudFront는 실제 콘텐츠를 엣지에서 캐시해 전달합니다. 사용자를 어느 엔드포인트로 보낼지 결정하는 문제가 핵심이면 Route 53을 보고, 응답을 가까운 엣지에서 더 빠르게 전달하는 문제가 핵심이면 CloudFront를 보면 됩니다.

글로벌 서비스를 운영하면서 us-east-1과 ap-northeast-2에 같은 앱을 배포했다면, Route 53의 지연 시간 기반 라우팅으로 각 사용자를 응답이 빠른 리전으로 자동 연결할 수 있습니다. 한쪽 리전에 장애가 나면 헬스 체크가 실패를 감지하고, 장애 조치 정책이 정상 리전으로 트래픽을 넘깁니다. 운영자가 새벽에 깨서 레코드를 바꿀 필요가 없습니다. 블루/그린 배포에서도 가중치 기반 라우팅으로 새 버전에 10%만 먼저 보내고, 에러율을 확인한 뒤 점진적으로 올릴 수 있습니다. 별칭 레코드를 쓰면 ELB나 CloudFront의 엔드포인트가 바뀌어도 DNS 레코드를 따로 수정하지 않아도 됩니다. 단, DNS 캐시와 TTL 특성상 변경이 즉시 반영되지 않으므로 실시간 트래픽 전환이 필요한 경우에는 맞지 않습니다.