[MSA] Service Discovery Server 이해하기 (3)

MSA는 클라우드 환경에서 수많은 서비스들이 자동 스케일링, 확장 등 서비스 인스턴스가 수시로 생성되고 또 소멸을 반복하게 되면서 서비스의 정보(IP, PORT 등)는 계속해서 변경되는데 계속해서 변경되는 서비스를 식별해서 호출하기는 상당히 어렵다.

 

그래서 많은 서비스들을 유지 관리하기 위해 서비스 디스커버리 패턴을 적용할 필요가 있다.

---

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

서비스 인스턴스를 식별하여 서비스를 등록하고 등록한 서비스의 검색을 수행한다.

 

서비스 디스커버리 서버의 동작 방식에 따라 Client Side, Server Side 방식이 존재한다.

 

Client Side Discovery

Client Side Discovery는 클라이언트가 서비스를 호출할 때 디스커버리 서버에 서비스의 위치를 확인하여 해당 서비스를 호출하는 방식이다.

Client Side Service Discovery

장점

1. 서비스별로 소프트웨어적으로 로드 밸런싱을 구현할 수 있다.
2. 상대적으로 간단해서 구현하기 쉽다.

단점

1. 서비스별로 로직을 구현해야 하기 때문에 종속성이 올라간다.
2. 언어, 프레임워크 별로 따로 구현을 해야 한다.

하드웨어 장비없이 소프트웨어적으로 로드 밸런싱의 방법을 구현하는 방식은 비용적으로도 메리트가 있는 것 같다.

대신 서비스별로 다른 언어, 다른 프레임워크를 사용한다면 따로 구현을 또 해줘야하는 단점이 있다. 대표적으로는 넷플릭스의 유레카(Eureka)가 대표적이다.

 

Server Side Discovery

Server Side Discovery는 클라이언트가 로드 밸런서(프록시)를 호출하면 로드 밸런서에서 디스커버리 서버에 서비스의  위치를 확인하여 해당 서비스로 라우팅하는 방식이다.

Server Side Service Discovery

장점

1. 디스커버리 로직을 클라이언트로부터 분리하여 클라이언트 측에서는 구현할 필요가 없다.

단점

1. 배포 환경에 구축이 되어야 하며, 설정 및 관리가 필요하다.
2. 서비스 디스커버리 서버가 죽으면 전체 시스템이 동작하지 않을 수 있다.

클라이언트 측에는 구현할 필요가 없어 의존성이 떨어지게 되는 점은 좋지만 그래서 더 많은 관리를 필요로 하는 것 같다.

대표적인 예로는 AWS Elastic Load Balancer(ELB)가 있다.

---

어떤 방식이 옳다고는 딱 잡아 말하진 못하지만 모든 기술 및 기능들은 운영 상황에 맞게 사용하면 된다.

 

간단하게 서비스 디스커버리 서버에 대한 필요성과, 동작 방식 대한 장단점을 정리해 봤고

아래 링크에서 실제 구현 소스를 확인해보자!

 

[MSA] Spring Boot로 Service Discovery 구축하기 - Netflix OSS Eureka Server

[MSA] Spring Boot로 Service Discovery 구축하기 - Netflix OSS Eureka Server

MSA에 대하여 (4) - Config Server