[MSA] #5 Service Discovery

MSA는 Cloud 환경과 밀접하게 관련이 있습니다. 각 서비스마다 다른 서버에 올려야 되는데, 물리 서버를 사용하게 되면 관리하기 힘들어집니다. 100개의 서버가 필요하다면 100개의 물리 서버의 비용과 장소 비용 하드웨어 관리 비용 등이 듭니다. 그러나 Cloud를 사용하게 되면 이런 이슈를 AWS와 같은 솔루션에서 해결해줍니다. 그리고 가용성을 고려해야 되기 때문에도 많은 서버에 관리해야 합니다. 예를 들면 주문 서비스는 수익과 직결되는 서비스입니다. 그래서 트래픽과 같은 환경에 따라 문제가 된다면 금전적으로 손실을 얻을 수 있습니다. 그래서 하나의 인스턴스(서버)에 하나의 서비스를 올려두는 것이 아니라 두 개 이상의 인스턴스에 동일한 서비스를 올린 후 인스턴스 1에 문제가 생기면 인스턴스 2를 통해 로직을 수행합니다. (일반적으로는 모든 서비스에 가용성을 고려해서 여러 개의 인스턴스를 둡니다.) Auto-scaling을 사용하면 앞선 이슈를 보다 더 간단하게 해결할 수 있습니다 Auto-scaling은 트래픽에 따라 서버(인스턴스)를 조정해줍니다. 예를 들면 새벽과 같이 트래픽이 낮을 때는 최소의 서버만을 구동시키고, 트래픽이 많은 오후 시간대에는 트래픽에 따라 3, 4, 5개 … 자동적으로 늘려줍니다. 이처럼 Cloud 환경에서는 Auto-scaling, 업그레이드, 확장 등의 이유로 인스턴스가 생성, 소멸되며 때로는 IP 주소가 변경되기까지 합니다. 이것은 Cloud에서 변경이 되는 것이지 우리의 서비스가 이를 알 수 없습니다. 다시 말해서 Auto-scaling이 되어서 인스턴스가 하나 생성되었더라도 우리는 이를 알아차리고, 생성된 인스턴스에 트래픽을 분산시킬 수 없습니다. 이런 것을 감지하는 역할이 Service Discovery입니다. Service Discovery가 어떻게 돌아가는지에 대해 알아보겠습니다.

1. 각 서비스가 실행될 때 Service Registry에 IP, port 등의 서버 정보를 저장합니다. (파란 점선)

2. Client에서 HTTP 요청이 들어옵니다.

3. Router는 정해진 시간마다 Service Registry에 가서 서비스들의 서버 정보를 가져옵니다.

4. 요청이 들어온 URL을 해석해 Service Registry에서 가져온 서버 정보를 토대로 해당 서비스로 라우팅을 시킵니다. (http://{url}/users… 란 URL이 있으면 유저 서비스라는 것을 짐작할 수 있겠죠?)

몇 가지 더 보충하자면 요청이 들어올 때마다 Service Registry를 통해 서버 정보를 가져오지는 않고요. 한번 가져온 정보는 알고리즘에 의해 캐시가 됩니다. 그리고 Service Registry는 지정된 시간에 한 번씩 서비스들에게 ping을 보내서 서버가 살아있는지 확인하고 죽어있으면 정보를 지웁니다. 위의 서버를 운영 중 갑자기 주문 트래픽이 늘어나면 Auto-scaling에 의해 인스턴스 2가 생성이 됩니다. 그 후 주문 서비스가 인스턴스 2에 올라가게 되고 그 과정에서 해당 서버 정보를 Service Registry 서버에 등록을 합니다. 그리고 하나의 서비스가 두 개의 서버에 있기 때문에 로드밸런싱 되어 트래픽이 분산됩니다. 그리고 IP, port를 이미 가지고 있기 때문에 DNS 서버에 다녀오지 않습니다. 이는 성능상으로도 이점이 있다고 합니다. 참고

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