Service Discovery

서비스를 배포할 때마다 새 IP가 생기고 오토스케일링으로 인스턴스 수가 변할 때, 호출하는 쪽이 매번 주소를 수동으로 갱신해야 한다고 생각해 보십시오. 롤링 배포 중에 절반은 구 버전, 절반은 신 버전인 상황에서 어느 주소로 요청을 보내야 하는지 설정 파일만으로는 따라가기 어렵습니다. 서비스가 2~3개일 때는 수동으로 버틸 수 있지만, 수십 개 서비스가 서로를 호출하기 시작하면 잘못된 주소로 요청이 쏠리거나 이미 죽은 인스턴스에 계속 연결을 시도하는 상황이 반복됩니다.

서버가 오래 고정되어 있던 온프레미스 환경에서는 설정 파일에 IP를 직접 넣어도 크게 문제가 없었습니다. 하지만 클라우드 환경에서 컨테이너 오케스트레이션이 확산되면서 인스턴스의 생애주기가 분 단위로 짧아졌습니다. 배포 자동화와 오토스케일링이 맞물리자 어제 설정한 주소가 오늘 새벽 스케일 다운으로 이미 사라져 있는 상황이 일상이 됐습니다. 운영자들은 배포할 때마다 호출 주소를 직접 찾아 고치는 대신, 이름만 안정적으로 유지하고 실제 위치 매핑은 플랫폼이 흡수해 주기를 원하게 됐고, Service Discovery가 그 역할을 맡게 됐습니다.

서비스 인스턴스가 시작되면 자신의 위치를 레지스트리에 등록하고, 종료되거나 헬스체크에 실패하면 목록에서 제거됩니다. 호출하는 쪽은 서비스 이름으로 레지스트리에 질의하고, 현재 유효한 인스턴스 목록 중 하나로 요청을 보냅니다. 클라이언트 측 방식에서는 호출자가 직접 선택하고, 서버 측 방식에서는 프록시나 로드밸런서가 선택을 대신합니다. 어느 쪽이든 핵심은 호출자가 실제 IP 대신 이름에만 의존하면 된다는 점이고, 인스턴스 교체나 수 조정은 레지스트리가 조용히 반영합니다.

Service Discovery와 API Gateway는 모두 요청이 어디로 가야 하는지와 맞닿아 있지만 다루는 레이어가 다릅니다. Service Discovery는 내부 서비스 간 호출에서 대상 인스턴스의 현재 위치를 해결하는 메커니즘이고, API Gateway는 외부 클라이언트의 요청을 받아 인증, 라우팅, 정책을 적용한 뒤 내부로 전달하는 접점입니다. 서비스 메시 환경에서는 사이드카 프록시가 Service Discovery를 내장해 두 역할이 겹쳐 보이기도 하지만, 하나는 내부 위치 해결이고 다른 하나는 외부 진입 제어입니다.

오토스케일링으로 인스턴스 수가 자주 변하거나, 롤링·카나리 배포로 여러 버전이 동시에 떠 있거나, 파드 교체가 빈번한 컨테이너 환경이라면 Service Discovery가 없으면 내부 호출이 쉽게 흔들립니다. 반대로 서비스 수가 적고 배포 주기가 길며 주소가 거의 고정된 환경이라면 레지스트리 운영 비용이 실익보다 클 수 있습니다. 도입한 뒤에는 이름 해결이 보이지 않는다는 점 때문에 장애 시 어느 인스턴스로 요청이 갔는지 추적하기 어려울 수 있으므로, 헬스체크와 관측 가능성을 함께 갖춰야 합니다.