[도메인 주도 설계로 시작하는 마이크로서비스 개발] 다양한 서비스의 등록 및 탐색을 위한 서비스 레지스트리, 서비스 디스커버리 패턴

 

1) 서비스 디스커버리 패턴이란?

- 프런트엔드 클라이언트가 여러 개의 백엔드 마이크로서비스를 어떻게 호출해야 할까?

  또한 스케일 아웃을 통해 인스턴스가 여러 개로 복제됐다면

  어떻게 부하를 적절히 분산할 수 있을까? 

 

- 이를 위한 패턴이 서비스 디스커버리(Service Discovery) 패턴이다.

  클라이언트가 여러 개의 마이크로서비스를 호출하기 위해서는 최적 경로를 찾아주는 라우팅 기능과

  적절한 부하 분산을 위한 로드 밸런싱 기능이 제공돼야 한다. 

  넷플릭스의 OSS로 예를 들면 라우팅 기능은 줄(Zuul)이, 로드 밸런싱은 리본(Ribbon)이 담당한다. 

 

- 라우터는 최적 경로를 탐색하기 위해 서비스 명칭에 해당하는 IP 주소를 알아야 한다.

  그런데 이러한 라우팅 정보를 클라이언트가 가지고 있으면 

  클라우드 환경에서 동적으로 변경되는 백엔드의 유동 IP 정보를 매번 전송받아 변경해야 한다.

 

- 따라서 제3의 공간에서 이러한 정보를 관리하는 것이 좋다.

  즉, 백엔드 마이크로서비스 서비스의 명칭과 유동적인 IP 정보를 매핑해서 보관할 저장소가 필요하다.

  넷플릭스의 OSS의 유레카(Eureka)가 그 기능을 담당하고,

  이러한 패턴을 서비스 레지스트리 패턴이라 한다. 

-

 

- 위의 그림처럼 각 서비스 인스턴스가 로딩될 때,

  자신의 서비스 이름과 할당된 IP 주소를 레지스트리 서비스에 등록한다.

  그런 다음, 클라이언트가 해당 서비스명을 호출할 때,

  라우터가 레지스트리 서비스를 검색해 해당 서비스의 이름과 매핑된 IP 정보를 확인한 후 호출한다. 

 

- 이 레지스트리 서비스는 모든 마이크로서비스의 인스턴스의 주소를 알고 있는 서비스 매핑 저장소가 된다.

  모든 마이크로서비스가 처음 기동할 때 자신의 위치 정보를 저장하고,

  서비스가 종료될 때 위치 정보가 삭제된다. 

 

- 서비스 레지스트리에는 업무 처리를 위한 마이크로서비스뿐만 아니라 

  관리와 운영을 위한 기반 서비스의 주소도 함께 보관한다.

  예를 들면, Config 서비스, 모니터링 서비스, 추적 서비스도 모두 이름을 가지고 있기 때문에

  주소를 가지고 있어야 한다. 

 

- 스프링 유레카로 레지스트리 서비스를 구현하면, 서비스 이름과 IP 포트 정보가 매핑된다.

  특히, 다수의 인스턴스가 하나의 서비스 이름으로 등록될 때, 

  다수의 IP 주소와 포트 정보가 매핑되고, 라우터는 이 정보를 질의해서 로드밸런싱도 할 수 있다.