[MSA] Spring Cloud Gateway vs. AWS API Gateway

1. 들어가기 전

  MSA(마이크로서비스 아키텍처(Micro Service Architecture) 로 구성되어 있는 환경에서는 복잡한 시스템에서 서버간 통신을 효율적으로 관리 하기 위해 API Gateway 를 사용하여 설계 하며, 현재 업무에서도 API Gateway 를 사용하고 있습니다. MSA 환경이 아닌 예전에는 L7 또는 L4 장비를 두고 뒷단에 Web Server, WAS(Web Application Server) 를 배치 하는 구조로 설계를 하였습니다. 해당글에서는 MSA 와 같이 분산 환경에서 API Gateway 에 대해서 이해 하고, 여러 Gateway 솔루션 중 개발자 중심의 Spring Cloud Gateway 와 AWS 에서 제공 하는 AWS API Gateway 에 대해서 비교 하고자 합니다.

2. API Gateway 란

  먼저, 두 개 의 서비스를 비교 하기 전에, API Gateway 에 대해서 알아 보겠습니다. 앞서 설명 드린바와 같이, MSA 환경에서는 여러 서버들이 거미줄 처럼 얽혀 있고 서로서로 통신을 하고 있습니다. 이러한 환경에서 서비스간 통신을 효율적이고, 안전하고 그리고 모니터링 및 관리를 할 수 있게 하기 위해 사용되는 것이 API Gateway 입니다.

2.1 특징

   API Gateway 가 가지는 주요 특징은 아래 표와 같습니다.

특징	설명
MSA 관리	API Gateway 는 MSA 환경에서 모든 서버의 공통 엔드포인트 역할을 하며, 클라이언트는 API Gateway 를 통해서 필요한 서비스에 접근 할 수 있게 해줍니다. 이를 통해 모든 서비스를 API Gateway 를 통해서 중앙에서 관리 할 수 있게 해줍니다.
보안	API Gateway 가 없다면, 모든 서비스들이 공통적으로 인증, 인가, SSL 처리를 적용해야 합니다. 하지만, API Gateway를 사용하면, 이러한 기능들을 API Gateway 에서만 처리하고, 각 서비스들은 인증,인가, SSL 기능 없이 오직 서비스에 맞게 개발을 할 수 있게 해줍니다.
로드 밸런싱	로드 밸런싱을 통해 여러 서비스로 트래픽을 분산 시켜 서비스의 안정성을 높이고 성능을 최적화 시킬 수 있습니다.
모니터링 및 감시	요청과 응답을 중앙에서 모니터링 하고 로깅 기능을 제공 하여 요청에 대한 모니터링 및 성능 분석 그리고, 문제 발생 시 신속하게 대응 할 수 있습니다. 또한, 잘못된 요청 또는 공격 패턴에 따라서 최초 진입점 부터 차단 또는 통제 할 수 있습니다.
제한	API 호출 횟수나 데이터 전송 속도를 제한하여 과도한 요청을 방지하고, 서비스 남용을 막습니다.

 

3. 비교 분석

API Gateway 로 사용 할 수 있는 솔루션 또는 서비스들은 다양하고 많습니다. 해당 글에서는 자주 사용되고 있는 개발자 중심의 Spring Cloud Gateway 와 AWS 에서 SaaS 형태로 제공해주는 AWS API Gateway 에 대해서 비교 해보겠습니다.

3.1 Spring Cloud Gateway 와 AWS API Gateway 비교

  아래 그림은 Spring Cloud Gateway 의 아키텍처 그림입니다. Spring Cloud Gateway 는 Spring WebFlux 기반의 비동기 논블럭킹 방식으로 동작하며, 거성능과 확장성을 제공 합니다. 그리고 기본적으로 Netty Server 를 통해서 제공 됩니다. 기본적인 아키텍처 구조는 Route, Predicate, Filter 로 구성되며, Route 는 클라이언트 요청을 목적지로 전달 하며, Predicate 는 요청이 Route에 매칭되는지 여부를 결정 합니다. 또한 Filter 는 요청 및 응답의 전/후 처리 작업을 담당하며, 인증, 로깅, 예외처리 등 부가 기능을 제공 합니다. 이러한 Spring Cloud Gateway 뒷단에 여러 마이크로 서비스들이 연결 되어 통합 서비스를 제공 합니다.

Spring Cloud Gateway 아키텍처

  아래 표는 Spring Cloud Gateway 와 AWS API Gateway 의 비교 내용을 나타냅니다.

구분	Spring Cloud Gateway	AWS API Gateaway
플랫폼	오픈 소스 프로젝트로 자바 기반의 스프링 프레임워크로 구성되며, 자유롭고 자체 적으로 개발 가능	AWS 에서 호스팅 되는 관리형 서비스로 AWS 클라우드 인프라에서만 사용 가능
관리 방식	개발자가 직접 관리하며 개발자가 모든 책임을 가짐	AWS 에서 자동 관리하며 AWS 콘솔을 통해서 관리
확장성	다양한 환경에서 실행 되며, 개발자가 원하는 데로 커스터마이징 가능	AWS의 서비스와 통합되어 확장가능 하며 자동 스케일링 가능

  두 개의 서비스를 비교 하면 크게 개발자가 얼마 만큼 권한과 책임을 가지냐에 따라서 달라질 수 있다는 것을 알수 있습니다. 만약, 개발자에게 커스타미이징 또는 모든 권한과 책임을 가지고 직접 개발을 해야 하는 상황이라면 Spring Cloud Gateway 를 사용하고, 어느정도 Gateway 관리에 대한 부담을 덜고 AWS 인프라와 쉽게 통합 시키고자 한다면 AWS API Gateway 를 사용하는게 좋을 것 같습니다.

  하지만, 무엇보다 사용하고자 하는 회사 또는 부서의 요구사항 또는 프로젝트 과업범위와 비용을 모두 고려하여 결정해야 할 것으로 보입니다.

3.2 보안을 생각하면..

  보안을 중요시 하는 회사 또는 프로젝트의 경우 AWS API Gateway 사용을 하기에는 힘들것으로 보입니다. 이럴 경우 자연스럽게 개발자 중심의 Spring Cloud Gateway 를 선택 해야 할것입니다. 다른 대안으로는 설치형으로 사용 할 수 있는 Kong Gateway 도 사용 할 수 있을 겁니다. Kong 또한 오픈 소스 API Gateway 이며, Proxy 및 Routing, 로드 밸런싱, 인증 및 인가, 모니터링 및 로깅과 같은 다양한 기능을 제공합니다.

  Kong Gateway 의 아키텍처는 아래 그림과 같습니다. Kong 은 Free 버전과 엔터프라이즈 버전이 존재 하며, 자체 관리자 기능과 다양한 플러그인을 제공하여 확장 할 수 있습니다. 다만, 커스텀 플러그인은 Lua Script 기반으로 제작하여야 하는 단점이 있습니다. 이러한 환경에서는 Spring Cloud Gateway 와 Kong 을 API Gateway 로 사용 함에 있어 고려 해볼 수 있습니다.

Kong Gateway 아키텍처

4. 마무리

  이번 글에서는 MSA 환경에서 서비스를 제공하기 위해 빠질 수 없는 API Gateway 에 대해서 간략히 살펴 보았습니다. 아무래도 예전 웹 어플리케이션 구성과 다르게 적용되고 있는것을 알 수 있으며, API Gateway 를 사용함으로써 보다 공통된 기능과 공통 진입점을 만들고 기존 서비스들은 Gateway 뒷단에 경량화 된 서비스로 구성 할 수 있는 것을 알 수 있습니다. 이러한 API Gateway 를 적용 하기 위해 고려 사항으로는 개발자 중심 또는 관리 중심으로 나뉠 수 있으며 주로 Spring Cloud Gateway, Kong Gateway 그리고 AWS API Gateway 등을 고려 할 수 있습니다. 하지만 무엇보다도 본인이 속한 팀 그리고 프로젝트에 적합한 환경에 맞는 API Gateway 를 선택하고 설계 하는것이 가장 최적이라고 생각합니다.

5. 참고 문서

• https://docs.konghq.com/gateway/latest/