[AWS] Route 53 - Records TTL

Records TTL(Time To Live)

• High TTL
   - 예를 들어 24시간으로 높게 설정한다면
       : Route 53의 트래픽은 현저히 적다. 결과가 24시간 동안 캐시될 테니 클라이언트는 요청을 적게 보낼 것이다. 하지만 클라이언트가 오래된 레코드를 받을 가능성도 있다. 그래서 만약 레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻이다.
• Low TTL
    - 반대로 TTL을 60초로 낮게 설정한다면
        : DNS에는 트래픽의 양이 많아져서 비용이 많이 들게 된다. Route 53에 들어오는 요청의 양에 따라 요금이 책정된다. 하지만 오래된 레코드의 보관 시간은 짧아진다. 레코드 변경 전반이 더욱 편리하게 된다. 
• 어떤 TTL 설정이 더 적합하지는 상황에 따라 달라진다.
• 레코드를 변경하려는 경우, 예를 들어 TTL을 24시간으로 늦춘 다음 모든 클라이언트가 느린 새 TTL을 가지고 있다는 점을 확인한 후, 레코드 값을 바꿔서 모두에게 업데이트가 되면 TTL을 올리는 식이다.

(출처 : 구글이미지)

• 클라이언트가 DNS route 53와 웹 서버에 접속한다고 생각해보자
    - myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받는다. 
      회신 내용으로는 A 레코드와 IP 주소 그리고 TTL이 있으며 TTL은 300초 정도 된다고 한다. 
    - TTL은 클라이언트에게 이 결과를 캐시하도록 요청한다. (300초의 TTL동안)
    - 300초 동안 클라이언트는 결과를 캐시한다.
      즉, 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우, 클라이언트는 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미이다.(이미 답변을 캐시에 저장했기 때문에 답을 알고 있으니깐)
    - 하지만 캐시에도 시간이 소요되니 캐시 TTL이 발생한다. DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않는 것이다.(레코드는 그렇게 자주 바뀌지 않는다. 이미 저장된 답변을 이용함으로써 웹 서버에 접속이 가능하며 HTTP 요청 및 회신을 보낼 수 있다.)