DNS 레코드에 적합한 TTL 선택하기

모든 DNS 레코드에는 대부분의 사람들이 한 번 설정하고 잊어버리는 숫자가 들어 있습니다: 바로 Time To Live입니다. 초 단위로 측정되는 이 값은 인터넷의 모든 리졸버에게 다시 확인하기 전까지 이 응답을 얼마나 오래 신뢰할 수 있는지 알려줍니다.

TTL은 미래에 대한 내기입니다. 짧은 TTL은 "곧 변경될 수 있다"는 뜻이고, 긴 TTL은 "이건 안정적이니 믿어도 된다"는 뜻입니다. 초를 더할수록 확신이 늘어나고, 초를 줄일수록 여유를 두는 셈입니다.

한 방향으로 잘못 설정하면, 하루에 수백만 번 같은 질문에 답하느라 자원을 낭비하게 됩니다. 반대 방향으로 잘못 설정하면, 토요일 아침에 IP 주소를 변경하고 나서 다음 24시간 동안 사용자들이 새 서버로 서서히 넘어오는 것을 속수무책으로 지켜봐야 합니다 — 일요일이 되도록 일부 사용자는 여전히 오래된, 더 이상 사용하지 않는 주소로 접속하게 됩니다.

트레이드오프

짧은 TTL (60-300초) 은 변경 사항이 몇 분 안에 전파됩니다. IP 주소를 업데이트하면 거의 즉시 전 세계에 반영됩니다. 그러나 리졸버는 여러분의 네임서버에 끊임없이 쿼리를 보내야 합니다. 트래픽이 늘어납니다. 캐시된 응답이 사용자가 혜택을 누리기 전에 만료되므로 조회 속도가 약간 느려집니다.

긴 TTL (3600-86400초) 은 네임서버가 쿼리의 일부만 처리합니다. 리졸버는 응답을 몇 시간 또는 며칠 동안 캐시합니다. 사용자는 캐시에서 즉각적인 응답을 받습니다. 하지만 무언가를 변경하면? 그 상태로 묶여버립니다. 잘못된 서버를 가리키고 있다면, 기다리는 수밖에 없습니다.

최적의 TTL은 한 가지 질문에 달려 있습니다: 이 레코드가 변경될 가능성이 얼마나 되며, 변경이 느릴 경우 얼마나 큰 문제가 생기는가?

안정성에 따른 TTL

매우 안정적인 인프라 (86400-172800초)

몇 달 동안 변경된 적이 없고 충분한 계획 없이는 변경되지 않을 경우:

• 전용 서버: 설치 이후 동일한 IP 주소를 유지해온 서버
• 메일 서버: 안정적인 인프라에서 운영 중인 서버 — 이메일은 캐싱을 잘 견딤
• 네임서버 레코드 (NS): 권한 있는 DNS를 가리키는 레코드 — 몇 년에 한 번 정도 변경될까 말까 함

24-48시간 TTL은 리졸버가 여러분의 서버를 거의 건드리지 않게 합니다. 인터넷이 여러분의 응답을 신뢰합니다.

프로덕션 서비스 (3600-7200초)

대부분의 프로덕션 워크로드가 여기에 해당합니다:

• 클라우드 호스팅 애플리케이션: IP를 변경하지 않을 가능성이 높지만, 변경할 수도 있는 경우
• API 엔드포인트: 페일오버나 로드 밸런싱 조정이 필요할 수 있는 경우
• CDN CNAME: 제공업체가 가끔 인프라를 교체하는 경우

1-2시간은 DNS 쿼리 폭주 없이 유연성을 제공합니다.

자주 변경되는 리소스 (300-900초)

• 개발 및 스테이징 환경: 배포가 수시로 일어나는 경우
• 동적 DNS: IP 주소가 자주 바뀌는 연결의 경우
• 로드 밸런서 풀: 비정상 서버를 빠르게 제거해야 하는 경우

5-15분이면 작업 흐름을 막지 않을 만큼 빠르게 변경 사항이 전파됩니다.

페일오버가 중요한 시스템 (60-300초)

몇 분간의 다운타임이 심각한 손실을 초래할 때:

• 재해 복구: 백업 데이터 센터로 즉시 트래픽을 전환해야 하는 경우
• 헬스체크 기반 DNS: 장애를 자동으로 우회하는 경우

1-5분이면 대부분의 사용자가 TTL 사이클 몇 번 안에 올바른 위치에 도달합니다.

마이그레이션 전 TTL 조정

여기가 TTL 전략이 실제로 빛을 발하는 지점입니다.

다음 주 토요일에 서버를 마이그레이션할 예정입니다. A 레코드의 TTL은 86400초 — 24시간입니다. 토요일 아침에 IP 주소를 변경하면, 일부 사용자는 일요일 아침이 되어서야 새 IP를 확인합니다. 이미 기존 서버는 오프라인입니다. 그 사용자들은 오류를 보게 됩니다.

문제는 이렇습니다: 리졸버가 레코드를 캐시하고 나면, TTL이 만료될 때까지 다시 묻지 않습니다. 전 세계 리졸버에 접근해 캐시를 지울 방법은 없습니다. 이것이 여러분이 가진 유일한 수단이며 — 필요하기 전에 미리 활용해야 합니다.

해결책: 필요하기 전에 TTL을 낮춰두세요.

1. 1주일 전: TTL을 86400초에서 300초로 변경합니다. IP 주소는 아직 건드리지 마세요.
2. 기존 TTL이 완전히 만료될 때까지 기다립니다: 86400초에 캐시된 모든 리졸버가 만료되어야 합니다. 이 과정은 원래 TTL 기간인 최소 24시간이 걸립니다 — 하지만 여유를 두기 위해 1주일 일찍 진행하는 것입니다.
3. 마이그레이션 진행: 이제 모든 리졸버가 5분마다 확인합니다. IP를 변경하면 몇 분 안에 전 세계에 반영됩니다.
4. 확인: 새 서버로 트래픽이 올바르게 도달하는지 확인합니다.
5. TTL 복원: 효율적인 장기 운영을 위해 86400초로 되돌립니다.

1주일을 기다리는 것이 과하게 느껴질 수 있습니다. 하지만 그렇지 않습니다. DNS 캐싱은 전 세계 수백만 개의 리졸버에 분산되어 있으며, 각각 자체적인 타이밍을 가지고 있습니다. 그리고 불편한 진실이 있습니다: 일부 리졸버는 TTL 값을 완전히 무시하고 지정한 것보다 더 오래 캐시합니다¹. 이 여유 기간은 편집증이 아닙니다. 여러분이 완전히 통제할 수 없다는 인정입니다.

레코드 유형별 TTL

A 및 AAAA 레코드: 인프라 안정성에 따라 완전히 다릅니다. 정적 전용 서버라면 86400초, 클라우드 인스턴스라면 3600초.

CNAME 레코드: 다른 사람의 인프라를 가리키고 있습니다. 그들의 TTL과 같거나 낮게 설정하세요 — 목적지 캐시 시간보다 포인터를 더 오래 캐시하는 건 의미가 없습니다. CNAME의 TTL이 86400초인데 대상 A 레코드의 TTL이 300초라면, 긴 TTL이 짧은 TTL의 효과를 무력화합니다.

MX 레코드: 이메일 인프라는 설계상 안정적입니다. 86400초가 표준입니다. 메일 전달은 캐싱을 잘 견딥니다.

TXT 레코드: SPF와 DKIM은 거의 변경되지 않으므로 86400초. 곧 삭제할 인증 토큰은 3600초 이하.

NS 레코드: 권한 있는 네임서버는 거의 변경되지 않습니다. 172800초(48시간) 이상. 네임서버를 변경할 때는 TTL에 상관없이 신중하게 계획하게 됩니다.

실제 설정 예시

이커머스 플랫폼의 설정 예시:

데이터 센터 마이그레이션 전에는 1주일 앞서 www와 api의 TTL을 300초로 낮추고, 마이그레이션 후 확인한 다음 복원합니다.

DNS TTL 자주 묻는 질문

TTL을 너무 낮게 설정하면 어떻게 되나요?

권한 있는 네임서버가 더 많은 쿼리를 처리해야 합니다 — 경우에 따라 훨씬 더 많이. 대부분의 환경에서 이는 그냥 비효율입니다: 대역폭 비용 증가, 사용자에게 약간 더 높은 지연 시간. 트래픽이 많은 도메인에서는 매우 낮은 TTL(60초 미만)이 실제 부하 문제를 일으킬 수 있습니다. 더 큰 문제는 대개 낭비입니다: 레코드가 자주 변경되지 않는데 한 번도 쓰지 않을 유연성을 위해 비용을 치르는 것입니다.

TTL이 허용하는 것보다 더 빠르게 DNS 변경을 강제로 전파할 수 있나요?

아니요. 리졸버가 레코드를 캐시하고 나면 TTL이 만료될 때까지 다시 묻지 않습니다. 전 세계 리졸버에 접근해 캐시를 지울 방법은 없습니다. 이것이 계획된 변경 전에 TTL을 미리 낮춰야 하는 이유입니다 — 이것이 유일한 수단이며, 미리 활용해야 합니다. 위기 상황에서는 캐시된 TTL에 의존할 수밖에 없습니다.

일부 대형 서비스가 매우 짧은 TTL을 사용하는 이유는 무엇인가요?

Google이나 Cloudflare 같은 대규모 플랫폼은 부하, 지리적 위치, 상태에 따라 글로벌 인프라 전반에 걸쳐 트래픽을 지속적으로 라우팅하기 때문에 60-300초의 TTL을 사용합니다. 이들은 그 쿼리 볼륨을 처리할 DNS 인프라를 갖추고 있으며, 유연성이 필요합니다. 대부분의 조직은 그 규모로 운영되지 않으며 그런 유연성이 필요하지 않습니다.

모든 레코드에 동일한 TTL을 사용해야 하나요?

아니요. 레코드마다 변경 빈도가 다르고 오래된 데이터로 인한 결과도 다릅니다. 거의 변경되지 않는 네임서버를 가리키는 NS 레코드와 매일 변경되는 스테이징 환경 A 레코드가 같은 TTL을 가져서는 안 됩니다. 레코드가 가리키는 대상의 안정성에 맞게 TTL을 설정하세요.

마이그레이션 전에 TTL 낮추는 것을 잊어버리면 어떻게 되나요?

기다려야 합니다. 지름길은 없습니다. 레코드의 TTL이 24시간인데 지금 당장 변경해야 한다면, 일부 사용자는 최대 24시간 동안 이전 주소로 접속할 것입니다. 변경하고 전파 지연을 감수하거나, TTL을 낮추고 전파될 때까지 기다린 후 변경하면 되지만 — 그 대기 시간은 피할 수 없습니다. 이것이 마이그레이션 전 TTL 조정이 중요한 이유입니다: 긴급 상황을 계획된 작업으로 바꿔줍니다.

출처