[MSA] Service Discovery - (3)

이전 포스팅 링크 참고

 

이전 글에서 다룬 MSA구조의 전체적인 구성도를 보면, 좌측 위에 Service Mesh라고 묶여있는 부분을 발견할 수 있다. 이부분은 어떤 일을 하는 곳일까?

 

 Service Mesh

 

 

체크한 5가지를 묶고있는 추상적인 개념으로 (서비스 아님)

MSA를 적용한 시스템의 내부 통신을 말한다.

서비스 간의 통신을 추상화 하고 안전하고 빠르고 신뢰성있게 만들어주는 인프라 스트럭처의 layer다. (네트워크 레이어)

이러한 기능을 통해 안정적이고 효율적인 마이크로서비스의 운영을 지원하는 것을 목적으로한다.

 

 

 

해당 네트워크 레이어(Service Mesh)에 있는 Service Discovery에 대해 자세히 알아보자.

 

 

 Service Discovery

 

이전 포스팅에서 '독립적으로 나눠진' 서비스들에 대한 위치를 찾기 위해 Service Discovery가 필요하다고 명시했다.

해당 내용에 대해 자세히 다뤄보자.

 

 

 

이전에는, 개발자가 수동으로 서버를 늘리고 줄이는 작업을 했다. 또한 직접 API Gateway에 바뀐 서비스들의 주소를 갱신해야만 했다.

 

하지만 도커와 쿠버네티스의 등장으로 요청하는 트래픽에 따라 서버를 늘리고 줄이는 것이 동적으로 바뀌게 된다.

이 때 삭제되고 추가되는 서버는 매번 새로운 ip를 할당받게 될 텐데 그 때마다 직접 개발자가 추가해야 한다면? 서버가 100개 1000개가 된다면 어떡할것인가?

 

 

 

 

이러한 점을 해결하기 위해 나온 개념이 '서비스 디스커버리'이다.

매번 동적으로 주소가 바뀌는 서비스들을 검색하기 위해 사용되는 개념으로 일종의 전화번호부 책과 같은 역할을 한다.

 

출처 : Nginx

1. 클라이언트나 외부 서비스에서  보낸 요청을 로드발란서나 API gateway가 전달받게 된다.
2. 그 후 로드발란서가 service discovery에 요청을 보내게 된다.
   (Load Balancer가 필요한 정보 : 클라이언트가 요청한 서비스의 위치는 어딨습니까?)
3. service discovery는 registry에 담긴 서비스들의 네트워크 위치를 꺼내 알려준다.
   (당신이 필요한 서비스는 10.4.3.99:4545로 가십셔)
4. 로드발란서는 받아온 주소를 토대로 사용자 요청정보를 해당 서비스에 전달하고 정보를 얻어온다.
   
5. 클라이언트에게 정보를 반환한다.

즉, 서비스 디스커버리의 역할은 각각의 마이크로 서비스가 어디에, 누가 저장되어 있는지 기억하고 요청 정보가 들어왔을 때 요청 정보에 따라서 필요한 서비스의 위치를 알려주는 역할이다.

 

앞서 필자가 말한 전화번호부 책과 같은 개념이라고 보면 된다.

서비스 레지스트리? 서비스 디스커버리?
서비스 디스커버리의 핵심 부분으로 서비스 인스턴스의 네트워크 위치를 포함하는 데이터베이스다.

 

 Neflix Eureka

 

앞서 말한 서비스 레지스트리의 좋은 예가 바로 넷플릭스 유레카이다.

디스커버리 서비스를 제공하는 제품중 하나로, 넷플릭스가 스프링에 기부했다고 한다. (오우 flex..)

 

개념만 들어서는 제대로 와닿지 않으니 다음 포스팅에서는 Neflix Eureka 제품을 사용하여 디스커버리 서비스를 간단하게 직접 구현해보도록 하자!

 

 

 

[참고 링크]

https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/

https://www.l7defense.com/cyber-security/api-gateway-vs-load-balancer/

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4