Section 9. Route 53

DNS

Domain Name System의 약자로 사람에게 친숙한 이름을 대상 IP 주소로 번역해 준다.
URL과 호스트 이름을 IP로 변환한다.

DNS에는 계층적 이름 구조가 있다.
.com
example.com
www.example.com
api.example.com

 

DNS 관련 용어

1. Domain Registrar | AMazon Route 53, GoDaddy
2. DNS Records | A, AAA, CNAME, NS...
3. Zone File | DNS 레코드를 포함한다.
4. Name Server | DNS 쿼리를 실제로 해결하는 서버이다.
5. Top Level Domain(TLD) | 최상위 도메인(ex. '.com')
6. Second Level Domain(SLD) | 두 번째 도메인

DNS 동작 방식

1. 공인 IP가 존재한다. example.com이라는 도메인 이름을 접근하려고 한다.
2. 로컬 DNS 서버에 접근하여 해당 도메인의 유무를 요청한다.
3. 본 적이 없다면 ICANN에 의해 관리된 DNS 서버의 루트에 물어볼 것이다. 그리고 유무에 대한 답을 로컬 DNS 서버에 전달한다.
4. 2~3의 방식을 반복하여 아래 계층의 DNS에 접근하여 도메인 이름을 계속해서 찾는다.

---

Amazon Route 53

Route 53은 고가용성, 확장성을 갖춘 완전리 관리되며 권한있는 DNS이다.

특징
사용자가 DNS에 대해 완전히 제어할 수 있다.
리소스의 상태를 확인할 수 있다.
100% SLA 가용성을 제공하는 유일한 AWS 서비스이다.

53이라 불리는 이유는 53이 전통적인 DNS 포트이기 때문이다.

 

Route 53 - Records

각 record가 포함하는 것:

• Domain/subdomain Name | ex. example.com
• Record Type | A, AAAA
• value | ex. 123.456.67.99
• Routing Policy | route 53이 쿼리에 반응하는 방법
• TTL | DNS resolver에 캐싱된 record가 살아있는 시간

Route 53 - Record Types

1. A | 호스트 이름과 IPv4 IP를 매핑한다.
2. AAAA | 호스트 이름과 IPv6 IP를 매핑한다.
3. CNAME | 호스트 이름을 다른 호스트 이름과 매핑한다. A나 AAAA가 될 수 있다.
4. NS | 호스팅 존의 이름 서버이다. 호스팅 존에 대한 DNS 쿼리에 응답할 수 있다.
   • 트래픽이 도메인으로 라우팅 되는 방식을 제어한다.

Route 53 - Hosted Zones

• 호스팅 존은 레코드의 컨테이너로 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다.
• 두 가지 방식의 호스팅 존
  1. Public Hosted Zones
     • 인터넷에 트래픽이 라우팅 되는 방식을 특정화하는 레코드를 포함한다.
  2. Private Hosted Zones
     • 공개되지 않는 도메인 이름을 지원한다.
     • 가상 private VPC만 URL을 해결할 수 있다.

 

Route 53 - Records TTL(Time To Live)

• TTL에 설정한 시간만큼 클라이언트에게 이 결과를 캐시하도록 요청할 수 있다.
• 만일 TTL을 24시간이라는 많은 시간으로 설정한다면 트래픽은 현저히 적어진다.
  • 클라이언트는 요청을 적게 보낼 것이지만 클라이언트가 오래된 레코드를 가질 수 있다.
  • 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 의미이다.
• 반대로 TTL을 60초라는 짧은 시간으로 설정한다면 트래픽의 양이 매우 많아져서 비용이 많이 들게 된다.
  • 오래된 레코드의 지속성은 짧아지므로 레코드의 변경이 빨라진다.

---

CNAME vs Alias

• AWS Resource(도메인)에 호스트 네임을 매핑하고 싶다면 두 가지 옵션이 있다.

1. CNAME | 호스트 네임을 다른 호스트 네임에 매핑한다.
   1. 루트 도메인이 아닌 경우에만 사용이 가능하다.
2. Alias | Route 53에 한정되지만 호스트 네임이 특정 AWS 리소스로 향하도록 할 수 있다.
   1. 별칭 레코드는 루트 및 비루트 도메인 모두에 작동한다.
   2. TTL을 설정할 수 없으며 Route 53에 의해 자동으로 설정된다.
   3. Zone Apex(서브 도메인이 붙지 않은 도메인)

Alias(별칭 레코드)의 대상

1. Elastic Load Balancer
2. CloudFront
3. API Gateway
4. Elastic Beanstalk
5. Route 53 Record 등등

주의할 점! EC2 DNS 이름은 별칭 레코드의 대상이 될 수 없다.

 

Route 53 - Routing Policies

• 라우팅 정책은 Route 53이 DNS 쿼리에 응답하는 것을 돕는다.
• 여기서의 라우팅은 로드 밸런서가 EC2 인스턴스로 라우팅하는 의미가 아닌, DNS의 관점을 의미한다.
  • DNS는 트래픽을 라우팅하지 않고, DNS 쿼리에만 반응한다.
• 라우팅 정책이 지원하는 것들:
  • 단순
    • 트래픽을 단일 리소스로 보내는 방식
    • 동일한 레코드에 여러 개의 값을 넣는 것도 가능하다.
    • 만일 여러 값이 반환되면, 무작위의 것이 클라이언트에 의해 선택된다.
    • 하지만 별칭을 사용한다면, 오로지 하나의 AWS 리소스만을 대상으로 지정한다.
    • 상태 확인은 불가능하다.
    
  • 가중치 기반
    • 가중치를 활용하여 특정 리소스로 보내는 식의 제어가 가능하다.
    • 각 레코드의 상대적 가중치는 해당 레코드로 트래픽을 얼마나 보낼지를 나타내는 값이다.
    • 상태 확인과 관련된다.
    • 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에 사용한다.
    • 만일 모든 레코드의 가중치가 0이라면 모든 레코드가 다시 동일한 가중치를 갖게 된다.
    
  • 장애 조치
  • 지연 시간 기반
    • 가장 짧은, 가까운 리소스로 리다이렉팅 하는 정책이다.
    • 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다.
    • 상태 확인과 관련되어 있다.
  • 지리적
    • 지연 시간 기반과는 다르게 사용자의 실제 위치를 기반으로 한다.
    • 가장 정확한 위치를 산정하여 그 IP로 라우팅 되는 것이다.
    • 일치하는 위치가 없다면 기본 레코드를 생성해야 한다.
  • 다중 값 응답
  • 지리 근접 라우팅 정책
    • 사용자와 리소스를 기반으로 트래픽을 리소스로 라우팅하도록 한다.
    • 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽으로 이동시킨다.
    • 지리적 위치를 변경하기 위해 필요한 편향값:
      • 더 많은 트래픽을 리소스에 전달하고 싶다면 편향값을 증가시켜 확장시킨다.
      • 리소스에 더 적은 트래픽을 전달하고 싶다면 편향값을 음수로 하여 축소시킨다.
    • 고급 Route 53 트래픽 플로우라는 기능을 사용한다.

즉, 지리 근접 라우팅은 편향값을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것이다.

 

1. Routing Policies - IP-based Routing

• 라우팅은 클라이언트의 IP 주소에 기반한다.
• Route 53에서 CIDR 목록을 정의하는데 이는 클라이언트의 IP 범위이다.
• 사용 시 성능을 향상시키고, 네트워크 비용을 절감할 수 있다.

2.  Routing Policies - Multi-Value

• 트래픽을 다중 리소스로 라우팅할 때 사용한다.
• Route 53은 다중 값과 리소스를 반환한다.
• 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있다.
• 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.(최대 100개의 IP 주소 반환)
• ELB를 대체할 수는 없다.
• 실행 시 Unhealthy의 결과는 제외하고 healthy인 레코드만 반환된다.

---

Route 53 - Health Checks

• HTTP Health Check는 공용 리소스에 대한 상태를 확인하는 방법이다.
• Health Checks는 오직 엔드포인트가 2xx와 3xx 상태 코드로 반응해야만 통과된다.

1. Health Checks - Public Hosted Zones

• 약 15개의 글로벌 health checks가 엔드포인트 health를 확인한다.
• Health Checks는 응답의 처음 5120 바이트의 텍스트에 근거하여 성공 or 실패할 수있다.
• 상태 확인의 작도이 가능하려면 상태 확인이 사용자의 어플리케이션이나 엔드 포인트에 접근이 가능해야 한다.
• 다음은 Health Checks를 확인하는 방법이다.

2. Health Checks - Private Hosted Zones

• 모든 Route53의 상태 확인이 VPC 외부에 있기 때문에 개인 엔드 포인트에 접근이 불가능하다.

---

 

Domain Registar vs. DNS Service

1. Domain Registar

• 도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있다.
• 매년 지불을 지불해야 한다.
• 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공한다.