[Spring] Spring Cloud Gateway(스프링 클라우드 게이트웨이) 공식 문서 간단히 살펴보기 및 리서치 후기

아래의 내용은 Spring Cloud Gateway의 공식 문서를 보고 요약 정리한 내용입니다.

 

 

 

 

1. Spring Cloud Gateway 공식 문서 간단히 살펴보기

---

[ Spring Cloud Gateway란? ]

• Spring 생테계를 기반으로 하는 API Gateway를 제공해주는 프로젝트
• Spring Cloud Gateway는 간단하지만 효율적인 방법으로 API를 라우팅하는 방법을 제공함
• 그 외에도 security, monitoring/metrics, resiliency 등과 같은 공통 관심사를 처리해줌
• 최신의 버전은 Spring 6, Spring Boot 3 and Project Reactor를 기반으로 동작

 

 

[ Spring Cloud Gateway의 동작 순서 ]

1. Client는 Spring Cloud Gateway 서버로 요청을 보냄
2. Gateway Handler Mapping에서 요청이 매핑된다고 판단하면 Gateway Web Handler로 요청을 보냄
3. Gateway Web Handler는 매핑되는 요청을 위한 필터 체인을 거쳐 요청을 실행함

 

 

 

 

[ 요청을 라우팅하기 위한 구분 조건 ]

• The After Route Predicate Factory: 날짜 파라미터를 받아 지정된 날짜 시간 이후에 발생하는 요청을 라우팅함
• The Before Route Predicate Factory: 날짜 파라미터를 받아 지정된 날짜 시간 이전에 발생하는 요청을 라우팅함
• The Between Route Predicate Factory: 날짜 파라미터를 받아 지정된 날짜 시간 사이에 발생하는 요청을 라우팅함
• The Cookie Route Predicate Factory: 특정 쿠키값을 기준으로 라우팅함
• The Header Route Predicate Factory: 특정 헤더값을 기준으로 라우팅함
• The Host Route Predicate Factory: 호스트 헤더값을 기준으로 라우팅함
• The Method Route Predicate Factory: HTTP METHOD값을 기준으로 라우팅함
• The Path Route Predicate Factory: 요청 PATH값을 기준으로 라우팅함
• The Query Route Predicate Factory: 요청 Query Parameter값을 기준으로 라우팅함
• The RemoteAddr Route Predicate Factory: RemoteAddr값을 기준으로 라우팅함
• The Weight Route Predicate Factory: weight, group 값을 기준으로 라우팅함

 

 

[ yaml 파일 작성 예시 ]

spring:
  cloud:
    gateway:
      routes:
        - id: host_mangkyu
          uri: https://host-mangkyu.com
          predicates:
            - Host=host-mangkyu.com # host-mangkyu.com을 Host의 헤더로 요청이 들어오는 경우 해당 uri로 라우팅
        - id: cookie_mangkyu
          uri: https://cookie-mangkyu.com
          predicates:
            - Cookie=MANGKYU_SES, ej* # MANGKYU_SES ej* 정규식에 매칭되는 MANGKYU_SES 쿠키로 요청이 들어오는 경우 해당 uri로 라우팅
        - id: path_mangkyu
          uri: http://path-mangkyu.com
          predicates:
            - Path=/hello/{path} # /hello/{path} 경로로 요청이 들어오는 경우 해당 uri로 라우팅

 

 

 

 

 

2. Spring Cloud Gateway에 대한 간단한 후기

---

[ Spring Cloud Gateway 장점과 단점 ]

• 장점
  • 요청을 다른 서버로 라우팅시키는 부분을 간단한 yaml 파일로 완성할 수 있음
  • Non-Blocking 기술 기반이라 라우팅에 집중된(I/O 작업이 많은) 프로젝트에 최고의 성능을 보일 수 있음
  • 라우티 전/후에 손쉽게 부가 기능을 추가할 수 있음(GatewayFilter를 등록할 수 있고, 이미 많은 필터를 제공해주고 있음)
    ex) 헤더 추가 필터, RateLimit 필터 등
• 단점
  • 추가 기능의 구현을 WebFlux 기반(리액티브)으로 작성해야 하므로 어려울 수 있음
  • 라우팅 대상 서버가 많아진다면 관리가 어려울 수 있음

 

 

[ Spring Cloud Gateway 리서치 후기 ]

현재 우리 팀에서는 서로 다른 계열사들의 API를 통합하는 통합 게이트웨이를 구축해야 하는 상황이다. 요청량도 당연히 많을 것이기에 컨테이너 기반의 인프라 구축에 집중하고자, 최소한의 코드로 최대의 효율을 뽑아낼 수 있는 오픈 소스를 찾아보게 되었다.

스프링 클라우드 게이트웨이를 사용해 프로토타이핑을 해보니, 역시나 요청을 라우팅하는 부분을 매우 편리하게 구현할 수 있었다. 그리고 현재로써는 라우팅 외에 별도의 부가 기능이 당장은 필요가 없어 1차적으로 적합하다고 판단했다.

 

그 외에도 사내 플랫폼에서 API Gateway라는 서비스를 제공해주고 있어서, 이 역시도 살펴보았다. 웹 기반으로 편리하게 현재의 요구사항을 충족시킬 있었다. 그래서 직접 구축할 것인가 or 플랫폼을 사용할 것인가 고민이 되었는데, 그 과정에서 여러 부분을 고려하였다.

• 현재의 모든 요구사항을 충족시키는가?
• 팀원들이 사용하기 쉬운가?
• 러닝 커브가 높지 않은가?
• ...

 

스프링 클라우드 게이트웨이는 당장 사용하기는 쉽지만 새로운 요구사항을 집어넣기 어려울 것이라고 판단했다. 개인적으로는 리액티브 스택을 사용해보고 싶었지만, 다들 어려움을 많이 겪을 것 같아서 회의 때 최대한 스프링 클라우드 게이트웨이를 지양하자고 했다.

물론 확장이 어려운 건 플랫폼도 마찬가지이다. 그래서 타 서비스로의 라우팅은 플랫폼에 전적으로 위임하고, 새로운 요구사항이 생겼을 때 우리의 코드를 추가할 수 있는 구조를 떠올리고 구성하게 되었다.