Netfilx 클라우드 인프라로 들어오는 모든 요청을 Zuul2 통해서 들어온다. (1.25 억 회원)
Netflix 의 Cloud Gatway 팀은 Zuul2 를 사용하여 80개 이상의 클러스터를 운영한다. 초당 100만건 이상의 요청을 처리하기 위해 100개 Backend 서비스 클러스터로 트래픽을 보냄. 트래픽의 거의 모두는 고객 디바이스와 브라우저에서 발생
How Zuul 2 Works
Netty 핸들러는 네트워크 프로토콜, 웨 서버, 커넥션 관리, 프록싱 등의 작업을 함. Inbound 필터는 요청을 프록시 하기 전에 실행하고 인증, 라우팅, decorating(?) 한다. Endpoint 필터는 static 응답 반환 혹은 요청을 백엔드 서비스로 프록시 한다. Outbound 필터는 응답이 나간후 실행하고, gzipping, metrics, 커스텀 헤더 조작 등에 사용 함.
필터를 임의로 추가 가능함.
모든 외부 트래픽의 시작을 Zulul 을 사용하여 라우팅 한다.
Open Source
지금 버전은 안정적이다. 하지만 예전에는 코드베이스를 발전시키고, 리팩토링 하는데 배당금(dividends)을 지불했고, 이를 공유하는게 행복하지 않았다.
Server Protocols
HTTP/2 — full server support for inbound HTTP/2 connections
Mutual TLS — allow for running Zuul in more secure scenarios
Resiliency Features
Adaptive Retries — Netflix 의 핵심 retry 로직 to increase our resiliency and availability
Origin Concurrency Protection — origins 의 과부하를 방지하고 Zuul 뒤에 있는 다른 오리진을 서로 보호하기 위해 concurrency limits 을 둔다.
Operational Features
Request Passport — 각 요청의 lifecycycle 이벤트를 추척한다. 비동기 요청을 디버깅 하는데 유용함
Status Categories — HTTP 상태 코드 보다 더 세분화된 요청의 성공 및 실패의 상태를 열거
Request Attempts — 재시도 및 라우팅 디버깅에 특히 유용하도록 프록시로의 각 요청 상태를 추적
다음은 제공될 예정인것들
Websocket/SSE — support for side-channel push notifications
Throttling and rate-limiting — 악의적인 대량의 공격 (클라이언트 연결 및 요청) 으로부터 방어
Brownout filters — Zuul 이 과부하 되면 CPU-intensive 기능을 사용하지 않음
Configurable routing — Zuul 필터 없이, file-based 라우팅 설정 지원
파트너가 가장 널리 쓰는게 바로 셀프 서비스 라우팅이다. 요청 URL, path, 쿼리 파람, headers 기준으로 라우팅 규칙을 만들 수 있는 API 제공한다. 그런 다음 이런 라우팅 규칙을 모든 Zuul 인스턴스에 publish 한다.
리얼 황경 프로덕션 트래픽 사용 사례:
트래픽 샤딩이 필요하는 서비스는 paths or prefixes 로 origin 을 나누는 라우팅 규칙을 만든다
(개발자) 새로운 서비스는 신규 oriin 에 신규 hostname 으로 라우트 하도록 한다
(개발자) 부하 테스트는 기존 트래픽 일부 퍼센트를 작은 클러스터로 라우팅한다
(리팩토링 팀) 신규 origin 으로 마이그레이션 하기 위해, 한번에 1 path 씩 천천히 옮긴다
(테스트 팀) 새빌드가 running 중일때, 작은 퍼센트의 트래픽을 보내서 changes 테스트(카나리아)를 한다
(팀) 새 빌드에 멀티플 연속적인 요청에 대한 변화를 테스트해야 하면, sticky 카나리 테스트를 동일한 유저로 간결하게 시간동안 새빌드에 한다
(보안 팀) path or header 규칙으로 만든 "bad" 요청을 거부하는 규칙을, 모든 Zuul 클러스터에 만든다
보다시피 셀프 서비스 라우팅을 광범위하게 사용하기 위해 사용자 정의와 route 범위를 더욱 늘리고 있다.
Load Balancing for Resiliency
또다른 메이저 기능은 origin 으로의 LB 를 보다 지능적으로 만드는것이다. failures, slowness, GC issues, 많은 노드를 실행할때 발생하는 다양한 문제 등을 해결할 수 있다. 결국 resiliency, avaliability, quality of service 를 높이는 것이다.
처리해야할 몇가지:
Cold Instances
새 origin 인스턴스가 up 하면, warm up 까지 일정량의 트래픽을 일정시간동안 보낸다. 코드베이스가 크거나 거대한 메타스페이스를 쓰는 애플리케이션에서 관찰 된다. JIT 하고 거대 트래픽 받을 준비를 하려면 상당한 시간이 걸린다.
일반적으로 older 인스턴스로 트래픽을 편중시키고, 만일 cold 인스턴스로 hit 되면, warm 인스턴스로 retry 를 항상 한다. 그래서 availability 가 크게 향상된다
High Error Rates
코드에 버그나, bad 인스턴스, invalid configuration property 등 다양한 이유로 에러가 발생한다. 다행히 프록시가 안정적으로 감지 가능하다.
각 origin 의 오류율을 추적하고, 오류율이 높으면 전체 서비스에 문제 있음을 의미. 디바이스에서 재시도 하도록 하고, 내부에서 재시도 못하게 하여 서비스가 복구 되도록 함. 또한 인스턴스 당 연속정인 장애를 추적해서, 일정 기간 동안 불량하면 블랙리스트에 넣어버림
Overloaded Instances
현재 utilization 를 LB 선택의 요소로 이용된다 - 오류율, retries, latency 가 줄어든다
origin 응답 헤더에 urilization 에 대한 백분율을 넣는다.
각 인스턴스에 score 를 매기고 choice-of-two LB 선택을 한다.
Anomaly Detection and Contextual Alerting (이상 감지와 상황별 Alert)
Matis 실시간 이벤트 스트리밍으로 서비스 당 오류율을 집계하고, 서비스에 문제가 생기면 알림해 주도록 함. 이것은 문제가 있는 모든 origin 의 타임라인을 만든다. 영향을 받는 서비스와 상황별 경고에 대해 이메일 발송. 이를 통해 운영자는 이벤트를 신속하게 연관짓고, 디버깅하고, 근본 원인을 찾을 수 있다.
실제로, 우리 팀은 이것을 확장해서 사용하여 유용하게 사용 함. 실제로 대규모로 outages 되기 전에 미리 발견해서 신속하게 해결했다.
https://medium.com/netflix-techblog/open-sourcing-zuul-2-82ea476cb2b3
Netfilx 클라우드 인프라로 들어오는 모든 요청을 Zuul2 통해서 들어온다. (1.25 억 회원) Netflix 의 Cloud Gatway 팀은 Zuul2 를 사용하여 80개 이상의 클러스터를 운영한다. 초당 100만건 이상의 요청을 처리하기 위해 100개 Backend 서비스 클러스터로 트래픽을 보냄. 트래픽의 거의 모두는 고객 디바이스와 브라우저에서 발생
How Zuul 2 Works
Netty 핸들러는 네트워크 프로토콜, 웨 서버, 커넥션 관리, 프록싱 등의 작업을 함. Inbound 필터는 요청을 프록시 하기 전에 실행하고 인증, 라우팅, decorating(?) 한다. Endpoint 필터는 static 응답 반환 혹은 요청을 백엔드 서비스로 프록시 한다. Outbound 필터는 응답이 나간후 실행하고, gzipping, metrics, 커스텀 헤더 조작 등에 사용 함.
필터를 임의로 추가 가능함.
모든 외부 트래픽의 시작을 Zulul 을 사용하여 라우팅 한다.
Open Source
지금 버전은 안정적이다. 하지만 예전에는 코드베이스를 발전시키고, 리팩토링 하는데 배당금(dividends)을 지불했고, 이를 공유하는게 행복하지 않았다.
Server Protocols
Resiliency Features
Operational Features
다음은 제공될 예정인것들
더 알고 싶으면 위키 방문 하라.
Leveraging Zuul 2 at Netflix
Netflix 내부에 Zuul 2 를 사용했지만 아직 open 안된것이 있다.
Self Service Routing
파트너가 가장 널리 쓰는게 바로 셀프 서비스 라우팅이다. 요청 URL, path, 쿼리 파람, headers 기준으로 라우팅 규칙을 만들 수 있는 API 제공한다. 그런 다음 이런 라우팅 규칙을 모든 Zuul 인스턴스에 publish 한다.
리얼 황경 프로덕션 트래픽 사용 사례:
보다시피 셀프 서비스 라우팅을 광범위하게 사용하기 위해 사용자 정의와 route 범위를 더욱 늘리고 있다.
Load Balancing for Resiliency
또다른 메이저 기능은 origin 으로의 LB 를 보다 지능적으로 만드는것이다. failures, slowness, GC issues, 많은 노드를 실행할때 발생하는 다양한 문제 등을 해결할 수 있다. 결국 resiliency, avaliability, quality of service 를 높이는 것이다.
처리해야할 몇가지:
Cold Instances
새 origin 인스턴스가 up 하면, warm up 까지 일정량의 트래픽을 일정시간동안 보낸다. 코드베이스가 크거나 거대한 메타스페이스를 쓰는 애플리케이션에서 관찰 된다. JIT 하고 거대 트래픽 받을 준비를 하려면 상당한 시간이 걸린다.
일반적으로 older 인스턴스로 트래픽을 편중시키고, 만일 cold 인스턴스로 hit 되면, warm 인스턴스로 retry 를 항상 한다. 그래서 availability 가 크게 향상된다
High Error Rates
코드에 버그나, bad 인스턴스, invalid configuration property 등 다양한 이유로 에러가 발생한다. 다행히 프록시가 안정적으로 감지 가능하다.
각 origin 의 오류율을 추적하고, 오류율이 높으면 전체 서비스에 문제 있음을 의미. 디바이스에서 재시도 하도록 하고, 내부에서 재시도 못하게 하여 서비스가 복구 되도록 함. 또한 인스턴스 당 연속정인 장애를 추적해서, 일정 기간 동안 불량하면 블랙리스트에 넣어버림
Overloaded Instances
현재 utilization 를 LB 선택의 요소로 이용된다 - 오류율, retries, latency 가 줄어든다 origin 응답 헤더에 urilization 에 대한 백분율을 넣는다. 각 인스턴스에 score 를 매기고 choice-of-two LB 선택을 한다.
Anomaly Detection and Contextual Alerting (이상 감지와 상황별 Alert)
Matis 실시간 이벤트 스트리밍으로 서비스 당 오류율을 집계하고, 서비스에 문제가 생기면 알림해 주도록 함. 이것은 문제가 있는 모든 origin 의 타임라인을 만든다. 영향을 받는 서비스와 상황별 경고에 대해 이메일 발송. 이를 통해 운영자는 이벤트를 신속하게 연관짓고, 디버깅하고, 근본 원인을 찾을 수 있다.
실제로, 우리 팀은 이것을 확장해서 사용하여 유용하게 사용 함. 실제로 대규모로 outages 되기 전에 미리 발견해서 신속하게 해결했다.