IT/AWS

[Netflix] Part 1 - Zuul 소개

물통꿀꿀이 2018. 12. 4. 02:51

*https://medium.com/netflix-techblog/announcing-zuul-edge-service-in-the-cloud-ab3af5be08ee


Zuul은 클라우드 환경에서 Edge Service*의 역할을 한다..

*Edge Service : 클라우드 환경에서 public internet과의 연결점으로 보통 gateway라고 하며, 내부의 서비스로 연결한다.

예를 들어, Nginx를 reserve proxy로서 활용할 때, Nginx는 외부의 요청을 받아 내부로 연결한다.


Netflix에서 Zuul이 Edge Service로 등장하게된데 몇 가지 배경이 존재한다. (축약해보면..)

- 기존에는 Netflix API를 사용하여 시스템을 운영하였다.

- 인기있는 application 답게 피크(peak) 시간에는 초당 50,00개 이상의 요청이 들어오고 1,000개가 넘는 디바이스 타입을 지원한다.

- 이러한 상황에 동시적으로 기능 수정/추가 개발*(+ 테스트)이 필요하다.

* 새로운 국가 지원 등등의 여러 features


위의 이유로 견고한(robust) edge service*가 필요하게 되었다.

* rapid development, great flexibility, expansive insights, resiliency


물론 Zuul의 초기 설계 당시는 Netflix API 앞단에서 edge service를 하는 것이었지만, 현재는 이외에도 다양한 방식으로 사용하고 있다.

(그림 1에서 현재 Zuul의 아키텍처를 확인 할 수 있다.)



그림 1. Zuul in Netflix's Cloud Architecture


그렇다면 Zuul은 어떻게 동작을 하는지 확인해 보자.

먼저, Zuul의 내부는 HTTP 요청/응답을 routing할 때 사용하는 filter들이 존재한다. 

(Zuul은 filter를 사용하여 여러 가지 행동을 한다.)


간단히 filter의 특징을 보자면 4가지가 있다.

- 유형 (Type) : routing이 진행 중일 때, 보통 stage을 정의

- 실행 순서 (Execution Order) : 다수의 필터에서 실행 순서 정의

- 조건 (Criteria) : 필터가 수행되는데 필요한 조건

- 행동 (Action) : 조건이 충족되면 실행되는 행동


이제까지 알아본 filter의 특징을 바탕으로 간단한 예시를 살펴보면 다음과 같다.

(아래 예제는 오작동된 디바이스의 요청을 지연시키기 위한 filter이다.)

class DeviceDelayFilter extends ZuulFilter {

    def static Random rand = new Random()
    
    @Override
    String filterType() {
       return 'pre'
    }

    @Override
    int filterOrder() {
       return 5
    }

    @Override
    boolean shouldFilter() {
       return  RequestContext.getRequest().
       getParameter("deviceType")?equals("BrokenDevice"):false
    }

    @Override
    Object run() {
       sleep(rand.nextInt(20000)) // Sleep for a random number of
                                  // seconds between [0-20]
    }

} 


위의 예제를 보면 4개의 method를 확인 할 수 있는데, 각각 위에서 언급했던 filter의 4가지 특징이다.


그럼 이제 Zuul이 어떻게 동작하는지 확인하기 위해 내부 Core부터 살펴보려 한다.


그림 2. Zuul Core Architecture


1. Publisher, Poller, Directories 등등.

해당 구성 요소들은 Zuul 서버에 지속적으로 업데이트 하기 위한 용도이다. 

즉, 파일을 주기적으로 polling하여 동적으로 컴파일하여 배포에 대한 지연시간 없이 Zuul 서버가 동작하게 한다.


2. Request Context

Filter는 서로 간에 직접 통신하지 않고, RequestContext를 통해 지속적으로 상태를 공유한다.


3. Routings..

Zuul은 routing flow에는 4가지의 종류가 있다.

- PRE : origin으로 routing 되기 전에 실행 (인증, 로깅 등등..)

- Routing : origin으로 routing

- POST : origin으로 routing 된 후에 실행 (통계 정보 수집 등등..)

- ERROR :  Zuul의 routing flow 중 오류가 발새 할 때 실행


Routing의 4가지 종류는 실제 HTTP Request가 들어왔을 때, 아래의 그림처럼 동작한다.

그림 3. Request Lifecycle


이제까지 Netflix Zuul에 대해 소개하였다. 간단히 정리해보자면 결국 Zuul은 filtering와 routing flow가 Zuul의 핵심 부분이다. 

또한 이러한 내부 구조를 통해 그림 1에서 볼 수 있듯이 Netflix API, Netflix streaming application에 edge service의 역할을 하고 있다.