[Netflix] Part 2 - Zuul 2 여정의 시작

*https://medium.com/netflix-techblog/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

이번 글에서는 새롭게 변화된 Zuul에 대해 Netflix에서 겪은 여러 과정을 소개하려고 한다.

그런데 위의 원본 페이지에서도 확인 할 수 있듯이, Netflix에서는 Zuul 2라고 언급한다. 사실 Zuul 1과 2의 기본 기능*은 거의 같다고 할 수 있다.

* Zuul 의 기능 요약 (이외에도 여러 가지가 있음)

- 요청 라우팅

- 개발자 테스트

- 외부 공격 방어

다만, Zuul 1과 2의 차이점은 Zuul 2에서는 Netty를 사용하여 asynchronous, non-blocking을 활용하고 있다는 것이다.

즉, 이를 통해 Netflix에서는 대규모의 상황*에서도 persistent connection을 유지 할 수 있게 되었다.

* Netflix의 사용자는 8천 3백만 명이 넘음

간단하게 생각하면 framework를 하나 도입했을 뿐이지만, 결과적으로 Netflix는 다음의 장점을 얻을 수 있게 되었다.

- 디바이스 요청 감소

- 디바이스 성능 향상

- 많은 제품 기능 추가

- 등등...

조금 기술적으로 들어가면, Zuul 1과 2의 차이점은 네트워크 구성 방식이다. 

- Zuul 1

Servlet framework로 구성되어 내부적으로 Blocking과 multithreaded를 사용한다.

즉, 요청이 들어오면 thread pool에서 thread를 할당하여 요청을 처리 할 수 있도록 한다.

(즉, thread당 connection 하나를 사용하여 요청을 처리)

그림 1. Multithreaded System Architecture

- Zuul 2

내부적으로 asynchronous를 사용한다.

즉, 요청 및 응답은 이벤트 및 콜백을 통해 처리된다.

Zuul 2로 넘어오면서 바뀐 네트워크 기술(asynchronous)의 큰 장점은 오버헤드가 적다는 것이다. 

일반적으로 한 개의 thread가 모든 요청과 응답을 처리하고,(보통 CPU Core당 thread 한 개) 이벤트와 콜백을 사용하기 때문에.. 

새로운 thread를 만드는데의 메모리와 여러 시스템 리소스를 덜 사용한다.

(+ 시스템 레벨 Cache 사용 및 더 적은 context switching)

그림 2. Asynchronous and Non-blocking System Architecture

이렇듯 Zuul 2로 넘어오면서 아키텍처도 바뀌게 되었다.

사실 이론상으로는 Zuul 2가 이점이 더 많은데 실제 환경에서도 많은 이점을 얻었는지 의문점이 생긴다.

이런 의문에 Netflix는 사실 큰 효율성은 없지만 많은 connection을 확보 할 수 있다고 말한다.

(특히, connection 유지 비용이 줄어들면서 디바이스간 양방향 통신도 가능해짐)

추가로 CPU의 사용률은 낮아지지만 처리량은 늘었다는 것을 확인 할 수 있었다고 한다.

(즉, asynchronous를 통해 요청에 대한 처리량이 늘었음)