[Netflix] Part 2 - Zuul 2 여정의 시작
이번 글에서는 새롭게 변화된 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를 통해 요청에 대한 처리량이 늘었음)