SECTION 10. Route 53

DNS

• 도메인 이름 시스템: 호스트 네임을 IP 주소로 변환함.
• www.google.com => 172.217.18.36
• DNS 레코드: A, AAAA, CNAME, NS
• Name Server: DNS 쿼리를 해결함.
• Top Level Domain(TLD): .com, .us, .in, .org
• Second Level Domain(SLD): amazon.com, google.com

DNS가 동작하는 방법

1. 웹 브라우저는 example. com 액세스 요청을 로컬 DNS 서버에 보냄

2. 캐시에 원하는 도메인의 IP 주소가 없는 경우, 로컬 DNS 서버는 루트 DNS 서버에 쿼리를 보내고, ".com" 도메인에 대한 최상위 도메인(TLD) 서버의 주소를 반환함.

3. 그 다음, TLD DNS 서버에 물어보고, "example.com" 도메인의 네임서버(NS) 주소가 반환됩니다.

4. 그 다음, SLD DNS 서버에 물어보고, "example.com" 도메인의 IP 주소가 반환됩니다.

5. 로컬 DNS 서버는 웹 브라우저에게 IP 주소를 응답하고, 웹 브라우저는 웹 서버에 접속하게 됨.

아마존 Route 53

• 아마존이 관리하는 DNS 웹 서비스
• 클라이언트가 라우트 53에 example.com에 접속을 요청하면, 루트 53은 클라이언트가 찾고 있는 IP를 전달함.
• EC2 인스턴스는 공용 IP만 가지고 있는데, DNS 기록을 루트 53에 기록함.
• 클라이언트는 EC2 인스턴스에 직접 연결 가능.
  

Record

• 특정 도메인으로 트래픽 경로를 정의
• 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의
• 각 레코드는 도메인과 서브 도메인 정보를 가짐
• 레코드 타입: e.g. A, AAAA, CNAME, NS
• 레코드 값: e.g., 123.456.789.123
• 라우팅 정책: Route53이 쿼리에 응답하는 방식
• TTL: DNS Resolver에 레코드가 캐싱되는 시간

레코드 타입

• A - 호스트 이름과 IPv4 Ip를 매핑함
• AAAA - 호스트이름과 IPv6 IP를 매핑
• CNAME
  - 호스트이름을 다른 호스트 이름과 매핑.
  - A나 AAAA 레코드가 될 수 있음
  - DNS 네임스페이스의 탑 노드에 대한 CNAME 레코드는 생성할 수 없다
  - 예시) example.com에 대한 CNAME은 만들 수 없지만 www.example.com에 대한 CNAME 레코드는 만들 수 있다
• NS
  - 호스팅 존의 네임서버로 서버의 DNS 이름 또는 ip주소로 호스팅 존에 대한 dns 쿼리 응답 가능
  - 트래픽이 도메인으로 라우팅 되는 방식을 제어

호스트 존

• 레코드의 컨테이너. 도메인과 그 하위 도메인으로 트래픽을 라우팅 하는 방법을 정의.

Public vs Private Hosted Zones

• 퍼블릭 호스트 존
  • 인터넷에서 트래픽을 라우팅하는 레코드를 포함.
  • 클라이언트로부터 쿼리에 응답 가능하고, IP주소를 반환함.
• 프라이빗 호스트 존
  • 하나 이상의 VPC 내에서 트래픽을 라우팅하는 레코드를 포함.
  • EC2 인스턴스가 액세스 요청하면, 사설 IP 주소를 반환함. 그리고 인스턴스가 다른 인스턴스에 연결할 수 있음.

레코드 TTL(Time To Live)

• 클라이언트가 루트53과 웹 서버에 액세스할 때
• High TTL, Low TTL

• High TTL (ex. 24 hr)
  Route 53에서의 트래픽이 적음
  레코드가 업데이트되지 않은 경우가 발생할 수 있음
• Low TTL (ex. 60 sec)
  Route 53에서의 트래픽이 많음 ($$)
  레코드가 업데이트되지 않은 기간이 짧음
  레코드를 쉽게 변경할 수 있음
• 엘라아스 레코드 제외하고, TTL은 모든 DNS 레코드에 필수적.

1. 클라이언트가 예를 들어 "myapp.example.com" 에 대해 DNS 요청.
2. 루트53으로부터 레코드 A라는 응답이 옴. 같이 온 TTL이 약 300초라고 할 때, 이 시간 동안 이 결과를 캐시해줌.
   -> 클라이언트가 다시 요청하거나 같은 호스트 이름에 접근하면 클라이언트는 DNS 시스템에서 쿼리를 발부하지 않음. 이미 답을 알고 있음.
3. 클라이언트는 갖고 있는 답을 이용해 웹 서버에 액세스해 HTTP를 요청하고 응답을 웹서버로부터 받음.

CNAME vs Alias 레코드

• CNAME: 호스트 네임이 다른 호스트 네임을 가리킴. 오직 NON ROOT 도메인 가능.
• Alias: 호스트 네임이 AWS 리소스를 가리킴. 루트 도메인과 논루트 도메인에서 모두 작동.

Routing Policies

1. Simlple

• 일반적으로 하나의 리소스에 대한 트래픽 경로를 보냄.
• 여러 값이 리턴될 때, 랜덤하게 하나가 클라이언트에 의해 선택됨.

2. Weighted

• 요청의 % 컨트롤해 각각의 특정 리소스에 보냄.
• 예를 들어, 루트53이 하나의 인스턴스에 70% 를 보냈다면, DNS 응답의 70%는 첫 번째 인스턴스로 리디렉션됨.
• 0을 레코드에 할당한다면, 그 리소스에 트래픽 보내는 것을 중단할 수 있음.
• 모든 레코드가 0을 가진다면 모든 레코드가 동등하게 반환될 것임.

3. Latency-based

• 대기시간은 유저와 AWS 리전 간의 트래픽에 기반함.
• 유저와 리전 거리가 멀면 리소스에 리다이렉트하는 대기시간 오래 걸림.

Route53- Health Checks

• HTTP 헬스 체크는 퍼블릭 리소스들에 대해서만 헬스 체크가 가능.

• 자동화된 DNS 장애조치

  • 엔드포인트를 모니터
  • 다른 헬스 체크를 모니터
  • 프라이빗 리소스를 모니터

1. 엔드포인트를 모니터

• 약 15개의 글로벌 헬스 체커들이 엔드포인트 헬스를 체크할 수 있음.
• 헬스 체커의 18% 이상이 해당 엔드포인트가 건강하다고 보고하면 루트 53은 그것을 건강하다고 고려함.
• 텍스트 기반 응답이라면 첫 5120 bytes 응답을 기반으로 pass/fail이 설정됨.
• 헬스 체커가 ALB에 HTTP 요청을 보내고, 이때 200(ok) 코드를 얻으면 리소스는 정상으로 간주된다.
• ALB(로드 밸런서)는 반드시 루트 53 헬스 체커 IP 주소 범위에서 오는 수신 요청을 허용해야 한다.

  Endpoint: 컴퓨터 네트워크에 연결되는 모든 장치

2. 계산된(합쳐진) 헬스 체커

• 여러 헬스 체크를 결과를 결합해 하나의 헬스 체커에 넣음.

• 부모 헬스 체커는 자식 헬스 체크에 의해 정의됨.

• 자식 헬스 체커가 EC2 인스턴스를 하나씩 모니터링함.

• 자식 헬스 체커 얼마나 많이 통과되었을 때 부모 헬스 체커를 패스로 만들지 지정함.

• 사용: 웹 사이트에 유지 관리를 위해 부모 헬스 체커를 확인하기 원할 때, 모든 건강 상태를 실패하게 하지 않음.
  

3. 프라이빗 호스트 존

• 개인 리소스 헬스를 모니터하기 (프라이빗 엔드포인트에는 접근할 수 없음)
• CloudWatch Metric을 생성하고 CloudWatch Alarm 을 할당함. 그리고 그 Alarm을 체크하는 헬스 체커를 생성함.
• EC2 인스턴스 상태를 프라이빗 서브넷에서 클라우드 워치 매트릭으로 모니터
  

Routing Policies

4. Failover

• 라우트 53이 Primary EC2 인스턴스를 헬스 체크했는데 비정상이라면, 자동으로 Secondary EC2 인스턴스에 연결(장애 조치)
• 클라이언트는 라우트 53에 DNS 요청을 보냈을 것이고, 헬스 체크 결과에 따라 Primary 또는 Secondary 리소스를 얻게 됨.

5. Geolocation

• user location에 따라 트래픽이 라우팅됨.
• Default 레코드를 만들어야 함.
• 예를 들어, 유럽에서 독일 사용자는 독일 버전 포함된 IP를 사용하고 프랑스 사용자도 이와 같은데, 만약 유럽 아닌 다른 곳에서는 Default 영어 버전 IP를 사용함.

6. Geoproximity

• bias(편향)에 따라 트래픽을 리소스로 옮길 수 있음.
• 먼저, 만약 us-west-1 리소스와 us-east-1 리소스가 있고 둘 다 bias가 0이라면, 미국 사용자는 사용자 위치 기반으로 반으로 나뉘어 왼쪽과 오른쪽 리소스를 사용할 것임.
• 그런데, 만약 us-east-1 리소스의 bias가 50이라면, 해당 리소스에 대해 더 많은 사용자의 트래픽을 만듦.

7. IP-based Routing

• 클라이언트의 IP 주소를 기반으로 라우팅함.
• CIDRs 리스트를 만들어야 함.
• CIDR 블록은 각각 IP 주소를 가지고, IP 주소마다 위치가 있음. 레코드는 Value(값)과 IP 기반 위치를 가짐. 그렇다면, 레코드는 해당 사이다 블록으로 값을 보내고 EC2 인스턴스가 그 값을 가지게 됨. -> 유저가 사이다 블록의 일부 IP를 가지고 들어오면, 그 IP 기반 위치의 레코드의 값을 가지는 EC2 인스턴스로 이동함.

  CIDR: 기존 네트워크 클래스로 나눠 정의하던 IP정보를 Class 없이 유연하게 나눠줄 수 있는 라우팅 기법

8. Muti-Value

• 트래픽을 다중 리소스로 트래픽할 때 사용
• 멀티 밸류 쿼리에 따라 정상 레코드가 8개까지 반환될 수 있음.
• ELB의 대체가 될 수는 없음.

  ELB: 엘라스틱 로드 밸런서. EC2 인스턴스, 컨테이너 및 IP 주소와 같은 여러 대상에 대해 수신 애플리케이션 또는 네트워크 트래픽을 여러 가용 영역에 배포함(부하분산)