Route 53에 대해 알아보자

(Stephane Maarek의 Udemy AWS Certified Solutions Architect Associate 강의를 참고했습니다.)

 

Amazon Route 53 작동 구조도

 

Amazon Route 53는 고가용성과 확장성을 제공하는 완전관리형의 권한 있는 DNS 서비스이다. 여기서 권한이 있다는 의미는 해당 도메인의 DNS 정보를 직접 관리하고 수정할 수 있는 DNS 서버를 의미한다. 즉, 사용자가 원하는 DNS 레코드를 자유롭게 추가하거나 변경할 수 있다. Route 53의 주요 기능은 도메인과 IP 주소를 연결하여 사용자가 올바른 서버로 접속하도록 DNS를 관리하고, 새로운 도메인 등록 및 관리를 도우며, 웹 서버가 정상적으로 동작하는지 헬스체크하는 역할을 수행한다.

 

그렇다면 DNS란 무엇일까? DNS는 인터넷의 전화번호부와 같은 역할을 수행하는 시스템이다. 우리가 웹사이트에 접속할 때 google.com, amazon.com과 같은 도메인 이름을 입력하지만, 실제 컴퓨터는 IP 주소를 이용해 통신한다. 이때 DNS는 도메인 이름을 IP 주소로 변환해주는 역할을 수행한다.

 

도메인 이름을 어떻게 처리할 것인지 정의하는 정보가 DNS Record이다. 각 Record에는 도메인 이름(Domain name)과 Record Type (A, AAAA, CNAME 등), Value (IP 주소 또는 다른 도메인), 트래픽을 어떻게 보낼지 결정하는 라우팅 정책, 그리고 DNS 캐시 유지 시간을 의미하는 TTL을 포함한다. 주요 DNS Record 종류는 다음과 같다.

• A Record: 도메인을 IPv4 주소와 연결
• AAAA Record: 도메인을 IPv6 주소와 연결
• CNAME Record: 하나의 도메인을 다른 도메인 이름으로 연결하며, Root Domain은 불가능
• NS Record: 이 도메인의 DNS를 관리하는 Name Server를 알려주는 역할

Hosted Zone

 

Hosted Zone은 특정 도메인의 DNS 레코드를 저장하는 공간이다. Route 53에서는 인터넷에서 누구나 접근 가능한 도메인을 관리하는 Public Hosted Zone과 VPC 내부에서만 사용하는 도메인을 관리하는 Private Hosted Zone, 총 2가지의 Hosted Zone을 제공한다. Hosted Zone은 월 0.5USD의 비용이 청구된다.

 

TTL (Time To Live)은 DNS 조회 결과를 DNS Resolver가 캐시에 저장하는 시간을 의미한다. TTL 동안에는 DNS 서버에 다시 조회하지 않고 캐시에 저장된 정보를 사용하며, 시간이 만료되면 새로운 DNS 정보를 다시 조회한다. TTL을 길게 설정한 경우, DNS 조회 횟수가 줄어 응답 속도 향상과 DNS 서버 부하 감소의 효과를 볼 수 있지만, IP 주소나 DNS 레코드를 변경해도 변경 사항이 사용자에게 반영되는 데 시간이 오래 걸린다는 단점이 있다. 반대로, TTL이 짧다면 새로운 정보가 빨리 반영되고, 서버 이전이나 장애 조치 시 유리하지만, DNS 서버 부하의 증가를 감안해야 한다. Alias Record가 아닌 DNS 레코드에 대해서는 TTL이 필수다.

 

그렇다면, Alias Record는 무엇일까? Alias Record는 Route 53에서만 제공하는 Route 53 전용 DNS 레코드로, 도메인을 AWS 리소스에 직접 연결할 수 있는 기능이다. CNAME과 달리 Root Domain에서도 사용할 수 있다는 것이 특징이다. 또한 IP 주소 변경을 자동으로 관리하며, 내부적으로 A(IPv4) 또는 AAAA(IPv6) 레코드 형태로 동작한다. 앞서 살펴봤듯이, Alias Record는 AWS가 대상 리소스에 맞는 적절한 TTL을 자동으로 관리하기 때문에 TTL을 따로 설정할 수 없다.

※ Root Domain이란?

  도메인의 가장 기본이 되는 최상위 도메인 이름이다. 예를 들어, 'example.com' 이라는 도메인이 있다면 'www.example.com', 'api.example.com'이 서브도메인이다.

 

Alias Record를 사용할 수 있는 AWS 서비스는 다음과 같다. 참고로 EC2 인스턴스의 Public DNS 이름에는 Alias Record를 사용할 수 없다.

 

• Elastic Load Balancer (ALB/NLB)
• CloudFront Distribution
• API Gateway
• Elastic Beanstalk Environment
• S3 Static Website
• VPC Interface Endpoint
• Global Accelerator
• 같은 Hosted Zone 내의 다른 Route 53 레코드

Route 53은 헬스 체크, 즉 애플리케이션이나 서버가 정상 작동하는지 주기적으로 확인하는 기능을 제공한다. 헬스 체크의 목적은 장애가 발생한 리소스를 DNS 응답에서 제외하여 사용자에게 정상적인 서비스만 연결되도록 하는 것이다. Route 53은 세 가지 방식의 헬스 체크를 지원한다. 헬스 체크의 결과는 CloudWatch Metrics와 통합되어 자동 장애 대응, SNS 알림 전송 등에 사용된다.

• Endpoint 헬스 체크: 가장 일반적인 방식으로, 애플리케이션이나 서버와 같은 특정 엔드포인트 상태를 직접 확인한다. HTTP, HTTPS, TCP를 지원한다.
• Calculated 헬스 체크: 여러 개의 헬스 체크 결과를 하나의 헬스 체크로 결합하는 기능이다. 최대 256개의 자식 헬스 체크를 하나의 부모 헬스 체크로 묶을 수 있다. AND, OR, NOT 논리 연산을 지원하며, 최소 몇 개의 헬스 체크가 정상이어야 하는지도 설정 가능하다.
• CloudWatch Alarm 헬스 체크: Route 53이 직접 서버를 검사하는 것이 아니라 CloudWatch Alarm의 상태를 기반으로 헬스 체크를 수행하는 방식이다. 이 방식으로 인터넷에서 접근할 수 없는 VPC 내부(Private) 리소스나 온프레미스 서버에도 헬스 체크를 구성할 수 있다.

Route 53은 전 세계에 분산된 약 15개의 헬스 체커를 사용하여 엔드포인트를 검사한다. 각 헬스 체커가 독립적으로 엔드포인트에 요청을 보내고 그 결과를 종합하여 18%가 넘는 헬스 체커가 정상이라고 판단하면 정상이라고 판단한다. 헬스 체크 수행 주기는 직접 설정 가능하며, 기본값은 30초이고 최소 10초로 설정할 수 있다. 주기를 짧게 설정하면 장애를 더 빨리 감지할 수 있는 반면 비용이 증가한다. Healthy/Unhealth Threshold도 설정 가능하다. 몇 번 연속으로 성공 또는 실패해야 상태를 변경할지 결정하는 것으로 기본값은 3회이다. 헬스 체크는 기본적으로 HTTP 상태 코드가 2xx나 3xx를 만족해야 성공이다. 이외의 응답은 실패로 간주한다.

 

그렇다면 Route 53의 라우팅 정책에 대해 알아보자. Route 53은 라우팅 정책을 바탕으로 DNS 조회에 대해 어떤 DNS 레코드를 응답할지 결정한다. Route 53의 라우팅 정책으로는 Simple, Weighted, Latency-based, IP-based, Failover, Geolocation, Multi-Value Answer, Geoproximity가 있다. 이때, Route 53이 ELB와 다른 점은 트래픽을 전달하는 것이 아닌 어떤 IP 주소 또는 AWS 리소스로 접속해야 하는지를 알려주는 역할만 수행한다는 것이다.

 

우선, Simple Routing은 가장 기본적인 라우팅 방식으로, 하나의 리소스로 트래픽을 연결할 때 사용한다. 하나의 레코드에 여러 IP를 등록할 수도 있으며, 여러 IP를 반환하는 경우 클라이언트는 그중 하나를 무작위로 선택한다. Alias Record를 사용하는 경우, 하나의 AWS 리소스만 지정이 가능하다. 헬스 체크와 함께 사용할 수는 없다.

 

Weighted Routing은 여러 리소스에 트래픽을 지정한 비율만큼 분산하고 싶을 때 사용하는 정책이다. 각 DNS 레코드에 가중치를 부여하면, Route 53이 그 비율에 맞게 DNS 응답을 제공한다. 이때, 가중치의 합이 반드시 100일 필요는 없고, 가중치를 0으로 설정하면 해당 리소스로는 트래픽을 보내지 않는다. 단, 모든 레코드의 가중치가 0이면 모든 리소스에 동일 비율로 응답한다. 같은 이름과 같은 타입의 레코드에서만 사용이 가능하고, 헬스 체크도 함께 사용할 수 있다.

 

Latency-based Routing은 사용자와 가장 낮은 지연 시간을 가지는 AWS 리전으로 연결하는 정책이다. 물리적인 거리가 아닌 실제 네트워크 지연 시간을 따지기 때문에 가장 가까운 지역으로 연결되지는 않는다. 헬스 체크와 함께 사용할 수 있기 때문에 장애 발생 시 다른 리전으로 자동 전환하는 것이 가능하다.

 

Failover Routing은 고가용성을 구현하기 위해 장애 발생 시 자동으로 대체 리소스로 트래픽을 전환하는 방식이다. 평상시에 사용하는 주 서버(Primary)와 Primary에 장애 발생 시에 사용하는 백업 서버(Secondary)로 구성되며, Primary 서버가 정상일 때에는 모든 DNS 요청을 Primary 서버로 응답하다가 헬스 체크를 통해 Primary 서버의 장애 발생을 감지하면 Secondary 서버의 DNS 레코드로 대신 응답하도록 한다. 따라서 반드시 헬스 체크와 함께 사용된다.

 

Geolocation Routing은 사용자의 실제 지리적 위치를 기준으로 DNS 응답을 결정한다. 대륙, 국가, 주(State) 단위로 라우팅 정책을 설정할 수 있으며, 여러 규칙이 동시에 적용된다면 가장 구체적인 위치 정보가 우선 적용된다. 모든 사용자가 설정한 위치에 속하는 것은 아니므로 설정하지 않은 지역의 사용자는 어느 서버 주소를 반환할지에 대한 Default Record를 반드시 생성하는 것이 권장된다. 헬스 체크도 함께 사용 가능하다.

 

Geoproximity Routing은 사용자와 리소스의 지리적 거리를 기준으로 DNS 응답을 결정하는 라우팅 정책이다. 이 정책의 가장 큰 특징은 Bias를 이용해 특정 리소스로 더 많은 혹은 더 적은 트래픽을 보내도록 조정할 수 있다는 점이다. Positive Bias(+1~+99)는 리소스의 영향 범위를 확장하여 더 많은 사용자를 해당 리소스로 연결하며, Negative Bias(-1~-99)는 리소스의 영향 범위를 축소하여 해당 리소스로 전달되는 트래픽을 줄인다. AWS 리소스는 AWS 리전을 지정하여, 비AWS 리소스는 위도와 경도를 직접 지정하여 사용할 수 있다. Route 53 Traffic Flow 기능을 사용해야만 사용 가능한 정책이다.

 

IP-based Routing은 클라이언트의 IP 주소를 기준으로 DNS 응답을 결정하는 라우팅 정책이다. 관리자가 특정 IP 주소 범위(CIDR)와 해당 사용자가 접속할 리소스를 미리 매핑해 두면, Route 53은 DNS 조회를 요청한 클라이언트의 IP를 확인하여 알맞은 리소스를 응답한다. 예를 들어, '203.0.113.0/24' CIDR은 서울 서버로 접속하도록 매핑했다면, 해당 IP 대역에 속하는 '203.0.113.10' 사용자는 서울 서버의 주소가 반환되는 방식이다.

 

마지막으로 Multi-Value Routing은 하나의 DNS 조회에 대해 여러 개의 리소스를 동시에 반환하는 정책이다. 클라이언트는 반환된 IP 중 하나를 선택하여 서버에 접속한다. 헬스 체크와 함께 사용 가능하며, 최대 8개의 Healthy 레코드를 반환한다.

※ Domain Registrar

  Domain Registrar는 도메인을 등록하고 소유권을 관리하는 서비스로, 대표적으로 GoDaddy, Google Domains, Amazon Registrar 등이 있다. 도메인과 IP 주소를 연결하는 DNS 레코드를 관리하는 DNS Service와는 역할이 다르다.

  일반적으로 Domain Registrar는 도메인 등록뿐 아니라 기본적인 DNS 관리 기능도 함께 제공하지만, 두 기능을 모두 같은 서비스에서 사용할 필요는 없다. 예를 들어, 도메인은 GoDaddy에서 구매하고, DNS 관리는 Route 53에서 수행할 수 있다. Route 53에서 외부 도메인을 설정하기 위해서는 Route 53에서 해당 도메인의 Hosted Zone을 생성하고, 도메인을 구매한 Registrar의 관리 페이지에서 Name Server(NS) 레코드를 Route 53이 제공한 Name Server로 변경하면 된다.