서비스 디스커버리(Service Discovery)

Service Discovery란?

마이크로서비스 아키텍처(MSA)로 구성되어 있는 서비스들은 각자 다른 IP와 포트를 가지고 있다. 수많은 서비스의 IP와 포트 정보에 대해서 저장하고 관리하는 것이 필요하다.

클라우드에서 인스턴스는 동적으로 할당되기 때문에 IP주소나 포트 정보가 정해지지 않은 데다가 오토스케일링도 일어나고 중지되고 복구되면서 네트워크 위치가 지속적으로 변경된다.
따라서 클라이언트나 API 게이트웨이가 호출할 서비스를 찾기 위해 서비스 디스커버리(Service Discovery)가 필요하다. 서비스 디스커버리는 클라이언트 사이드 디스커버리 패턴(Client-Side Discovery Pattern)과 서버 사이드 디스커버리 패턴(Server-Side Discovery Pattern)으로 나눌 수 있다.

 

클라이언트 사이드 디스커버리

서비스 인스턴스의 네트워크 위치를 찾고 로드밸런싱하는 역할을 클라이언트가 담당하는 방식이다.

서비스 인스턴스는 네트워크 주소를 서비스 레지스트리(Service Registry)에 등록하고, 서비스 레지스트리는 각 서비스 인스턴스의 상태를 계속해서 체크한다. 클라이언트는 서비스 레지스트리에 등록된 인스턴스 중 하나를 골라서 요청을 보내는 방식으로 로드밸런싱이 이루어진다. 인스턴스가 종료되면 서비스 레지스트리에 등록된 정보는 삭제된다.
클라이언트 사이드 디스커버리 패턴의 예시로는 Netflix OSS가 있다. Netflix Eureka는 서비스 레지스트리로 서비스 인스턴스의 등록과 가용한 인스턴스를 찾는 REST API 를 제공한다. Netflix Ribbon은 Eureka와 같이 동작하는 IPC 클라이언트로, 서비스가 가능한 서비스 인스턴스 간 로드밸런싱을 해준다.

장점

• 비교적 간단하다.
• 디스커버리 로직을 클라이언트가 클라이언트가 가지고 있기 때문에 서비스에 맞는 로드밸런싱 방식을 각자 구현할 수 있다.

단점

• 클라이언트와 서비스 레지스트리가 연결되어 있어서 종속적이다.
• 서비스 클라이언트에서 사용하는 각 프로그래밍 언어 및 프레임워크별로 클라이언트 측 서비스 검색 로직을 구현해야 한다.

 

서버 사이드 디스커버리

서버 쪽에서 디스커버리 로직을 구현한 방식이다.

클라이언트가 로드밸런서로 요청을 보내면 로드밸런서는 서비스 레지스트리를 조회해서 가용한 인스턴스를 찾고 그 중 선택해서 요청을 라우팅하는 방식이다. AWS Elastic Load Balancer(ELB)가 서버 사이드 서비스 디스커버리 패턴의 예이다. 클라이언트에서 DNS 이름을 이용해 ELB로 요청을 보내면 ELB는 등록된 EC2 인스턴스나 ECS 컨테이너 사이에서 부하를 분산하며, 서비스 레지스트리 역할도 한다.
Kubernetes 환경에서는 클러스트 내 호스트 별로 프록시(proxy)를 실행한다. 이 프록시는 서버 쪽 서비스 디스커버리의 역할을 하며 클러스트 내에 가용한 서비스 인스턴스로 요청을 포워딩한다.

 

장점

• 디스커버리의 세부 사항이 클라이언트로부터 분리되어 있다. (의존성 ↓)
• 클라이언트는 단순히 로드 밸런서에 요청만 하므로, 각 프로그래밍 언어 및 프레임 워크에 대한 검색 로직을 구현할 필요가 없다.
• 일부 배포환경에서는 이 기능을 무료로 제공한다

단점

• 로드밸런서가 배포환경에서 제공되어야 한다.
• 서비스 디스커버리가 죽으면 전체 시스템이 동작하지 않으므로, 고가용성 등 더 많은 관리가 필요하다.

 

서비스 레지스트리

서비스 레지스트리는 각 서비스 인스턴스의 네트워크 위치 정보를 저장하는 데이터베이스로 항상 최신 정보를 유지해야 하며 고가용성이 필요하다. Netflix Eureka는 서비스 인스턴스를 등록하고 조회하는 API를 제공하는데, 각 서비스 인스턴스는 POST 요청으로 자신의 네트워크 위치를 등록하고 30초마다 PUT 요청으로 자신의 정보를 갱신한다. 등록된 서비스 정보는 DELETE 요청이나 타임 아웃으로 삭제된다. 그리고 등록된 서비스 정보는 GET 요청으로 조회 가능하다.

 

서비스 등록

서비스 레지스트리에 정보를 등록하고 해제하는 데에는 서비스 스스로 등록을 관리하는 셀프 등록 패턴(Self Registration Pattern)과 제3의 시스템에서 등록을 관리하는 써드 파티 등록 패턴(3rd Party Registration Pattern)이 있다.

 

셀프 등록 패턴

 

등록과 관리의 주체가 서비스인 방식으로, 각 서비스는 서비스 레지스트리에 자신의 정보를 등록하고 주기적으로 자신이 살아있다는 신호를 전송한다. 만약 이 정보가 일정 시간이 지나도 오지 않는다면 서비스에 문제가 발생한 것으로 보고 등록이 해제되며, 종료될 때에도 등록을 해제한다.

이 방식은 다른 컴포넌트 없이 간단하게 구성할 수 있다는 장점이 있지만, 각 서비스에서 서비스 등록 로직을 구현해야 한다는 단점이 있다.

 

써드 파티 등록 패턴

서비스 등록을 관리하는 서비스 레지스트라(Service Registrar)를 따로 외부에서 서비스 등록을 관리하는 방법이다.  서비스 레지스트라는 각 서비스 인스턴스의 변화를 폴링(polling)이나 이벤트 구독으로 감지해서 서비스 레지스트리에 계속 업데이트한다.

이런 방식의 서비스에서 서비스 등록 및 관리 로직을 분리할 수 있다는 점, 중앙에서 통제가 가능하다는 장점이 있다. 반대로 서비스 레지스트라가 멈추면 안되기 때문에 고가용성 등 더 많은 관리가 필요한 단점이 있다.

[출처]

https://futurecreator.github.io/2018/10/18/service-discovery-in-microservices/

마이크로서비스 Microservices (4) 서비스 디스커버리

https://bcho.tistory.com/1252

MSA에서 Service discovery 패턴

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=ithink3366&logNo=221368902485

[Service Discovery] Service Discovery 란?

https://mangchhe.github.io/springcloud/2021/04/07/ServiceDiscoveryConcept/

Service Discovery란?