DNS 변경은 이름 질의 결과를 바꾸는 제어면 작업이지, 이미 열린 연결을 이동시키는 명령이 아닙니다. 전환을 판단하려면 권한 응답·캐시·앱 resolver·연결 풀·실제 원격 IP를 각각 관찰해야 합니다.
주소 변경과 기존 연결 재사용
권한 DNS를 옛 IP에서 새 IP로 바꿨는데 일부 클라이언트가 계속 옛 서버로 요청한다고 합시다.
한 요청의 trace를 pool hit(옛 IP)와 새 연결 필요→resolver cache hit(옛 IP)와 새 질의→새 IP로 나누면 원인이 보입니다. 권한 DNS가 새 값을 반환한다는 확인만으로는 기존 pool의 요청이 전환됐다고 말할 수 없습니다. 전환 완료 조건에는 새 연결 성공뿐 아니라 옛 연결의 신규 대여 중단, 진행 중 요청 drain, 오류·롤백 경로를 넣어야 합니다. 새 질의는 새 주소를 받아도 이미 얻은 DNS 답과 이미 열린 TCP·HTTP 연결은 남을 수 있습니다. DNS 변경은 모든 클라이언트의 소켓을 이동시키는 명령이 아닙니다.
전환을 확인할 때는 제어면의 새 DNS 응답과 데이터면의 실제 원격 IP를 분리해야 합니다. 새 주소를 조회했지만 풀에서 옛 연결을 빌린 상황을 DNS 오류로 고치려 하면 원인을 놓칩니다.
DNS 전환 경로 네 층의 시간
| 층 | 보존하는 것 | 확인할 정보 |
|---|---|---|
| 권한 DNS | 현재 레코드 | 응답 값·레코드 유형·TTL |
| 재귀 resolver·OS | 이전 질의 결과 | 사용 resolver·남은 TTL·부정 응답 |
| 런타임·앱 | 자체 주소·실패 캐시 | 캐시 정책·갱신 시점 |
| 연결 풀 | 이미 열린 연결 | 원격 IP·생성 시각·유휴·최대 수명 |
그림을 글로 읽기
- HTTP 요청
- 기존 연결 재사용: 옛 IP 소켓이 남을 수 있음
- 새 연결 생성: 캐시 또는 새 DNS 질의
- 실제 원격 서버: 원격 IP를 직접 관찰
- HTTP 요청 → 기존 연결 재사용: 풀 hit
- HTTP 요청 → 새 연결 생성: 새 연결 필요
- 기존 연결 재사용 → 실제 원격 서버: 같은 소켓
- 새 연결 생성 → 실제 원격 서버: 새 주소 연결
낮은 TTL의 사전 적용 조건
기존 TTL이 한 시간이었는데 전환 직전에 30초로 낮춰도 이미 한 시간짜리 답을 받은 캐시는 그 변경을 모릅니다. 계획된 전환은 먼저 TTL을 낮추고 이전 답의 보존 시간이 소진될 여유를 둔 뒤 주소를 바꿉니다. 모든 구현의 실제 캐시가 설정을 그대로 따르는지도 확인해야 합니다.
새 서버의 TLS 이름·인증서·애플리케이션 readiness를 먼저 준비하고 양쪽이 동시에 요청을 받을 기간의 데이터·버전 호환을 유지합니다. 옛 서버 제거는 DNS TTL 경과뿐 아니라 잔존 활성 연결·신규 요청·실패 복구 경로를 보고 판단합니다. 롤백도 즉시 전파되는 것이 아니므로 같은 잔존 기간이 반대 방향으로 생깁니다.
연결 최대 수명과 유휴 수명의 목적 구분
풀에서 사용하지 않는 연결을 정리하는 유휴 수명과, 계속 사용되어도 옛 주소나 인증 상태를 붙잡는 연결을 교체하는 최대 수명은 목적이 다릅니다. 최대 수명에 도달한 연결을 진행 중 요청과 함께 끊으면 결과가 불확정해질 수 있으므로, 먼저 신규 대여를 막고 현재 요청이 끝나기를 기다린 뒤 연결을 닫아 교체합니다. 이것이 이 연결을 드레이닝하는 과정입니다.
모든 인스턴스가 같은 시각에 교체하면 DNS·TLS·서버 수락 부하가 몰리므로 수명에 지터를 넣고 교체 동시성도 제한합니다. 낮은 TTL과 짧은 연결 수명은 전환을 앞당길 수 있지만 이름 서비스와 handshake 비용을 늘리므로, 즉시 전환이 필요하면 DNS만으로 약속하지 않고 로드밸런서·서비스 발견·연결 배출 계약을 함께 설계합니다.
이름 부재와 음성 DNS 캐시
새 이름을 만들기 전에 조회해 NXDOMAIN을 받았다면 이후 레코드를 생성해도 부재 응답이 캐시에 남을 수 있습니다. 이름 자체 부재와 특정 유형의 데이터 부재를 구분하고 SOA 등 관련 음성 캐시 규칙을 확인합니다. SERVFAIL 같은 오류의 캐시·재시도도 단순 부재와 같지 않습니다.
권한 서버에는 새 레코드가 있지만 재귀 경로에서는 부정 응답일 수 있고, 앱이 자체 실패 캐시를 유지할 수도 있습니다. 양성 레코드 TTL만 바꾼다고 모든 부정 캐시가 소급 만료되는 것은 아닙니다. 도메인을 배포 전에 준비하고 실제 클라이언트의 resolver 경로에서 확인하는 편이 안전합니다.
후보 주소 경쟁과 제한된 병렬 연결
IPv6 경로가 느리거나 끊겼을 때 그 실패 timeout 전체를 기다린 뒤 IPv4를 시도하면 사용자 지연이 큽니다. Happy Eyeballs는 주소 해석·정렬과 적절한 간격의 제한된 연결 경쟁으로 한 경로의 긴 대기를 줄입니다. 정확한 간격과 승자 판정은 사용하는 클라이언트 구현을 확인해야 합니다.
먼저 연결된 후보를 선택한 뒤 패자의 소켓·타이머·완료를 정리합니다. 연결 경쟁을 여러 서버에 주문 본문을 중복 보내는 것과 혼동하지 않습니다. TCP 연결 성공과 TLS 인증 성공은 다르며 인증 오류를 단순 속도 문제처럼 무조건 우회하지 않습니다.
Registry Watch와 현재 상태 복구
서비스 registry에서 endpoint를 제거해도 client의 watch·cache·연결 풀이 즉시 바뀌지 않습니다. watch가 끊긴 동안 삭제 이벤트를 놓쳤다면 저장된 revision부터 재생 가능한지, 보관 범위를 벗어나 전체 snapshot을 다시 읽어야 하는지 계약을 확인합니다. heartbeat 만료는 장애 의심이며 그 프로세스가 실제로 종료됐다는 증명은 아닙니다.
registry의 drain 상태와 앱의 신규 수락 차단·기존 요청 종결을 연결합니다. client는 삭제된 endpoint로 새 연결을 만들지 않게 하되 진행 중 변경은 성공·취소·불확정으로 정확히 처리합니다. 발견 목록 최신성과 앱의 실제 DB·queue 준비도 별도입니다. 재탐색·재연결은 전체 deadline·retry budget·jitter로 제한해 registry 장애 복구 때 재조회 폭주가 생기지 않게 합니다.
실제 전환 로그 기반 판단
TTL 감소 전 답을 캐시한 클라이언트, 새로 실행한 클라이언트, 기존 풀 연결을 유지한 클라이언트를 나누어 주소 전환을 시험합니다. 부재 조회 후 생성, IPv6 경로 지연, 동시 연결 교체도 별도입니다. 기록에는 DNS 응답·실제 원격 IP·연결 생성 시각·재사용 여부·요청 성공을 함께 남깁니다.
이 노트의 절차는 테스트 계획이며 실제 운영 DNS 전환을 수행한 결과는 아닙니다. 이름이 새 주소를 가리킨다는 사실과 모든 요청이 안전하게 새 서버로 옮겨갔다는 사실을 구분해야 합니다.