Route 53에 대해 알아보자 (2)

 

#0 Route 53 - Records TTL (레코드 Time To Live)

아래 그림으로 먼저 설명해보겠다.

클라이언트가 DNS route53와 웹 서버에 접속한다고 가정해보자.

myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받는데 회신 내용으로는 A레코드와 IP주소, 그리고 TTL이 있고 TTL은 300초 정도 된다고 할 때, TTL은 클라이언트에게 300초의 TTL동안 이 결과를 캐시하도록 요청한다.

=> 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미 (이미 답변을 캐시에 저장했기 때문에 답을 알고 있다.)

하지만 캐시에도 시간이 소요되니 캐시 TTL이 발생한다.

DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않는 것이다. 레코드는 그렇게 자주 바뀌지 않으니..!

이미 저장된 답변을 이용함으로써 웹 서버에 접속이 가능하며 HTTP 요청 및 회신을 보낼 수 있다.

 

➕) 두 가지 극단적 예시를 추가로 알아보기

☑️ TTL 24시간으로 설정하기 :

Route53의 트래픽은 현저히 적으나 결과가 24시간동안 캐시되니 클라이언트는 요청을 적게 보낼 것이다. 클라이언트가 오래된 레코드를 받을 가능성도 있다.

=> 그래서 만약 레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻이다.

☑️ TTL 60초로 설정하기 :

DNS에는 트래픽의 양이 많아져서 비용이 많이 들게 된다.

=> 왜냐하면 Route53에 들어오는 요청의 양에 따라 요금이 책정되기 때문이다. 그러나 오래된 레코드의 보관 시간은 짧아지고 레코드 변경이 빨라진다.

 

==> 어떤 TTL설정이 더 적합할지는 상황에 따라 달라지니 알아두는 것이 좋다!

 (레코드를 변경하려는 경우, TTL을 24시간으로 늦춘 다음 모든 클라이언트가 느린 새 TTL을 가지고 있다는 점을 확인한 후, 레코드 값을 바꿔서 모두에게 업데이트가 되면 TTL을 올리는 식으로..)

 

#1 CNAME과 Alias 차이는?

로드밸런서나 SloudFront 등 AWS의 리소스를 사용하는 경우, 호스트 이름이 노출되어버린다.

그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수 있는데 예시) myapp.mydomain.com에 이 로드 밸런서를 매핑하는 경우이다.

 

✅ CNAME

CNAME 레코드로 앞서 A레코드를 다뤘고 이번엔 CNAME 레코드이다.

- CNAME은 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있다.

(예를 들어 app.mydomain.com이 blabla.anything.com으로 향하는 식)

=> 이건 🌟루트 도메인 이름이 아닌 경우에만 가능🌟해서 그냥 mydomain.com은 안 된다.

 

✅ Alias(별칭 레코드)

- Route53에 한정되지만 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있다.

(가령 app.mydomain.com이 blabla.amazonnaws.com을 향할 수 있는 거)

- Alias는 루트나 루트가 아닌 도메인 모두에 작동하고 mydomain.com을 Alias으로 사용해 AWS 리소스로 향하도록 할 수 있기 때문에 아주 유용하다.

- 무료이고 자체적으로 상태 확인이 가능하다.

...

그리고

- AWS 리소스에만 매핑되어있다.

위의 그림을 예로 들어 Route 53에서 example.com을 A레코드의 Alias로 하고

그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 가정할 때, DNS의 확장 기능으로 시중의 모든 DNS에서 가능하다. 만약 기반 ALB에서 IP가 바뀌면 Alias는 이걸 바로 인식할 것이다.

CNAME과 달리, Alias는 Aone Apex라는 DNS네임스페이스의 상위 노드로 사용될 수 있다. (example.com에도 Alias를 쓸 수 있는 것)

AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA인데 리소스는 IPv4나 IPv6 중 하나

(Alias 사용하면 TTL설정은 불가능)

 

➕) 위의 개념을 토대로 레코드 설정하기

Route53 - 호스팅영역 - 레코드 생성 클릭

1. CNAME으로 설정할 때

2. Alias로 설정할 뗴

 

#2 Route 53의 Routing Policies(라우팅 정책)이 정확이 뭘까?

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

...

들어가기에 앞서

🌟라우팅이라는 단어를 혼동하면 안 되는게 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스로 라우팅하는 거랑은 다른 상황..!🌟

(여기서의 라우팅은 DNS 관점 - DNS는 트래픽을 라우팅하지 X)

=> DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해서 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 되는 것이다. DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 돕는다.

 

Route 53가 지원하는 라우팅 정책 종류는 다음 챕터에서 다뤄보겠다.

 

#3 라우팅 정책 종류 살펴보기 (1)

종류로는 간단히 simple, Weighted, Failover, Latency based, Geolocation, Multi-Value Answer, Geoproximity등이 있는데 하나하나 다 다뤄보려고 한다.

 

1. Simple(단순 라우팅 정책) :

일반적으로 트래픽을 단일 리소스로 보내는 방식이다.

위의 그림을 예로 들어 클라이언트가 foo.example.com으로 가고자 한다고 하면 Route 53이 IP주소를 알려주는 것이다. (이는 A 레코드 주소)

동일한 레코드에 여러 개의 값을 지정하는 것도 가능한데 이렇게 DNS에 의해 다중의 값을 받은 경우에는 클라이언트쪽에서 그 중 하나를 무작위로 고르게 된다.

위의 예시는 A 레코드에 임베딩된 세 개의 IP주소로 답하는데 클라이언트가 셋 중 하나를 골라서 라우팅에 적용하는 것!

+) 별칭(Alias) 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있다

=> 그러나 단순정책상 상태 확인은 할 수 없다..

 

2. Weighted(가중치 기반 라우팅 정책) :

이 정책을 사용하면, 가중치를 활용해서 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능하다.

그림을 보면 Amazon Route53이 있고 EC2 인스턴스가 세 개 있는데 각각 다른 가중치를 할당받은 모습이다. (DNS 응답의 70%가 첫 번째 EC2 인스턴스로 간다는 말이니 총합이 100이라는 말은 X)

한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지를 나타내는 값이다. 이렇게 하려면 DNS 레코드들은 동일한 이름과 유형을 가져야 하고 상태 확인과도 관련될 수 있다.

 

- 가중치 정책이 사용되는 경우는 무엇일까?🤔

서로 다른 지경들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에도 사용한다.

가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다..!

만약에 모든 리소스 레코드 가중치의 값이 0인 경우에는 모든 레코드가 다시 동일한 가중치를 갖게 된다.