ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Amazon Route 53 DNS 서비스
    카테고리 없음 2017. 2. 3. 22:52



    Route53은 아마존에서 제공하는 DNS 서비스이다. 일반 DNS와 다르게 아마존에 특성화된 몇 가지 기능을 가지고 있는데 특화 기능에 앞서 DNS의 일반 개념을 먼저 정리해 보자.



    DNS


    DNS는 domain name (www.example.com)을 ip 주소로 바꿔 주는 일종의 dictionary 서비스 이다.

    이러한 맵핑 정보를 저장해 놓는 파일을 DNS Zone file 이라고 한다.


    이 서비스는 DNS 서버에 저장해놓은 파일을 기반으로 주소를 변환한느데, 여기에 정의되는 레코드들 중에서 대표적인 레코드는 다음과 같다.


    1) SOA 레코드 : 해당 DNS 서버 자체의 설정 정보를 정의한다.

    + DNS 서버는 Primary/Secondary 구조로 장애 대응을 할 수 있는 구조인데, 이를 위해서 SOA 레코드에는 이를 위한 설정이 반영되어 있다.

    + serial # - reverse #로 Zone 파일이 업데이트 될때 마다 증가하는 일종의 버전
    + refresh : secondary server가 primary server로 부터 업데이트를 하는 주기
    + retry : primary server로 부터의 query 가 실패하였을 때, 다음 retry 까지 시간
    + expire : secondary server 에서 zone 파일을 유지하는 시간
    + TTL : DNS 응답을 받아가는 서버가 해당 레코드 응답을 얼마나 유지해야 하는 TTL 시간

    2) NS 레코드 : DNS 서버가 참조하는 다른 DNS 서버이다. DNS 서버 자신에서 domain name 에 대한 주소를 알아 내지 못할때, 이 NS 레코드에 정의된 서버로 가서 주소를 알아온다.

    3) CNAEM 레코드 : 도메인명을 다른 도메인과 맵핑할 때 사용 (일종의 alias)

    4) A 레코드 : 도메인을 ip로 맵핑

    5) PRT 레코드 : ip를 도메인으로 맵핑 (Reverse Zone에서 사용)



    DNS 서버의 캐싱

    DNS 서버의 특성 중에서 주의깊게 봐야 하는 특성은 캐싱이다.
    보통 DNS 서버는 클라이언트가 사용하는 로컬 네트워크에 있는 DNS를 사용하게 된다. 회사 네트워크라면 회사내의 DNS 서버, 집에서 사용하는 경우 해당 통신사의 DNS서버, 모바일을 사용할 경우, 해당 통신사의 DNS 서버를 사용한다. 이 DNS서버들은 look up을 요청한 목적 서비스 서버에 대한 ip 주소를 다른 클라이언트가 요청할 때 응답을 빠르게 하기 위해서 자체적으로 캐싱하고 있따.

    예를 들어 구글의 A라는 서비스가 있다고 하자. 이 서비스 A는 구글의 DNS 서버에 주소가 정의되었을 것이다. 만약 한국의 사용자가 스마트 폰을 이용하여 이 서비스의 URL을 접근하게 되면, 해당 한국 통신사의 DNS 서버를 통해서 주소를 look up 하게 될 것이고, 이 한국 DNS 서버는 구글의 DNS 서버에 주소를 물어본 후에, 다음 서비스를 위해서 자신의 Cache를 업데이트 한다. 


    이 캐시가 지워지고 다시 업데이트 되는 시간이 TTL 시간인데, 이 TTL은 이후에도 설명하겠지만, 동적으로 DNS 주소를 업데이트하거나 변경하였을때, 로컬 DNS서버의 캐시가 업데이트 되지 않아서 실제 주소가 바뀌더라도 이전 서버의 주소를 리턴하는 경우가 있어 주소 변경을 어렵게 한다.




    Route 53 의 고유기능


    Health check & DNS Fail Over

    Route53은 자체적으로 Health check 기능을 가지고 있다. 하나의 DNS 명에 대해서 multiple ip address를 return 할 수 있는데, 해당 ip의 서버의 상태를 체크해서 장애인 경우에는 list에서 제외하고, 장애가 복구 되면 다시 리스트에 추가하는 형태이다. 


    앞에서도 언급했듯이 이 기능의 경우 local DNS 들의 캐싱 때문에, Route53이 장애를 인지하고 바로 list를 제외한다 하더라도 local DNS 에서 캐시가 업데이트 되는 시간이 필요하기 때문에 바로 fail over 되지 않는다. 되도록 빠른 fail over를 하기 위해서는 Route 53에서 TTL 시간을 짧게 주는 것이 좋은데, 아마존의 경우 60초 이하의 값을 권장하고 있다.


    Latency based routing 


    Route53의 기능 중에 상당히 흥미로운 기능중의 하나인데, Route53에 하나의 DNS 주소에 대해서 여러개의 서비스 ip가 binding 되어 있을 경우, Route53은 클라이언트로부터 DNS 주소에 대한 look up 요청을 받았을 경우, 클라이언트로 부터 가장 빠른 응답시간을 보장하는 (거리가 가까운) 서버의 ip 주소를 리턴하는 기능이다. 


    원리를 설명해보면 다음과 같다. 아마존 인프라는 각 데이터센터로부터 다른 ip주소 대역까지의 네트워크 latency 값을 주기적으로 수집해서 데이터 베이스화 해서 가지고 있다. 예를 들어 미국 아마존 데이터센터에서 전세계에 대한 latency를 아마존을 가지고 있다. 한국, 중국, 유럽 등등 이렇게 latency 자료를 가지고 있다가, DNS look up요청이 오면, 요청을 한 클라이언트쪽의 Ip를 기반으로 내부 데이터 베이스 내의 latency를 체크하여 가장 가까운 아마존 데이터 센터의 ip를 리턴하게 되는 원리이다. 


    이 때 Route53으로 request를 보내는 클라이언트는 end user browser나 모바일 기기등이 아니라 end user가 접속된 네트워크의 로컬 DNS 서버가 되게 된다. 


    Latency based routing 의 경우 로컬 DNS가 클라이언트가 접속하는 망내에 있는 것을 전제로 한다.



Designed by Tistory.