[서버개발캠프] MSA 아키텍쳐의 API Gateway 프레임워크 결정

Sieun Sim·2020년 1월 23일

서버개발캠프

목록 보기

9/21

우리 프로젝트 MSA 아키텍처

API Gateway

API 게이트웨이는 클라이언트 앱과 마이크로 서비스 사이에 위치합니다. 클라이언트에서 서비스로 요청을 라우팅하는 역방향 프록시로 사용됩니다. 또한 인증, SSL 종료 및 캐시와 같은 추가 교차 편집 기능을 제공할 수 있습니다. 사용자의 API 게이트웨이 서비스는 클라이언트 앱의 다양하고 많은 요구 사항을 기반으로 늘어나고 진화하므로 그러한 사실은 중요한 위험입니다. 결국 이러한 다른 요구 사항으로 인해 너무 커지면 사실상 모놀리식 애플리케이션 또는 모놀리식 서비스와 상당히 비슷할 수 있습니다. 예를 들어 API 게이트웨이를 여러 서비스 또는 더 작은 여러 API 게이트웨이로 클라이언트 앱 양식 팩터 형식당 하나씩 분할하는 것이 좋습니다.

MSA인 우리 프로젝트에서 각 기능 서버들을 앞에서 관리할 management API 같은 느낌. 결국 병목현상을 막으려면 게이트웨이에 대한 서버 scale out이 필수적이라는데 우리는 일단 구현이 먼저니까 단일 게이트웨이 서버로 진행하고 빨리빨리 잘 진행되면 노드를 추가해서 proxy까지 붙여보고 싶다.

API Gateway를 위한 프레임워크 결정과정

Spring Cloud Gateway vs Netflix zuul

초기 버전인 spring-cloud-zuul 에서는 Netflix Zuul 1 을 사용했다.

비동기를 지원하기 위해 Netflix 는 Zuul 2 로 업그레이드

Zuul 은 Spring Eco 시스템의 취지에 맞지 않아, Spring Cloud Gateway 에서는 Zuul 2 를 사용하지 않고 새로 만들게 됨

Zuul은 다른 기업용 API 게이트웨이 제품과는 달리 개발자가 특정한 요구 사항에 알맞게 설정하고 프로그래밍할 수 있게

개발자에게 완전한 통제권을 준다.

Zuul 프록시는 내부적으로 서비스 탐색을 위해 Eureka(유레카) 서버를 사용하고, 서비스 인스턴스 사이의 부하 분산을 위해 Ribbon(리본)을 사용한다.

Zuul은 API계층에서 서비스의 기능을 재정의해서 뒤에 있는 서비스의 동작을 바꿀수 있다.

Zuul Components

zuul은 zuul-core, zuul-simple-webapp, zuul-netflix, zuul-netflix-webapp 4개의 컨포넌트로 구성한다.

zuul-core : 위에서 설명한 Zuul의 Request Lifecycle를 담당하고, Fliter를 컴파일하고 실행한는 기능을 담당하고 있는 Zuul의 core library
zuul-netflix : 기본적은 Zuul에 NetflixOSS library를 추가한다.
zuul-simple-webapp : zuul-core만 사용한 아주 기본적은 web application
zuul-netflix-webapp : zuul-core와 zuul-netflix를 함께 사용한 web application

API GATEWAY를 구축하기 위해서는 zuul-simple-webapp를 사용하다는 것은 MSA 환경에서 아주 유용한 NetflixOSS library를 포기하는 것이다. zuul-netflix-webapp을 도입하기에는 학습곡선이 크다. 그래서 찾은게 spring cloud netflix 프로젝트이다.

우형분들께서 그러셨다는데 내가 zuul2.0을 도입할 수 있을 지 확신이 안선다.... zuul만 공부하게 되면 안되는데

Zuul 2.0에서 Zuul 1보다 나아진 점

블록킹 → 논-블록킹 시스템, netty 적용, Limit Rate, 웹소켓 지원 등.. 이 내용 대부분은 sping cloud gateway에서도 지원한다

우리 프로젝트에 zuul 2.0 vs spring cloud zuul(1.0) vs spring cloud gateway

아니 스프링 왜 2.0 지원 안해줘요....

특히 zuul 2와 sping cloud gateway 의 성능을 비교한 글이 참 많이 보이는데 spring boot 2와 spring cloud 2가 릴리즈 된 후에는 spring gateway의 성능이 훨씬 뛰어나다는 분석이 있다.

출처: https://www.bytesville.com/zuul-spring-cloud-gateway-comparison-benchmarks-loadtesting/

배달의 민족에서 17년도에 spring cloud zuul(1.0)을 도입한 내용이 있고, 카카오의 18년 컨퍼런스에는 Spring cloud gateway를 사용한 내용이 있다. 배달의 민족 글은 zuul 2.0이 나오기도 전인 것 같아서 고려하기 힘들고 zuul 2.0도 나온지 2년이 다되어가는데 굳이 1.0은 쓰기가 왠지 싫다. 근데 스프링에서 지원하니까 구현하기엔 편할 것 같고.. spring cloud gateway는 일단 spring 생태계니까 안전빵에 자료도 많을 것 같긴 하다. zuul이 궁금해서 써보고싶었지만 ㅠㅠ spring cloud gateway에서도 여전히 zuul의 hytrix 같은 것들을 지원하는듯 하다.

Spring Cloud gateway

When it comes to choosing an API gateway for your microservices, there are a variety of options: Zuul from netflix, Kong, Nginx, HAProxy, Traefik, cloud vendor's solutions such as Amazon API Gateway or Google Cloud Endpoints and (the new) Spring Cloud gateway from Pivotal.Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs. When it receives request, Spring Cloud Gateway forwards it to a Gateway Handler Mapping, which determines what should be done with requests matching a specific route. Instead of taking a traditional approach and listing all the features, I rather prefer to build a small , microservices based project, that showcase and describe it usage

출처: https://aboullaite.me/spring-cloud-gateway/

이 글의 small이라는 말에 대충 결정짓게됐다. 기존 스프링에 잘 얹어서 사용하는 느낌인 것 같아서 편하고 빠르게 적응하기에 나을 것 같다 시간이없서

Gateway에 message queue를 붙일 필요성

대용량 트래픽에는 필수인 것 같긴 하다. 우리가 쓰기로 한 툴들은 이미 너무 훌륭하고 이대로 잘 된다면 대용량 트래픽에 필요한 구조를 더 완벽하게 갖추어봐도 되지 않을까 싶다. 물론 거기까지 갈 수 있을지도 아직 확실하지 않으니 우선 보류하기로 한다. 많이들 쓰는 RabbitMQ를 써보고 싶긴 한데 우선 어느정도 형태가 나오면 큐를 붙이기 전과 후의 차이를 테스트해가면서 천천히 붙여보고 싶다.