Service Discovery

서비스 인스턴스가 늘고 줄고 교체될 때마다 호출하는 쪽이 매번 실제 주소를 알아야 한다면 운영이 금방 깨집니다. 특히 컨테이너와 오토스케일링 환경에서는 어제의 주소가 오늘은 무의미할 수 있습니다. 고정 주소를 전제로 한 설계는 이런 동적 환경과 잘 맞지 않습니다. Service Discovery는 이름과 실제 위치를 분리해 이 불안정을 흡수합니다.

서버가 오래 고정되어 있던 시절에는 주소를 설정 파일에 직접 넣어도 큰 문제가 아니었습니다. 하지만 클라우드와 컨테이너가 보편화되면서 인스턴스는 자주 교체되고 자동으로 늘었다 줄었다 하게 됐습니다. 그 결과 '서비스 이름은 안정적이지만 실제 위치는 계속 변한다'는 전제를 시스템이 직접 흡수해야 했고, Service Discovery가 핵심 기반으로 떠올랐습니다.

서비스는 자신을 레지스트리에 등록하거나 플랫폼이 대신 등록해 주고, 호출하는 쪽은 서비스 이름을 기준으로 현재 유효한 인스턴스를 찾습니다. 여기에 헬스체크가 결합되어 죽은 인스턴스는 목록에서 빠지고 새 인스턴스는 자동으로 반영됩니다. 핵심은 호출자가 매번 구체 주소를 외우지 않아도 현재 살아 있는 대상을 찾을 수 있다는 점입니다.

Service Discovery와 API Gateway는 모두 '어디로 보낼까'라는 질문과 맞닿아 있지만, Service Discovery는 내부 호출의 대상 주소를 해결하는 메커니즘이고 API Gateway는 외부 요청을 어떤 서비스로 라우팅할지 정리하는 접점입니다. 하나는 서비스 간 호출의 기반이고, 다른 하나는 클라이언트와 백엔드 사이의 문입니다.

오토스케일링되는 서비스, 롤링 배포가 잦은 플랫폼, 서비스 메시나 컨테이너 오케스트레이션 환경에서는 Service Discovery가 거의 기본 기능처럼 필요합니다. 이를 통해 호출하는 쪽은 실제 주소보다 서비스 이름에 의존할 수 있고, 운영자는 배포와 복구를 더 유연하게 다룰 수 있습니다. 다만 이름 해석이 보이지 않는다고 해서 장애가 사라지는 것은 아니므로, 상태와 헬스체크를 함께 운영해야 합니다.

다음에 볼 개념

함께 보면 좋은 개념