[AWS] aws 강의 섹션 9 (DNS 란?, Route 53이란? DNS 라우팅 정책)

DNS란?

domain name system의 줄임말이다.

• 호스트 네임을 적절한 ip 주소로 변경해주는 역할을 한다. ex) naver.com을 입력하면 웹 사이트로 이동
• URL과 호스트 네임을 IP로 변환한다.
• DNS는 계층적 네이밍 구조를 가지고 있다.
  • www. example. com

DNS 관련 용어

• Domian Registrar: 도메인 네임을 등록하는 곳이다.
  • ex) Route 53, Go Dddy, 가비아 ,,
• DNS Records : 밑에 나온다
  • ex) A,AAAA,CNAME,NS ,,
• Zone File: 모든 DNS 레코드를 포함한다.
  • 호스트 네임과 IP 주소를 존 파일을 통해 일치 시킨다.
• NAME Server: DNS 쿼리를 실제로 해결하는 서버다.
• Top Level Domain (TLD): com, us, in, gov ,,
• Second Level Domain (SLD): amazon.com, google.com ,,,

DNS 동작방식

1. 사용자가 example.com에 대해 Local Domain Server(통신사에서 관리하는 DNS 서버)에 물어본다.
2. LDS가 루트 도메인 서버에 example.com에 대해 물어본다
3. 루트 도메인 서버는 .com을 관리하는 TLD 서버의 ip 주소를 알려준다.
4. TLD DNS 서버는 .com 중 example.com 을 찾아서 example.com을 관리하는 SLD DNS 서버 주소를 알려준다.
5. SLD DNS 서버는 example.com 중 https:// example.com을 찾아 로컬 도메인 서버에게 알려준다.
6. 해당 주소를 다시 엔드 유저에게 전달하면 해당 ip를 통해 접근할 수 있다.

Route 53

고가용성, 확장성을 갖춘, 관리되는 권한있는 DNS다.

• 권한 있다는게 무슨 뜻일까
  • 고객인 우리가 DNS 레코드를 업데이트 할 수 있다는 의미다.

위와 같은 방식으로 ec2 인스턴스에 도메인네임을 등록하여 해당 도메인 네임으로 인스턴스에 접근할 수 있게 해주는

Domain Registrar다.

 

• Route 53으로 특정 리소스의 health check를 할 수 있다.
• 100%의 SLA 가용성을 제공하는 유일한 AWS 서비스다.
• 53은 DNS 서비스에서 사용되는 전통적인 포트번호다.

Route 53 - Records

라우트 53에서 여러 DNS 레코드를 정의하고, 레코드를 통해 특정 도메인으로 라우팅 하는 방법을 정의한다.

• 각 레코드는 다음과 같은 항목을 포함한다.
  • 도메인이나 example.com과 같은 서브 도메인의 정보를 포함한다.
  • RecordType: A,AAAA등 ,,
  • Value: 123.456.789.123
  • Routing Policy: 라우트 53이 쿼리에 응답하는 방식을 정의한 것 
  • TTL: DNS 리솔버에서 레코드가 캐싱되는 시간을 저장한다.
• Route 53 에서 지원하는 레코드 타입은 다양하다
  • 반드시 알아야할 것은 A/ AAAA/ CNAME/ NS 다.

A 레코드 타입

• 호스트 네임과 IPv4 ip주소를 매핑한다.

AAAA 레코드 타입

• 호스트 네임과 IPv6 주소를 매핑한다.

CNAME 레코드 타입

• 호스트 네임을 다른 호스트 네임과 매핑한다. 
  • 예) example.com 을 www.example.com으로 매핑
• CNAME 레코드를 설정할 때, 그 대상이 되는 목표 도메인은
  A 레코드 또는 AAAA 레코드를 가지고 있어야 한다.
• Route 53에서 DNS 이름 공간 또는 (Zone Apex) 최상위 노드에 대한 CNAMES를 생성할 수 없다. 
  • 예를들어 example.com에는 CNAME을 만들 수 없지만
    www.example.com에는 CANME을 만들 ㅜㅅ 있다.

NS 레코드 타입

• NS는 호스팅 존의 네임 서버다 
• 서버의 DNS 네임 또는 IP 주소로 호스팅 존에서 날라온 DNS 쿼리에 응답한다.
• 트래픽이 도메인으로 라우팅 되는 방식을 제어한다.

호스팅 존이란? (Hosted Zone)

• 호스팅 존은 레코드의 컨테이너다.
• 특정 도메인에 대한 모든 DNS 레코드를 관리한다.
• 도메인과 서브 도메인으로 가는 트래픽의 라우팅 방식을 정의한다.

예시:

만약 example.com이라는 도메인을 AWS Route 53에서 관리하려면, example.com에 대한 호스팅 존을 생성합니다. 그 안에서 A 레코드로 example.com을 특정 IP에 연결하거나, CNAME 레코드로 www.example.com을 example.com에 연결하는 등의 작업을 할 수 있습니다. 

 

 

호스팅 존에는 두 가지 종류가 존재한다. 

• Public Hosting Zone
  • 퍼블릭 도메인 네임을 구매한다면 해당 도메인 네임에 대한 퍼블릭 호스팅 존을 만들 수 있다.
  • 외부에서 모두가 접근 가능한 도메인에 대한 관리를 한다.
• Private Hosting Zone
  • 공개되지 않는 도메인 네임을 지원한다.
  • 특정 VPC 내부에서만 사용되는 도메인 네임에 대한 DNS 설정을 관리한다. 
  • 외부에서 접근 불가능한 내부 네트워크용 도메인을 위한 호스팅 존이다.  

어떤 호스팅 존이던 달마다 50센트를 지불한다.

 

퍼블릭 호스팅 존과 프라이빗 호스팅 존은 똑같이 동작하지만 

 

퍼블릭 호스팅 존은 누구든 레코드를 쿼리할 수 있다.

 

프라이빗 호스팅 존은 오직 프라이빗 리소스

VPC에서만 쿼리할 수 있다. 

다음과 같이 VPC 내부에서 다른 인스턴스로 접근하고 싶을 때 프라이빗 호스팅 존을 통해 접근할 수 있다.

 

Route 53 - Records TTL

1. 클라이언트가 서버에 접속하기 위해 route 53에 도메인 네임을 물어봤다.
2. route 53 은 ip 주소를 알려주며 TTL도 같이 보낸다.
3. 클라이언트는 해당 TTL 시간동안 ip 주소를 캐싱한다.
4. 해당 TTL 시간 이내에 클라이언트가 동일한 도메인에 접근하면
   DNS 시스템에 접근하지 않고 저장해둔 캐시로 바로 서버에 접근할 수 있다.

TTL 을 24시간으로 설정하면?

• Route 53의 트래픽은 현저히 적어진다.
• 클라이언트가 최신화된 ip를 받지 못해 이상한 주소에 접근할 수도 있다.

TTL을 60초로 설정하면?

• DNS에 트래픽의 양이 많아져서 비용이 많이 들게 된다.
• 오래된 이상한 레코드로 접속할 가능성이 준다.

TTL은 별칭 레코드를 제외하고  모든 레코드에게 거의 필수적이다. 

 

CNAME vs Alias

aws 리소스들(로드 밸런서, 클라우드 프론트)은 모두 aws에서 부여한 호스트 네임을 갖고 있다.

 

그리고 보유한 도메인을 해당 호스트 네임에 매핑하고자 할 수 있다.

 

해당 방법엔 몇 가지 옵션이 있다.

 

CNAME

• cname은 호스트 네임이 다른 호스트 네임으로 향하도록 하는 레코드 타입이다. 
• 이건 루트 도메인 네임이 아닌 경우에만 가능해서 domaim.com 앞에 무언가가 붙어야 한다. 

Alias

• route 53에 한정되지만 호스트 네임이 특정 AWS 리소스로 향하도록 할 수 있다.
  • 즉 호스트 네임이 다른 호스트 네임으로 향하게도 만들 수 있다는 의미다.
• 별칭 레코드는 루트 및 서브 도메인 모두에 적용할 수 있다.
  • mydomain.com을 다른 리소스나 다른 도메인으로 보낼 수 있다는 의미다.
• 자체적으로 상태확인이 가능하다.

Alias Records

이들은 AWS의 리소스에만 매핑이 되어 있다.

 

route 53에서 example.com을 A타입의 별칭 레코드로 하고

그 값은 로드밸런서의 DNS 네임을 가르킨다고 하자

 

• 이건 DNS의 확장 기능으로 시중의 모든 DNS에서 가능하다.
• 만약 ALB의 ip 주소가 변경되면 별칭 레코드는 이걸 바로 인식한다.
• CNAME과 달리 별칭 레코드는 Zone Apex라는 것의 상위 노드로도 사용될 수 있다.
• AWS 리소스를 위한 별칭 레코드의 타입은 항상 A, AAAA로 해야 한다.
• 별칭 레코드를 사용하면 TTL을 설정할 수 없다.

별칭 레코드의 대상은 무엇이 될 수 있을까

EC2의 DNS 네임에 대해서는 별칭 레코드를 설정할 수 없다.

 

Route 53의 라우팅 정책

라우팅 정책은 Route 53이 DNS 쿼리에 응답하는 것을 돕는다.

• 라우팅이란 단어를 혼동하면 안 된다.
• 로드 밸런서가 트래픽을 백엔드 EC2에 라우팅 하는 것과는 다른 상황이다.
• 여기서 라우팅은 DNS 관점이다.
• DNS는 호스트 네임을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 DNS 라우팅이라 한다.

Route 53에서 지원하는 라우팅 정책은 다음과 같다.

Simple - 단순 라우팅 정책

• 단순하게 하나의 IP 주소나 도메인에 대한 응답을 반환하는 방식이다. 

• 동일한 레코드에 여러 개의 값을 지정하는 것도 가능한데 
• 이렇게 다중 값이 존재하는 경우에는 클라이언트 쪽에서 그 중 하나를 랜덤으로 고르게 된다.

예를 들어 위의 그림과 같은 상황이라 하면

route 53은 여러 개의 값을 반환하고 클라이언트에서 그 중 하나를 골라 라우팅 한다.

• 단순 라우팅 정책에 별칭 레코드를 함께 사용하면
• 하나의 AWS 리소스 만을 대상으로 지정할 수 있다.
• health check은 할 수 없다.

Weighted - 가중치 기반 라우팅 정책

• 가중치를 활용해 특정 리소스로 라우팅 한다.

다음과 같이 각각의 인스턴스에 가중치를 할당할 수 있고 해당 가중치의 % 만큼 트래픽이 향한다.

각 레코드로 보내지는 트래픽의 양은 해당 레코드의 가중치를 전체 가중치로 나눈 값을 같게 된다.

• 가중치의 합은 100이 아니어도 된다.
• 이렇게 하려면 DNS 레코드들은 동일한 도메인 이름과 유형을 가져야 하며 
  health check와도 연관되어 작동하게 된다.

사용 예시

1. 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나
2. 적은 양의 트래픽을 보내 새 애플리케이션을 테스트 하는 경우에도 사용한다.
3. 가중치 0의 값을 할당하게 되면 특정 리소스에 트래픽 보내기를 중단한다.
4. 만약 모든 레코드의 가중치 값이 0인 경우에는 모든 레코드가 다시 동일한 가중치를 갖게 된다.

 

Latency-based - 지연 시간 기반 라우팅 정책

• 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책이다.
• 지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 유용하다. 
• 지연 시간은 특정 Region에 도달하는데 까지 걸리는 시간을 기반으로 측정된다.
• 헬스 체크와 연결이 가능하다.

Route 53 - Health Check

• 헬스 체크는 공용 리소스에 대한 상태를 확인하는 방법이다. 

서로 다른 두 지역에 각각 한 개의 로드 밸런서가 있고

둘은 모두 공용 로드 밸런서라고 해보자. 

 

그 둘의 뒤에서 애플리케이션이 작동 중이다.

 

다중 AZ로 고 가용성을 원하는 상황이다. 

 

그리고 Route53을 이용해 DNS 레코드를 만들 것이다. 

여기서 만약 한 지역이 사용 불가능 상태가 되면

해당 지역으로는 트래픽을 보내선 안 된다 이를 위해 각각의 route 53에 헬스 체크를 생성해야 한다.

 

이제 해당 헬스 체크를 Rotue 53의 레코드와 연결할 수 있다.

이를 통해 장애 조치를 자동화 할 수 있다.

 

세 가지의 헬스 체크가 가능하다.

1. 공용 엔드 포인트를 모니터링 하는 것 
   (애플리케이션, 서버, AWs 리소스 등등,,)
2. 다른 헬스 체크를 헬스 체크 할 수도 있다.
3. 클라우드 워치 경보의 상태를 모니터링 하는 상태 확인도 있다. '

이 헬스 체크들은 각자의 매트릭을 사용하는데 클라우드 워치의 지표에서도 확인이 가능하다.

 

health check - monitor 엔드 포인트

각 지역에서 요청을 보내고 200ok를 받으면 정상이라 간주한다.

• 전 세계에서 온 15개의 상태 확인이 엔드 포인트의 상태를 확인하고
  임계값을 정상 혹은 비정상으로 설정한다.
• 확인을 보내는 간격도 설정 가능한데 두 개의 선택지가 있다. 
  • 10초 or  30초 
• HTTP, HTTPS. TCP 등 많은 프로토콜을 지원한다. 
• 18% 이상의 상태확인이 엔드포인트를 정상이라고 판단하면 라우트 53도 이를 정상이라고 간주한다.
• 그렇지 않다면 비정상인 것으로 인식한다.
• 상태확인은 2xx 또는 3xx의 상태코드를 받으면 정상이라 판단한다. 
• 텍스트 기반응답인 경우 상태 확인은 응답의 처음 5120 바이트를 확인한다. 
  • 응답 자체에 해당 텍스트가 있는지 보기 위해서다.
• 상태확인이 정상적으로 작동하려면 상태확인이 로드 밸런서나 엔드포인트에 접근이 가능해야 한다.
• 따라서 헬스 체크가 들어올 모든 IP 주소를 허용해야한다. 

Route 53 - Calculated Health Checks

여러 개의 상태확인 결과를 하나로 합쳐주는 기능이다.

다음과 같이 인스턴스 별로 헬스 체크를 생성한 후 헬스 체크의 결과를 합쳐서 판단한다.

 

헬스 체크의 결과를 합치는 방법은 AND, OR, NOT 세 가지가 존재한다.

 

• AND: 모든 하위 헬스 체크가 정상이어야 상위 헬스 체크가 정상으로 판단됩니다.
• OR: 하나 이상의 하위 헬스 체크가 정상이면 상위 헬스 체크도 정상으로 판단됩니다.
• NOT: 특정 하위 헬스 체크가 비정상이어야 상위 헬스 체크가 정상으로 판단됩니다. (이건 흔하게 쓰이지는 않음).

 

• 하위 헬스 체크를 256개까지 모니터링할 수 있고 
• 하위 헬스 체크 몇 개를 통과해야 상위 헬스 체크를 통과할 수 있는지도 정할 수 있다.
  • 이 부분은 조금 다른 설명인데, 이건 Threshold(기준값) 설정에 대한 내용입니다.
    즉, OR 연산의 변형이라고 볼 수 있습니다. 하위 헬스 체크 중 몇 개 이상이 정상이면 상위 헬스 체크를 정상으로 판단하겠다는 설정입니다. 예를 들어, 10개의 하위 헬스 체크가 있다면 그중에서 5개만 정상이어도 상위 헬스 체크를 정상으로 판단할 수 있도록 설정할 수 있는 것입니다.

개인 리소스의 상태 확인 방법 

개인 리소스의 상태를 확인하는건 좀 어려울 수 있는데 모든 Route53의 상태 확인이 

공용 웹 즉 VPC 외부에 있기 때문이다.

 

그래서 클라우드 워치 지표를 만들어 클라우드 워치 알람을 할당하는 식으로 이 문제를 해결할 수 있다.

 

그러면 클라우드 워치 경보를 상태 확인에 할당할 수 있다. 

 

클라우드 워치를 통해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링 하는 것이다. 

 

라우팅 정책 - Fail Over (Active Passive)

• 메인 EC2 인스턴스가 비정상이면 보조 인스턴스로 이동한다.
• 헬스 체크는 기본과 보조가 각각 하나씩만 있을 수 있다.

라우팅 정책 - Geolocation (지리 위치)

• 지연 시간 기반의 정책과는 매우 다르게 사용자의 실제 위치를 기반으로 한다.
• 사용자가 어느 주에 거주하는지 선택하여 해당 IP 로 라우팅되는 것이다. 
• 일치하는 위치가 없는 경우에는 기본 레코드(특정 아무 구역으)로 라우팅 한다. 
• 사용 사례로는 콘텐츠 분산을 제한하고 로드 밸런싱등을 실행하는 웹사이트 현지화가 있다.
• 상태확인과 연결할 수 있다. 

이런 식으로 지역을 Asia 값을 특정 인스턴스로 정해두면

Asia의 모든 유저는 위에 설정한 특정 인스턴스로 가게 된다.

 이렇게 디폴트 로케이션도 반드시 설정해야 한다. 

 

라우팅 정책 - Geoproximity Routing Policy

• 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 라우팅한다.
• 보통은 사용자의 위치에 가장 가까운 리소스로 트래픽을 보내지만
  bias를 설정하면 이 기본 동작을 바꿀 수 있다.
• 지리적 라우팅 기준을 변경하려면 bias 를 지정해야 한다. 
• 특정 리소스에 더 많은 트래픽을 보내려면 bias를 늘리면 된다.
• bias는 음수값도 가능하기 때문에 트래픽을 줄이려면 bias를 음수로 설정하면 된다.

AWS 리소스를 사용하는 경우엔 Region을 정해줘야 하며

AWS 리소스가 아닌 경우엔 위도와 경도를 지정해줘야 한다.

 

 

bias를 사용하려면 Route 53의 트래픽 플로우를 사용해야 한다.

사용자의 위치를 기반으로 가까운 리소스에 연결된다.

 

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

 

traffic flow

• 트래픽을 효율적으로 관리하고 복잡한 라우팅 정책을 설정할 수 있게 해주는 기능이다.

다음 ui를 통해 세부 사항을 결정할 수 있다. 

• 트래픽 플로우 정책으로 저장이 된다.
• 버전을 지정하고 호스팅 영역을 적용할 수 있으며
• 호스팅 영역에서 쉽게 변경하고 적용할 수 있다.

라우팅 정책 - ip 기반 라우팅

• 클라이언트 ip 주소를 기반으로 라우팅을 정의한다.
• 클라이언트의 cidr 목록을 입력해야 한다.
• ip를 미리 알고있으니 최적화가 쉽고
  ip가 어디에서 오는지 알고 있으므로 네트워크 비용도 절감할 수 있다.

레코드 네임과 ip based를 설정할 수 있다.

이를 통해 레코드 네임으로 들어와도 value로 이동하고

특정 ip 범위에서 들어와도 value로 이동하게 설정할 수 있다. 

 

라우팅 정책  - Multi value

• 트래픽을 다중 리소스로 라우팅할 때 사용한다.
• 라우트 53은 다중 값을 반환한다.
• 상태확인과 연결할 수 있다.
• 한 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
• ELB와 비슷해보이지만 ELB를 대체할 수 없다.
  • 클라이언트 측면의 로드 밸런싱인 것이다.
• 단일 값 반환 정책은 상태 확인과 연결 할 수 없으니 그런 부분에서 다르다. 

도메인 레지스트라

도메인 네임을 구매하면 DNS 레코드 관리를 위한 DNS 서비스를 제공한다.

 

다른 도메인 레즈스트라에서 도메인을 구매하여 route 53에 등록한 다음 관리할 수도 있다. 

1. route 53에 퍼블릭 호스팅 존을 만든다
2. route 53의 NS 값을 다른 도메인 레지스트라의 NS 값에 집어넣는다.
3. 이제 다른 도메인 레지스트라로 들어온 요청은 route 53으로 연결되어 route 53에서 트래픽을 관리할 수 있다.