[스프링 클라우드] Netflix Zuul

뿌이·2022년 2월 7일

스프링 클라우드

목록 보기

3/32

Zuul이란?

zuul서버는 API Gateway이다
먼저 왜 API Gateway가 필요할까 이해하는게 중요
API Gateway는 API의 요청자인 Client(웹어플리케이션 또는 모바일앱)와
API의 제공자인 backend service를 연결하는 중계자

우리가 부동산중계인을 통해 거래를 하듯이, API를 사용하는 어플리케이션과 API를 제공하는
backend service는 API Gateway를 통해 데이터를 유통
API Gateway가 필요한 이유도 안전한 API유통과 Client 요청별로 유연하게 대처하기 위해

API Gateway가 필요한 이유

인증/인가: 부적절한 요청을 차단하여 Backend service를 보호
L/B & Routing: Client의 요청에 따라 적절한 backend service를 로드밸런싱(L/B: Load Balancing)하고 연결(라우팅)
Logging: 유통되는 트래픽 로깅
Circuit Break: Backend service 장애 감지 및 대처

모든 frontend의 요청을 라우팅하므로 다음의 usecase에도 활용할 수 있습니다.

점진적으로 레거시 시스템을 신규 시스템으로 교체: Strangler pattern 적용
트래픽 일부만 새로운 서비스로 라우팅: Canari(카나리) 배포 가능

zuul은 몇 개 정도 필요할까?

zuul로 모든 api요청이 들어오면
zuul은 일단 하나만 있으면 장애가 나기때문에 무조건 이중화를 해서
서버를 보통 1개 초과로 갖고잇음

그리고 zuul에는 ribbon이 내장되어있음!!

Ribbon이란?

Ribbon은 Load balancing을 요청 어플리케이션 단에서 수행해주는 Client-side Load balancer입니다.
Ribbon과 같은 L/B가 필요한 이유는 부하 분산을 적절하게 하여 서비스의 가용성을 최대화하기 위함입니다.

API Gateway도 Ribbon을 통해 Backend service를 로드밸런싱합니다.
또한, Ribbon을 사용하면 API Gateway없이 대상 어플리케이션을 직접 로드밸런싱하여 연결할 수도 있습니다.

Eureka client도 내장되어있어서
유레카 클라이언트를 사용해서 주어진 url의 호출을 전달할 서버리스트를 찾음

각 url에 mapping 된 서비스 명을 찾아서 Eureka server 를 통해 목록 조회함
조회된 서버 목록을 Ribbon 클라이언트에게 전달한다.
Eureka + Ribbon 에 의해 결정된 Server 주소로 HTTP 요청을 한다.

11번가에서도 많은 접속이 올 것을 대비해 11절에는 기존 16대에서 22대로 늘렸다고 한다.

zuul의 모든 호출은

HistrixCommand로 실행되므로 Circuit Breaker를 통해 장애시 Fail Fast 및 Fallback 수행 가능
Ribbon + Eureka조합을 통해 현재 서비스가 가능한 서버의 목록을 자동으로 수신
Ribbon의 Retry 기능을 통해 동일한 종류의 서버들로 자동 재시도가 가능

Zuul 어노테이션

@EnableZuulProxy
@EnableDiscoveryClient
이렇게 두가지를 사용하여 application에 어노테이션을 달아준다.
근데 @EnableDiscoveryClient와 같은 경우엔 @EnableEurekaClient를 사용해도 되는데 유레카에 종속되는 느낌이고, @EnableDiscoveryClient는 조금 더 추상적인 느낌이라고 한다

zuul도 어쨌든 eureka를 통해서 관리를 한다

Spring Cloud Zuul

넷플릭스 zuul이랑 spring cloud zuul이랑 다르다
semaphore에서 차이가 있다고 하는데
넷플릭스 zuul을 감싸서 spring cloud안에서 쓸수 있도록 한 거라고 한다.

Spring cloud Netflix zuul은 2018년 12월부터
더 이상의 기능 개선 없이 유지만 하는 Maintenance Mode로 변경되었습니다
이미 Spring boot 2.4.X부터는 zuul, hystrix가 더 이상 제공되지 않습니다.
Spring cloud 커뮤니티에서 zuul 대신 권고하고 있는 API Gateway가 Spring cloud gateway입니다.
아직 zuul을 많이 사용하고 있으므로, zuul서버 개발도 배우실 필요가 있습니다.

근데 semaphore는 network timeout을 격리시켜주지 못해서 11번가에서는 threadpool로 바꿨다고 한다.
11번가는 spring cloud gateway를 쓰되 threadpool로 바꾼 것이죠
Tip : zuul을 쓰면 histrix command가 서비스 id별로 된다

에러 가 났다면 error filter를 통해서 , post를 한다면 post filter를 통해서 관리를 해준다.
모든 들어오는 요청을 담아서 분석을 한다던가..
에러를 에러필터를 통해 정형화시켜서 사용자에게 에러를 보여주고있기도 하다.

보통 들어오는 요청에 대해 'pre' filter에서 인증/인가 처리를 하고,
routing filter에서 L/B, Routing, Circuit break를 처리하며,
Post filter에서 요청과 응답에 대한 Logging을 처리합니다.
L/B는 ribbon이라는 라이브러리가 사용되고,
Routing은 zuul core라이브러리가 사용되며,
Circuit break는 Hystrix라이브러리가 사용됩니다.

pre/route/post/error filter를 이용하여 인증/인가, 라우팅, 로깅등을 정교하게 할 수 있습니다.

Spring Cloud Config

spring cloud config server도 간단하면서 중요한 개념이다
만약에 zuul을 30개에서 40개로 바꾸고싶다.
그러면 중앙화된 설정서버가 있다면 서버들을 일일히 재가동할 필요도 없고,
git 레포지토리에 넣어두고 config server 설정을 한줄만 바꾸고
서버 재시작을 하면 되는 되게 간단하게 해주는 애!

config server는 git에서 config파일을 읽고, config 변경시
Message broker(예:rabbitMQ, kafka등)에 변경내용을 반영합니다.
그럼 각 마이크로서비스는 변경을 통지받고 config server를 통해 최신 config를 갱신하게 됩니다.
각 마이크로서비스는 ribbon을 이용하여 직접
다른 마이크로서비스를 load balancing하여 연결할 수 있습니다.
이때 Hystrix를 통해 circuit break를 적용할 수도 있습니다.

하지만 11번가에서 19년 1월 기준 config server를 쓰면 당연히 좋지만,
config server에서 바꾼 것을 서버 재시작을 하면
refresh 어노테이션이 붙어있는 부분들이 refresh scope에 의해서 빈이 다시 생성되서...
이런 부분에 대한 것을
검증을 못해서 이걸 꼭 써야한다 라고는 당당하게 얘기하지는 못하겟다고 함..