Netflix Stack

MSA와 Netflix

MSA (MicroService Architecture) 를 말한다면 성공사례로 Netflix 를 빼놓을 수 없다.

사실 MSA 1세대는 대부분 Netflix의 아키텍쳐를 따라간다. 

이후 컨테이너라는 기술이 나오면서 트렌드가 바뀌긴 했지만 Netflix는 자신들만의 기술들을 잘 구축했으니 한번 살펴보자

Netflix는 이런 MSA 구성을 위한 오픈소스들도 http://netflix.github.io/ 에 공개해놓았으니

우리들은 잘 구성해놓은 기술들을 잘 사용만 하면 된다.

MSA 구성을 위해 Netflix가 공개해놓은 기술 스택에 대해서 알아본다.

MSA 구성 시 고려사항

MSA 를 구성하려면 몇가지 고려사항이 있다.

아래 그림처럼 기존 Monolothic 구조를 Microservice로 분리했다고 보자.

                     [그림1] Microservice Architecture 전환 구성 예제

위 그림을 보면 서비스들을 분리하긴 했지만 그래서..? 의문점이 한 두가지가 아닐 것이다.

그럼 이 서비스들을 어떻게 한번에 관리하지?

서비스들간의 통신은? 각 서비스들의 URL을 또 관리하나?

각 서비스 자원을 사용하기 위한 인증&권한은 어떻게 처리하지?

이처럼 서비스를 잘 분리하는 것 이외에 

분리된 서비스들에 대한 Ochestration, 로그 수집, 트래킹, 라우팅, 인증처리 등을 처리하는 방법이 필요하다.

이런 의문점들을 해결하기 위해서는 VM을 사용하는 환경에서는 Netflix Stack을 고려해봐야 한다.

(추후 Container기반으로 구성할 때 K8S에 대한 내용을 정리해야지)

뭐 많은 고민없이 앞서 언급한 것 처럼, 잘 구성해놓은 기술들을 우리는 잘 사용하면 된다.

Netflix Stack?

Netflix 에서 사용되는 기술은 아래와 같다.

Zuul과 Eureka는 MSA 1세대 이후에도 많이 참조가 되는 모듈이므로 숙지하고 넘어가야 한다.

• Zuul - Gateway, 인증, Logging 수집 등
• Eureka - Service Registry & Discovery
• Ribbon - Load Balancing
• Hystrix - Circuit Breaker
• Turbine - Hystrix Stream Aggregator

---

위 모듈들이 왜 도입되었는지 무슨 역할을 하는지에 대해서 자세히 생각해 볼 필요가 있다. 

Zuul의 역할

의문점 : 위 [그림1] 처럼 서비스들을 분리했을 때 Client쪽에서는 어떻게 처리를 할까? 

※ Client는 간단히 User Interface로 생각한다

한번 직접 호출하는 방식으로 생각해보자.

     [그림2] Client에서 직접 호출 시 구성도

 

위 그림과 같이 직접 호출해준다면..뭐 해줄순 있겠지만 할일이 

 - 서비스들을 사용할 때의 인증과 권한체크도 Client에서 처리를 해줘야 한다.

 - 브라우저 정책상..Client에서 Cross Origin 문제 때문에 서비스들마다 처리를 해줘야 한다. 

 - 서비스들을 관리하기가 어렵다.

등등 더 생각할게 많겠지만..몇가지만 봐도 Fat Client가 되어버렸고

가장 중요한건 Client와 서비스간의 Dependency가 많아서 서비스 변경마다 Client 변경이 일어나야 한다는 점이 아닐까

아래 [그림3] 에서의 그런 역할들을 Zuul (API Gateway)에서 처리하는 것으로 분리한다고 생각해보자

              [그림3] API Gateway 도입 시 구성도

그냥 똑같은데 Layer 하나 더 생긴거 아냐? 맞다.

이렇게 Gateway를 사용함으로써 한번에 서비스 관리가 가능하다.

자연스럽게 라우팅 기능 역할을 하게 된다. 뭐 이런것들을 고려한 것이 아닐까.

Eureka의 역할

의문점 : Gateway에서 서비스들이 어디있는지 어떻게 알아?

위 [그림3] 은 알겠는데 신규 서비스가 생겼거나 위치가 변경이 된 경우는 어떻게 자동으로 처리해주는걸까?

                    [그림4] Eureka (Service Registry) 의 역할

위 [그림4] 와 같이 서비스들이 각자가 Eureka 서버에 등록을 하고 API Gateway에서는 그 등록된 정보를 사용하는 것이다.

그래서 정확히는 Service Registry 역할을 하는것이고 Discovery라고 보기에는 어렵다고 한다..

Ribbon의 역할

TODO

 - Load Balancing 역할

 - 서비스 Scale-out 시 필요

Hystrix & Turbine의 역할

TODO

 - Circuit Breaker 패턴

 - Open & Close 를 통해 Fault Tolerance (SW 품질 향상)

 - 서비스 호출 실패 시 Faultback

 - Event Stream들을 Aggregator

 - 수집된 내용을 기반으로 Dashboard