[MSA] Spring Cloud Zuul 1.x - 개념편

안녕하세요. 오늘은 Spring Cloud에서의 API Gateway인 Zuul 1.0에 대해서 알아보도록 하겠습니다. 사실 현재 Zuul은 내부가 동기통신으로 이루어지기 때문에 부하 문제를 가지고 있어 Zuul 2.0 또는 Spring Cloud Gateway로 넘어가고 있는 추세입니다만, 요즘 나오는 API Gateway를 이해하기 위해서는 webflux를 이해하고 있어야 합니다. 때문에 이해를 위해서 1.0을 기준으로 설명을 진행하도록 하겠습니다.

Zuul

Zuul은 모든 장비 또는 웹사이트에서 백엔드 서비스를 호출할 때 거치는 문 같은 역할을 하는 어플리케이션입니다. Edge 서비스 어플리케이션이라고도 하며 MSA에서 동적 라우팅, 모니터링, 보안 등을 담당합니다.

사용처

zuul의 공식문서에는 Netflix에서는 Zuul을 어떻게 사용하는지 기술해 둔 페이지가 있습니다. 해당 페이지를 보면 아래와 같이 언급하고 있습니다.

how we use zuul at netflix, 출처 : https://github.com/Netflix/zuul/wiki

ZUul은 edge 서비스로 다양하게 사용할 수 있습니다.

• 인증과 보안 : 각 서비스가 분산되어있는 MSA에서 인증을 edge 서비스에서 구현함으로써 모든 서비스에 보안을 구성하지 않고도 보안성있는 어플리케이션 작성을 도모할 수 있습니다.

• 다이나믹 라우팅 : 호출하는 end-point에 따라 다른 백엔드 서비스의 handler를 호출할 수 있습니다.

• 모니터링 : 어떤 서비스가 호출되는지 모니터링할 수 있습니다.

• Stress 테스트 : 퍼포먼스를 테스트하기 위해 점진적으로 트래픽을 증가시킬 수 있습니다.

• Load Shedding : 서로 다른 백엔드 서비스에 대한 요청의 수요량 및 한계를 정할 수 있습니다.

• Static Response handling : 특정 요청에 대해서 실제 서비스를 접근하지 않고 zuul에서 바로 응답하게 할 수 있습니다.

• Multiregion Resiliency : AWS regions을 넘어 routing 할 수 있도록 해줄 수 있습니다.

그렇다면 zuul은 어떤 구조를 가지고 이런 일을 할 수 있을지 내부 구조에 대해서 알아보도록 하겠습니다.

Zuul의 원리

Zuul의 중심에는 다양한 필터들이 있으며 이러한 필터들을 통해 http 요청에서 응답까지의 라우팅 및 다양한 작업을 수행할 수 있습니다.

기본적으로 Zuul에서 제공하고 있는 기본 Type 필터에는 PRE, ROUTING, POST, ERROR가 있습니다. 이러한 Filter들은 Chaining 방식으로 아래와 같이 거치도록 되어있습니다.

zuul request lifecycle, 출처 : https://github.com/Netflix/zuul/wiki

• PRE : origin server에 요청이 전송되기전에 실행되는 routing입니다. request의 인증 / 인가등의 확인 및 부여에 사용할 수 있습니다.
• ROUTING : 실제 origin Server로 라우팅하는 것을 처리하는 filter입니다. Apache http client 또는 Ribbon을 이용하여 http 요청을 작성하고 보냅니다.
• POST : origin server에서 응답을 받은 후 실행되는 filter입니다.
• ERROR : PRE, ROUTING, POST filter 처리중 error가 일어났을 경우 실행되는 filter입니다.

Zuul에는 위 4가지의 기본 적인 필터와 추가적으로 custom를 만들 수 있도록 되어있습니다. 그리고 각 Filter에는 아래와 같이 4가지 주요 키워드를 가지고 있습니다.

• Type : filter가 적용되는 시점(PRE, ROUTING, POST, ERROR).
• Execution Order : fileter가 적용되는 시점(Type) 안에서의 순서
• Criteria : Filter가 실행되는 조건
• Action : Filter가 실행될 때 수행되는 실질적인 로직

이런 특징을 가지고 있는 Zuul은 API Gateway의 형태로 가장 많이 사용하게 됩니다. 해당 시스템을 사용하는 모든 사용자는 End-Point인 Zuul에 요청하고 Zuul에서 실제 서비스로 다이나믹 라우팅을 수행하여 실제 서비스를 접근하는 것입니다. 실제 아키텍처는 아래와 같이 가져갈 수 있습니다.

api gateway, example

Zuul의 내부 Dependency

우리는 지금까지 Zuul의 기본원리와 어디에 사용되는지 알아보았습니다. 한가지 추가적으로 집고 넘어가도록 하겠습니다. Zuul은 모든 request가 집중되는 곳입니다. 그래서 장애가 일어나게되면 모든서비스가 동작하지 않게 되는 단일 지점이라는 의미입니다. 그래서 Zuul을 구성할 때 이런 부분을 잘 생각해서 설계할 필요가 있으며 절대 장애가 나서는 안되는 부분이기도 합니다.
그래서 Zuul에는 Retry와 LoadBalancing을 할 수 있는 Ribbon과 장애의 전파를 막아줄 수 있는 Hystrix가 내부 Dependency로 되어있습니다. Zuul을 사용하기 위해서는 반드시 Ribbon과 Hystrix에 대한 이해가 필요합니다. 아래의 Link에 제가 설명한 부분을 참고하시면 좋을것 같습니다.

• Hystrix 관련 포스팅
• Ribbon 관련 포스팅

마무리

오늘은 이렇게 Zuul의 기본 개념과 돌아가는 원리에 대해서 알아보았습니다. Zuul은 일반적으로 위에서 설명한것과 같이 API Gateway로 사용됩니다. 다음시간에는 Zuul을 실습해보도록 하겠습니다.

감사합니다.

참조

https://github.com/Netflix/zuul/wiki