AWS Route 53

DNS란

사람들에게 친숙한 도메인을 IP주소로 변환해주는 것을 의미한다.

계층적 이름 구조가 존재한다. 

.com

example.com

www.example.com  

이런식으로 말이다.

 

domain registra

amazon route 53, go daddy, ...

 

DNS records

A, AAAA, CNAME, NS ...

 

Zone file

모든 DNS레코드를 기록한 파일

 

Name server

dns쿼리를 실제로 해결하는 서버 

 

Top level domain

.com .in .us ...

 

Second level domain

example.com < 

 

.com : TLD

example.com : SLD

www.example.com  : Sub domain

api.www.example.com : Domain name 

 

FQDN : http://api.www.example.com : Domain name 

http는 프로토콜 

 

DNS 동작 원리 

먼저 웹 브라우저에서 example.com으로 접속을하면 local DNS서버로 요청이 가는데, 여기서 해당 도메인에 대한 캐시 값이 없다면 먼저 Root DNS 서버로 요청을 보낸다. 그럼 example.com은 모르는데 .com은 어딘지 안다고 하며 .com을 관리하는 주소(TLD server)를 보내준다. 그럼 그 주소를 타고 .com에 가서 example.com을 아냐고 물어본다. 그럼 .com에서 example.com의 주소는 모르는데 이를 관리하고 있는 곳은 안다고 알려준다 그럼 그 서버는 domain registra에 관리되는 서버로 보내진다. SLD server이며 예를들어 route 53이라면 거기서 example.com주소를 알려준다. 그럼 이 주소를 local dns서버의 캐시에 저장해두고 이를 브라우저에게 돌려주며 ip주소를 알려준다. 그리고 캐시에 저장이 되어있으므로 다음번에 다시 이 주소에 대한 요청이 오면 dns서버로 가는 작업을 하지 않고 바로 브라우저에게 ip주소를 돌려줄 수 있다. 

 

Route53

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

고객 자신이 DNS에 대해 완전히 제어할 수 있다. 

 

ec2에 인스턴스를 생성하고 이를 DNS레코드를 사용하여 접근하려고 한다면 .

route53에 등록해두면 된다. 그럼 route 53이 등록된 레코드 네임의 아이피 값을 브라우저에 전해줌으로 바로 ec2에 접근할 수 있게 된다.

 

각 recode는

도메인, 서브도메인 이름을 가지고 있다.

레코드 타입을 가지고 있다. A, AAAA...

레코드 값, 123.456.789.123

라우팅 폴리시, : 어떻게 route53이 쿼리에 리스폰스하는지 정함

TTL, DNS리졸버에서 레코드가 캐쉬되는 시간이다.

 

레코드 타입

A: 호스트네임을 ip4와 매칭시킨다.

example.com > 1.2.3.4 

AAAA : 호스트네임을 ip6와 매칭시킨다.

CNAME : 호스트네임을 다른 호스트 네임과 매칭시킨다. 

물론 대상 호스트 이름은 A나 AAAA레코드가 될 수 있다.

example.com에 대한 cname은 만들 수 없지만 www.example.com에 대한 cname은 만들 수 있다.

NS : 서버의 DNS 이름 또는 IP주소로 호스팅 존에 대한 DNS쿼리에 응답가능 

 

 

Hosted Zones 

레코드의 컨테이너이다. 

도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다 .

퍼블릭, 프라이빗이 있다.

퍼블릭 도메인 이름을 살 때마다 퍼블릭 호스팅 존을 만들 수 있다.

퍼블릭 호스팅 존은 공개된 클라이언트로 부터 온 쿼리에 응답을 할 수 있다.

클라이언트 example.com 이 뭐야 ? ---> public hosting zone 54.22.33.44야

이렇게 해서 외부에서 들어올 수 있는데

 

프라비잇 호스팅 존은 해당 VPC에서만 동작한다. 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있게 해준다.

예를들어 vpc안에 2개의 인스턴스와 하나의 db가있고, 

webapp.example.internal , api.example.internald은 각 Ec2에 설정하고

db.example.internal은 디비에 설정해두었다면 해당 VPC안에서만 사용이 가능하다.

webapp인스턴스에서 api인스턴스의 주소를 퍼블릭 호스팅 존에 요청하면 해당 아이피를 반환해준다.

 

퍼블릭 호스팅은 외부에서 여러분의 해당 도메인에 대한 아이피를 취득할 수 있지만,

프라이빗 호스팅은 같은 VPC내에서만 가능하다

 

route 53에서 호스팅 존을 하나 퍼블릭으로 생성한 뒤에  exampl.com

앞에 test.example.com처럼 test라는 것을 붙여서 A타입, 아이피 주소를 적으면 하나 레코드를 생성할 수 있게 된다.

그런 뒤에 test.example.com으로 접속을 하면 호스팅 존에 값이 무엇인지 요청할 것이고 호스팅존은 설정한 아이피 값을 반환하게 된다.

nslookup test.example.com을 해보면 바로 알 수 있다, 이럼 우리가 등록한 아이피 값을 반환해준다. 맥에선 dig

 

TTL ( Time To Live ) 

클라이언트가 dns요청을 보내면 route 53에서 a레코드인 아이피와 ttl을 함께준다.

그리고 꼭 클라이언트에게 이TTL을 캐시하도록 요청한다. 300초 동안 클라이언트는 결과를 캐시한다.

이 말인 즉슨 클라이언트가 재 요청을 보내거나, 같은 호스트 이름으로 접속할 경우 클라이언트는 DNS시스템에게 쿼리를 보내지 않아도 된다는 말이다.

 

극단적인 예를 상상해보자 우리가 24시간을 TTL로 설정한다면 라우트 53의 트래픽은 현저히 적을 것이다.

왜나면 라우트53으로 해당 유알엘로 요청을 24시간동안 안보낼 것이니까, 하지만 클라이언트가 오래된 레코드를 받을 가능성이 있다.

반대로 60초로 짧게 설정한다면 트래픽 요청이 많아짐으로 가격이 높아질 것이다. 

 

두개의 인스턴스를 준비해두고 TTL을 2분으로 설정해보자 a,b인스턴스가 있다고 가정하자

ip는 a의 인스턴스의 아이피를적으면 처음 클라이언트가 요청을 보내면 2분동안은 반환받은 a의 아이피를 캐시로저장해둘 것이다.

그래서 레코드를 입력하면 a로 접속을 한다. 그리고 바로 레코드의 아이피를 b아이피로 바꾼다.

그럼 2분동안은 a인스턴스로 접속이 될 것이고 2분이 지나면 b인스턴스로 접속이 되는걸 확인할 수 있다.

 

별칭 (alias record )레코드를 제외하고는 TTL설정은 필수이다. 

 

CNAME vs Alias

CNAME

로드 밸런서나 cloud front를 사용하는 경우 호스트 이름이 노출된다,

그리고 보유한 도메인에 호스트 이름을 매핑하고자 할 수도 있다.

 

예를들어 로드밸런서를 만들면 기본적으로 도메인을 하나 준다.

그리고 내가 레코드로 만든 도메인과 연결시키고 싶다.

그럼 CNAME방식을 사용해야한다. 씨네임은 도메인과 도메인을 연결시켜주기 때문이다.

위에서 해본 것은 도메인과 인스턴스의 아이피를 연결했기 때문에 A방식을 사용한 것이다.

이건 루트 도메인 이름이 아닌 경우에만 가능하다. 

예를들어 루트 도메인 이름이 example.com이면 레코드를 생성하면 하위에 abcd.example.com이라던지

test.example.com이라던지 이렇게 생성된다. 이 것과 연결을 시킬 순 있지만 example.com과 연결 시킬 수는 없다는 말이다.

 

Alias

이건 루트53에만 한정이 된다. 호스트 이름이 특정 AWS리소스로 향하도록 할 수 있다. 

예를들어 abcd.example.com을 hihi.example.com으로 향하도록 할 수 있다. 이건 루트 도메인 및 비루트 도메인에 적용한다.

루트 도메인 ( example.com을 별칭으로 사용해서 AWS리소스로 향하도록 할 수 있기 때문에 아주 유용하다. )

무료이며 자체적으로 상태확인이 가능. 근데 이건 무조건 AWS의 리소스에만 매핑이 되어있다. 

TTL을 사용할 수 없다.

EC2 DNS 이름은 별칭 레코드 대상이 될 수 없다.

 

라우팅정책

 

simple 

기본적으로 레코드에 아이피를 지정해주는것이다.

여기에 아이피를 여러개 지정해 줄 수도 있다.

그럼 클라이언트가 알아서 여러개의 아이피 중에 골라서 아이피에 접속한다.

상태 확인은 불가하다. 그래서 여러개를 지정할 때 상태확인이 비정상인 값이 반환될 수도 있다

 

weighted

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

세개의 인스턴스가 있고 각 인스턴스에 70 20 10을 지정해줄 수 있는데 그럼

루트 53에서 오는 dns응답의 70퍼센트가 첫 번째 ec2 인스턴스로 리다이렉팅 된다.

마찬가지로 20퍼센트는 두번째로 10퍼센트트 세번째로 간다. 

dns레코드들은 동일한 이름과 유형을 가져야 한다. 

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

가중 0을 선택하면 트래픽 보내기 중단, 하지만 모든 레코드가 0이면 동일한 가중치를 갖음 

 

Latency-based

지연시간기반이다. 

지연기간이 가장 짧은 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책이다.

예를들어 두개의 로드밸런서를 미국과 일본에 만들고 그 로드밸런서에 접근하는 시간이 짧은 쪽 즉 가까운 곳으로 이동시켜 주는 것을 의미한다. 아시아 살면 일본으로 유럽에 살면 미국으로 갈 것이다.

상태확인 가능하다.

 

Failover ( active-passive )

2개의 인스턴스가 있다고 가정하고 하나는 일반 인스턴스고 하나는 재해복구용인스턴스라고 해보자.

상태확인과 기본 레코드를 연결한다. (필수)

만약 이 상태확인이 비정상이면 자동으로 루트53은 2번째 인스턴스로 장애조치를 한다.

( 기존에는 첫번째 인스턴스로 보내는데 거기서 헬스체크가 비정상이면 두번째 인스턴스로 보낸다 )

클라이언트는 정상으로 생각되는 리소스를 자동으로 얻는다. 기본이 정상이면 루트53은 기본레코드로 응답한다.

비정상이면 장애조치에 도움되는 두번째 레코드이ㅡ 응답을 얻게된다. 두번째 인스턴스에도 헬스체크를 달아줘도 되지만 

안달아줘도상관없다. 

 

Geolocation

사용자의 실제위치를 기반으로한다.

특정 대륙이나 국가 혹은 어디에 있는지 더 정확하게

미국의 경우 어떤 주에에 있는지 특정할 수 있다.

 

예를들어 프랑스에서 접속하면 a인스턴스로 보낸다. a인스턴스는 프랑스 버전이다.

독일에서 접속하면 b인스턴스로 보낸다. b인스턴스는 독일어이다. 

디폴트로 설정하면 다른지역에서 트래픽을 보내면 모두 c인스턴스로 보내는식으로할 수 있다. 

(지연시간과의 차이는 지연시간은 단순히 해당 인스턴스로 가는 시간이 짧은 쪽에간다. 특정 지역을 한정할 수 없음 )

근데 이건 위치를 아시아로 설정해두면 아시아에서 오는 모든 트래픽은 특정 인스턴스로 보낼 수 있음

 

Geoproximity Routing policy

인스턴스 위치가 us-west-1리전에있고, 다른 하나는 us-east-1에 있다고 가정하다.

그럼 이 두 위치를 기반으로 반을 갈라서 미국 전역의 사용자가 리소스에 접속하게 된다.

반을 갈라서 us-west-1과 가까운 곳에서 접속한 유저는 그 인스턴스로, 반대면 반대의 인스턴스로갈것이다.

 편향이 없으면 반으로 가른다. 근데 여기서 편향값을 설정하면 bias 

us-west-1에는 편향값을 0으로 지정 us-east-1에는 50으로 지정하면 그 편향으로 해당 리소스에 더 많은 사용자와 ㅍ=트래픽이 발생된다. 그 이유는 편향값 때문에 선이 반으로 갈리는게 아니라 east인스턴스 쪽의 공간이 좀더 넓게 생성되기때문이다

즉 1/2 씩기존 편향값이 0인경우 )  지금은 1/3 2/3이 되어버린 느 낌이다. 2/3에 속한 지역에서 접속하면 east로 트래픽이 이동

 

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

 

Multi-Value

트래픽을 다중 리소스로 라우팅할 때 사용한다.

 그래서 Route 53은 다중 값과 리소스를 반환한다. 

헬스체크와 같이 사용할 수 있늗데 이 때에는 정상확인이 된 값만 리턴한다.

최대 8개의 정상 레코드가 반환될 수 있다.

 

예를들어 3개의 레코드를 각 헬스체크와 묶어서 연결해놓으면

클라이언트가 해당 레코드로 접속하면 정상확인이 된 아이피만 반환한다.

비정상이면 반환 x근데 심플정책에서 여러개를 지정해놓은 경우 하나가 비정상이더라도 그냥 전부 준다고 알고있음

그래서 비정상이 것에 접근 할 가능성이 있을수도

 

도메인은 다른 레지스트라에 구매하고 DNS서버를 라우트53으로 사용할 수 있다.

라우트 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 그 호스팅영역에 이름 서버를 찾는다.NS

그 걸 도메인 구매한 사이트에서 네임서버에 입력을 해주면 된다. 

 

-> 도메인을 타사 등록 대행사에서 구매해도 , DNS서비스 제공자로 루트53을 사용가능하다. 

사용하려면 루트53에서 공용 호스팅 영역을 생성한 뒤에 도메인을 구매한 타사 웹사이트에서 NS서버를 입력하면 루트53 NS를 가리키게 된다.

 

 

 

 

 

 

상태확인 헬스체크

각 ec2 마다 헬스체크를 만들 수 있다. 만약

calcutated를 누르면 여러 인스턴스를 한번에 묶어서 상태체크를 할 수 있다.

 

 

각기 다른 리전에 3개의 인스턴스를 생성해보자  로드 밸런서를 그 중 하나의 리전에 만들자 .