[MSA] Spring Cloud를 사용해보자(2)-서비스디스커버리
MSA는 각각 흩어진 서비스간의 원격 호출로 구성된다.
원격 호출을 하기위해 각각 서버에 대한 IP와 PORT를 이용한다.
기존 하드웨어 기반의 시스템에서의 서비스 인스턴스는 상대적으로 정적이다.
그러나 최근 많이 사용하는 클라우드 기반 환경에선 네트워크 정보가 동적으로 바뀔 수 있다.
그러면 이런 동적으로 변하는 네트워크 정보를 어떻게 관리해야할까? 유용하게 쓰는 방법이 있다.
MSA처럼 흩어져있는 분산시스템들의 수시로 변하는 네트워크 정보에 관한 관리포인트를 줄이기 위해 사용하는 패턴이 서비스 디스커버리 패턴(Service Discovery) 이다.
- Service Discovery
| 각 서비스들의 네트워크 위치 정보(IP, Port)를 저장하고 관리하며 연결시켜준다. |
이러한 Service discovery 패턴을 구현하는 방법으로는 크게 Clientside Service discovery 방식과 Server side Service discovery 방식이 있다.
Client Side Discovery 패턴을 공부하며 클라이언트의 주체에 대해 혼동이 많았는데, 아래의 사진과 같이 클라이언트의 주체는 서비스를 요청하는 또 다른 서비스 인스턴스이다.
Netflix OSS는 클라이언트 측 검색 패턴의 좋은 예다. 그 중, 넷플릭스 유레카는 Service Registry역할을 하며, 서비스 인스턴스 등록을 관리하고 사용 가능한 인스턴스를 쿼리하기 위한 REST API를 제공해준다. Netflix 리본은 유레카와 연동되어 사용 가능한 서비스 인스턴스에게 요청을 로드밸런싱을 해주는 프로세스간 통신 클라이언트이다.
이 패턴의 장점과 단점을 알아보자.
먼저 장점은, 서비스 레지스트리만 있으면 되기 때문에 비교적 간단하다.
또한 클라이언트가 사용 가능한 서비스 인스턴스에 대해 알고 있기 때문에 알아서 로드 밸런싱을 할 수 있다.
반면에, 이 패턴의 한 가지 중요한 단점은 클라이언트가 서비스 레지스트리에게 의존성을 가진다는 점이다.
즉, 각 서비스마다 서비스레지스트리를 구현해야하며, 만약 서비스마다 다른 언어를 사용하고 있다면 언어별 또는 프레임워크별로 구현해야 한다.
2) Server Side Service Discovery
서비스 앞에 일종의 proxy 서버 (로드밸런서)를 넣어, 서비스 클라이언트는 이 로드밸런서를 호출하면 로드밸런서가 Service registry로 부터 등록된 서비스의 위치를 리턴하고, 이를 기반으로 라우팅을 하는 방식이다.
Server Side Service Discovery 패턴의 예로는 Aws ELB와 구글 로드밸런서가 있다. 각각의 프록시 서버가 서비스 레지스트리를 통해 인스턴스를 질문하고 요청을 로드밸런싱을 해준다.
Server Side Service Discovery 패턴에는 몇 가지 이점과 단점이 있다. 이 패턴의 한 가지 큰 장점은 검색 세부 사항이 클라이언트에서 추상화된다는 점이다. 클라이언트는 단순히 프록시 서버에 요청을 하면 서비스 클라이언트에서 사용하는 각 프로그래밍 언어 및 프레임워크 별로 구현할 필요가 없다.
이에 반해 로드 밸런서가 설정 및 관리해야 하는 또 다른 가용성 시스템 구성 요소라는 점이 관리포인트가 늘어나게 된다.
참고