서비스 레지스트리에서 인스턴스를 제거했는데 요청이 계속 갑니다. 발견과 연결 수명은 어떻게 분리하나요?

레지스트리 상태 변경과 client 캐시·DNS·연결 풀·로드밸런서 반영 시점은 다릅니다. 목록에서 제거했다고 이미 열린 연결과 진행 요청이 즉시 사라지지 않습니다.

동작 원리와 전제

새 연결의 endpoint 선택과 기존 연결의 재사용을 각각 확인합니다. TTL·watch 지연·업데이트 유실에 대비해 현재 상태 재조회 경로를 둡니다. heartbeat 만료는 장애 의심이며 인스턴스가 실제로 죽었다는 증명은 아닙니다.

선택과 실패 처리

drain 상태를 먼저 표시하고 새 작업 수락을 막은 뒤 기존 작업을 정리합니다. client는 실패 endpoint를 제한적으로 재탐색하되 전체 요청 deadline과 재시도 예산을 유지합니다. 모든 인스턴스가 동시에 재조회하면 레지스트리가 병목일 수 있어 지터·캐시가 필요합니다.

구체적인 사례와 검증

레지스트리의 watch가 끊겼다가 복구되면 누락 이벤트를 모두 재생할 수 있는지와 현재 전체 snapshot을 다시 읽어야 하는지 확인합니다. 삭제 이벤트 하나를 놓치고 이전 endpoint를 계속 쓰면 health 실패와 재시도가 반복될 수 있습니다. discovery 캐시의 수명과 연결 풀의 최대 수명을 따로 관리하고 제거된 endpoint에는 새 연결을 만들지 않도록 합니다. 하지만 이미 처리 중인 변경은 정상 완료·취소·불확정 상태로 마무리해야 합니다. endpoint 목록이 최신이라는 사실과 그 인스턴스의 DB·큐가 준비됐다는 사실도 다르므로 실제 요청 결과와 readiness를 함께 관찰합니다.

제거·네트워크 분할·watch 재연결·오래된 풀·새 인스턴스를 시험합니다. 요청이 어디로 갔는지 실제 주소와 버전을 남깁니다. 발견된 endpoint가 현재 요청을 처리할 준비가 됐다는 보장도 별도 health 계약입니다.