DNS를 새 서버 주소로 바꿨는데 일부 클라이언트는 계속 이전 서버에 접속합니다. 왜 그렇고 언제 이전 서버를 내려도 되나요?

DNS 레코드를 바꿔도 일부 클라이언트는 일정 시간 이전 서버에 계속 접속할 수 있습니다. 새 조회 결과만 바뀌며, 리졸버·운영체제·런타임 캐시와 이미 맺은 TCP 연결·HTTP 연결 풀을 강제로 이동시키지 않기 때문입니다. 롤백도 마찬가지로 즉시 전파된다고 약속할 수 없습니다.

조회 캐시와 연결 수명을 나눠 본다

DNS 응답에는 TTL이 있고 재귀 리졸버와 클라이언트가 그 기간 동안 답을 재사용할 수 있습니다. 이미 주소를 얻어 연결한 HTTP/1.1 keep-alive와 HTTP/2 연결은 DNS를 다시 거치지 않고 계속 요청을 보낼 수 있습니다. 이 둘을 구분하는 것이 핵심이며, TTL은 연결 수명이 아닙니다. 존재하지 않는 이름에 대한 negative caching도 복구를 늦출 수 있으므로, 권한 DNS가 고쳐졌다는 사실만으로 모든 실패가 사라진다고 보지 않겠습니다. 이를 이름 해석 캐시(DNS caching)와 연결 재사용(connection reuse)이라는 별도 현상으로 보겠습니다.

장애 전환 중에는 클라이언트가 받은 DNS 답뿐 아니라 실제 원격 IP, 연결 생성 시각, 연결 풀의 유휴·최대 수명을 함께 측정합니다. 새 조회는 새 서버로 가는데 기존 연결만 이전 서버에 남는다면 DNS 문제가 아니라 연결 배출 정책 문제입니다. 반대로 새 조회도 예전 주소라면 클라이언트가 어느 리졸버를 사용하는지와 캐시 만료를 확인합니다. 낮은 TTL만으로 연결 풀이 재연결되는 것은 아니므로, 실패한 연결에서 재조회하는 규칙과 최대 연결 수명을 별도로 둡니다.

안전한 전환과 롤백

계획된 교체라면 변경 전에 TTL을 낮출 시간을 확보하고, 새 주소를 등록한 뒤 양쪽 서버의 신규 요청 비율과 오류율을 관찰합니다. 이전 서버는 캐시된 답이 남을 수 있는 시간뿐 아니라 기존 연결이 자연스럽게 종료되거나 배출될 때까지 유지하겠습니다. 연결 최대 수명을 모든 인스턴스가 같은 시각에 만료시키면 재연결 폭주가 생기므로 만료를 분산합니다. 실패 시에는 새 연결이 어느 주소로 향하는지와 재시도 대상이 안전한 요청인지 확인합니다.

즉시 전환이 SLO의 핵심이면 DNS만으로 약속하지 않고 로드밸런서의 상태 제거, 짧은 연결 수명, 명시적 드레이닝을 조합하겠습니다. TTL을 과도하게 낮추면 조회 부하와 DNS 의존성이 커집니다. 롤백할 때도 같은 전환 절차를 역방향으로 적용하고, 롤백 직후에도 새 조회·기존 캐시·기존 연결이 서로 다른 주소를 가리킬 수 있다는 전제를 유지합니다.

운영 판단에서는 DNS 서버가 새 값을 반환한다는 제어면 증거와 애플리케이션의 실제 접속 대상이 바뀌었다는 데이터면 증거를 나누겠습니다. 리졸버 질의 결과가 새 IP인데 연결 풀의 소켓 원격 주소가 옛 IP라면 레코드를 다시 고치지 않고 풀 수명·드레인 정책을 조정합니다. 이전 서버를 내릴 조건은 TTL이 지났다는 사실만이 아니라 허용된 잔존 캐시 기간, 이전 주소의 활성 연결·신규 요청 감소, 복구 경로가 확인된 때입니다. 가중 DNS의 요청 비율도 캐시와 연결 재사용 때문에 가중치와 정확히 같지 않습니다.

추가 조건과 판단

TTL을 낮추는 시점도 중요합니다. 기존 TTL이 한 시간이었는데 전환 직전에 30초로 바꿔도, 이미 한 시간짜리 답을 받은 캐시는 그 변경을 모릅니다. 계획된 교체에서는 이전 TTL이 소진될 시간을 먼저 확보해야 합니다. 서버 주소를 되돌린 뒤에도 새 주소를 캐시한 사용자는 남아 있으므로 양쪽의 호환성과 데이터 쓰기 책임을 유지해야 합니다. 단순히 두 서버를 동시에 살려 두는 것으로 충분하지 않고, 두 버전이 같은 주문을 처리해도 중복이나 상태 분기가 생기지 않는지 확인하겠습니다.