요구사항
- 클라이언트는 각 서비스 인스턴스의 IP와 Port에 대해 모른다. 게이트웨이 서버 주소만 알면 된다.
- 게이트웨이는 각 서비스 인스턴스의 IP, Port에 대해 알지 못한다.
- 서비스 디스커버리만 각 서비스 인스턴스에 대한 정보를 알고 있다. 변경 사항도 이 곳에서만 적용하고 반영한다.
- 클라이언트 요청은 게이트웨이에서 추가 처리(ex. Header에 특정 값 추가)되어, 타겟 인스턴스에 최종 전달된다.
- 서비스 인스턴스가 오토스케일링될 때, 게이트웨이에서 로드밸런서의 역할을 한다.
- 게이트웨이의 처리 속도는 빨라야 하고, 게이트웨이가 병목이 되어서는 안 된다.
- 등록된 서비스의 Health Check를 통해, 현재 서비스가 가능한 서비스를 판별한다.
- 동적으로 변경되는 서버 인스턴스의 주소값은 서비스 디스커버리에서 알고 있는다.
Service Discovery 패턴의 장점
- 클라이언트는 각 서비스 인스턴스에 변경이 발생해도 영향 받지 않는다.
- 클라이언트의 요청은 서비스 디스커버리에서 결정하여 전달하고, 필요한 전후처리는 게이트웨이에서 담당하기 때문에, 각 서비스 서버는 비즈니스 로직에만 집중하면 된다.
Service Discovery
MSA는 일반적으로 가상화된 혹은 컨테이너화된 환경에서 실행되고, 서비스 인스턴스의 수와 위치(주소)값은 계속해서 동적으로 변경된다. 인스턴스의 주소값과 이름을 알아서 요청을 타겟 마이크로서비스에 전달할 필요가 있고, 이것이 바로 Service Discovery가 등장한 이유다.
동작 방식
2가지 단계로 동작한다.
1. 인스턴스가 자신의 주소값을 등록한다.
2. 등록된 정보를 바탕으로 클라이언트의 요청이 인스턴스에 전달된다.
- Service Provider의 주소가 Service Registry에 등록된다.
- Service Consumer는 Service Provider의 주소를 Service Discovery Server에 요청한다.
- Service Registry를 찾아서 Service Provider의 주소를 Service Consumer에게 전달한다.
- Service Consumer는 Service Provider에게 직접 요청을 보낸다.
두 가지 패턴
Client-Side Service Discovery
클라이언트 사이드 서비스 디스커버리를 사용하면, Service Consumer가 Service Registry에서 서비스 인스턴스들의 네트워크 위치를 파악해와서, 직접 로드 밸런싱의 로직까지 하게 된다.
Server-Side Service Discovery
서버 사이드 서비스 디스커버리를 사용하면, 로드 밸런서의 역할을 하는 중간 매개체를 두게 된다. 클라이언트는 로드밸런서에게 요청을 보내고, 로드밸런서가 Service Registry에 질의하여, 인스턴스의 주소값을 받아오고, 요청을 Service Provider로 보낸다. 즉, 하나의 요청에 대한 orchestrator 역할을 하는 로드밸런서를 두는 것이 서버 사이드 서비스 디스커버리 패턴의 핵심이다.
Service Registry
각 서비스 인스턴스의 주소값을 전화번호부처럼 기록하고, 업데이트하고, 정리하고, 관리/운영하는 것이 바로 Service Registry의 역할이다.
이 Service Registry에 등록을 하는 방법도 두 가지가 있다.
Self Registration
직접 등록하는 방식이다.
Third-Party Registration
3자를 두어서, 인스턴스에 어떤 변화가 감지되거나 이벤트가 발생하면 Service Registry에 알리는 방식이다.
Reference
- Service Discovery in Microservices (링크)
