[MSA] API Gateway

최근 많은 서비스들이 독립적인 기능을 수행하는 작은 단위의 서비스들로 구성된 마이크로 서비스 아키텍처(Micro Service Architecture) 형태로 구축되면서 서비스의 복잡도를 줄일 수 있게 되었고, 변경에 따른 영향을 최소화하면서 개발과 배포를 할 수 있다는 장점도 얻게 되었다.

 

하지만 여기서 말하는 작은 단위의 서비스가 50개, 100개가 되었을 때, 이 많은 서비스들의 엔드포인트를 관리하는 데 있어서 어려움이 생기고, 또 각각의 서비스마다 공통적으로 들어가는 기능(ex 인증/인가, 로깅 등)들을 중복으로 개발해야 한다는 문제점이 발생한다.

 

이러한 문제점을 해결하기 위해 등장한 것이 바로 API Gateway이다.

 

API Gateway란?

API Gateway Service는 사용자가 설정한 Routing 설정에 따라 각 endpoint로 클라이언트를 대신해서 요청하고, 응답을 받으면 다시 클라이언트에게 전달해 주는 역할을 한다.

 

 

다시 말해,

클라이언트는 각 서비스의 엔드포인트 대신에 API Gateway로 요청을 보내게 되며, 요청을 받은 API Gateway는 설정에 따라 각 endpoint로 클라이언트를 대신하여 요청하고, 응답을 받으면 다시 클라이언트에게 전달하는 프락시(proxy) 역할을 한다.

 

• API Gateway는 클라이언트와 각각의 서비스들 사이에 위치한다.
• 시스템의 내부 구조는 숨기고 외부의 요청에 대해 적절한 형태로 가공해서 응답할 수 있는 장점이 있다.

 

API Gateway Service가 없을 경우,

클라이언트에서는 microservice를 호출할 때, 클라이언트 쪽에서 endpoint를 설정하게 된다. 그런데 만약 microservice의 설정이 변경되어 endpoint가 변경되거나, 새로운 microservice가 추가되어 이에 해당하는 endpoint를 클라이언트에 추가할 때 클라이언트도 관련해서 수정 및 재배포가 이뤄저야 한다. 이러한 불편함을 없애고자 단일 진입점이 존재하는 개발이 필요하게 되었다.

 

API Gateway의 주요 기능

• 인증 및 권한 부여
• 서비스(마이크로서비스 등) 검색 통합
• 응답 캐싱
• 정책, 회로 차단기 및 QoS 다시 시도
  •  클라이언트가 요청한 Micro Service에 문제가 생기면 그 회로를 차단한다.
• 속도 제한
• 부하 분산
  • 예를 들면, A라는 Micro Service가 3개의 인스턴스로 나누어졌을 경우에도 판단 가능하다.
• 로깅, 추적, 상관관계
  • 하나의 서비스가 다른 서비스를 호출하는 경우도 많은데 진입점 및 중간 단계를 거치고 그다음 단계는 어디인지도 추적 가능하다.
  • 이를 위해서는 Logging 하는 작업 필요하다.
  • Api Gateway는 어떤 클라이언트가 어느 서비스에 요청했는지 로그 파일을 처리 가능하다.
• 헤더, 쿼리 문자열 및 청구 변환
• IP 허용 목록에 추가
  • 목록에 추가 허용할 수 있는 IP와 차단 IP를 처리한다.
  • 일종의 방화벽처럼 사용 가능하다.

 

 

1. 인증/인가 및 토큰 발급

인증/인가의 경우, 각 서비스마다 공통으로 구현되어야 하는 필수적인 기능이다.

각각의 서비스마다 인증/인가 처리를 구현하는 것은 매우 비효율적이다. 따라서, API Gateway에서 이를 처리하게 된다.

 

인증 서버

 

Spring으로 예를 들면, 각각의 서비스에 Spring Security 의존성을 추가하여 해당 기능을 구현하는 것을 말한다.

 

또한, API 사용을 위한 토큰 발급 기능도 마찬가지 이유로 API Gateway에서 처리된다. 실제로 토큰 발급 기능은 인증을 위한 서비스(= 인증 서버)를 하나 두고 거기에서 처리된다.

• 인증(Authentication) : 해당 사용자가 본인이 맞는지를 확인하는 절차
• 인가(Authorization) : 인증된 사용자가 요청한 자원에 접근 가능한지를 확인하는 절차

 

2. 공통 로직 처리

인증/인가 외에도 여러 서비스에서 공통적으로 처리해야 할 기능들이 있다.

공통되는 기능을 각각의 서비스마다 구현하는 것은 번거로울 일일뿐더러 코드 수정이 필요할 때, 각각의 서비스를 다 수정해야 하는 등, 유지보수 측면에서의 어려움도 존재한다.

 

공통 로직 처리

 

따라서, 공통적으로 사용되는 로직의 경우 API Gateway에서 구현되는 것이 효율적이며, 개발 중복을 줄이는 것뿐만 아니라 표준 준수도 쉽다는 장점을 가지고 있다.

 

최근에는 API 호출 로깅을 통한 클라이언트의 API 호출 패턴을 분석하여 활용하는 것이 빅데이터의 특면에서 중요한 자산으로도 다뤄지고 있다.

 

3. 로드밸런싱

대용량 처리 서비스에 있어서 로드밸런싱은 필수적이다.

기본적으로는 여러 개의 API 서버로 부하를 분산하는 기능이 주가 되겠지만, API 서버에 장애가 발생했을 때 이를 감지해서 로드밸런싱 리스트에서 빼고, 복구되었을 때 다시 로드밸런싱 리스트에 넣는 기능들이 필요하다. (health-check)

 

4. 메디에이션 기능(Mediation)

메디에이션 기능 중에는 메시지 호출 변화(Message Exchange Pattern)가 있다. 

메시지 호출 패턴은 동기(Sync), 비동기(Async)와 같은 API를 호출하는 메시지 패턴을 정의하는 것인데, API Gateway를 이용하면 아래와 같이 동기 호출을 비동기 호출로 바꿀 수 있다.

 

API Gateway에서의 Message Exchance Pattern

 

또한, 클라이언트의 요청을 하위 서비스가 처리할 수 있도록 데이터 형식을 변형하거나, 하위 서비스의 응답 표준 포맷으로 데이터 형식을 변형하는 메시지 포맷 변환(Message format transformation) 기능도 있다.

 

반응형

 

Spring과 API Gateway의 역사

1. RestTemplate와 Feign Client

과거에는 Spring Cloud에서의 MSA 간 통신을 위해 RestTemplate, Feign Client를 주로 사용했었다.

• RestTemplate
  • 전통적인 사용법이다.
  • 하나의 웹 애플리케이션에서 다른 애플리케이션을 사용하기 위해 사용된 API이다.
  • 다른 애플리케이션을 호출할 때 접속하고자 하는 서버의 주소, port 번호 등을 기재해야 했다.
• Feign Client
  • Spring Cloud에서 사용하는 API이다.
  • interface를 생성하고 외부 microservice 이름만으로 다른 microservice를 호출할 수 있다.

 

하지만, RestTemplate와 Feign Client는 단일 인스턴스의 서비스를 호출할 때는 잘 동작하지만, 마이크로서비스 아키텍처와 같이 많은 수의 서비스 인스턴스가 있는 환경에서는 부족한 점이 있었다. MSA 환경에서는 서비스 인스턴스의 동적인 변화, 로드 밸런싱, 장애 처리 등을 고려해야 했다.

 

Netflix의 Ribbon은 이러한 문제를 해결하기 위해 개발되었다.

 

2. Netflix Ribbon

Spring Cloud는 Load Balancer를 해주는 별도의 서비스를 위해 Netflix의 Ribbon을 채택하여 제공했다.

 

Ribbon은 클라이언트 측 로드 밸런싱을 지원하고, 서비스 디스커버리와 통합하여 동적으로 서비스 인스턴스를 찾고 호출하는 기능을 제공한다. 또한, 장애 처리와 재시도 메커니즘을 내장하고 있어서, 네트워크 문제나 서비스 장애 시 적절히 대응할 수 있다. (Health Check)

• 클라이언트 측 내부에 Ribbon을 구축해서 사용한다.
• 클라이언트 안에서 이동하고자 하는 주소값을 직접 관리한다.
• ip:port를 명시 안 해도 서비스를 이름만으로 호출 가능하다.

 

하지만, Netflix Ribbon도 리액트와 같이 비동기를 사용하는 기술들과의 호환이 잘 안 되는 문제가 발생했고 최근에는 잘 사용하지 않는다.

 

Spring Boot 2.4에서 Maintenance 상태가 되었다. 즉, Spring boot 2.4 이상 버전에서는 지원하지 않는다.

• Maintenace : 다음 버전에서 사용할지 이 기술을 빼거나 보완하려는 상태

 

3. Netflix Zuul

Netflix OSS(Open Source Software) 프로젝트의 일부로 개발되었으며, Netflix에서 제공하는 API Gateway 또는 API Service 기술이다. 마이크로서비스 아키텍처에서 여러 클라이언트 요청을 적절한 서비스로 프락시 및 라우팅 하기 위한 서비스이다.

• JVM-based router 및 Server-side load Balancer이다.
• 내부적으로 Eureka 서버를 사용하고, 부하 분산을 위해 Ribbon을 사용한다.
• Eureka Client이다.
• Eureka 및 Ribbon과 함께 사용할 수 있도록 만들어진 기술이다.

Ribbon과 마찬 가지로 maintenance 상태이며, Spring boot 2.4 이상 버전에서는 지원하지 않는다.

 

4. Spring Cloud Gateway

• Spring 생테계를 기반으로 하는 API Gateway를 제공해 준다.
• Spring Cloud Gateway는 간단하지만 효율적인 방법으로 API를 라우팅 하는 방법을 제공한다.
• 그 외에도 security, monitoring/metrics, resiliency 등과 같은 공통 관심사를 처리해 준다
• 최신의 버전은 Spring 6, Spring Boot 3 and Project Reactor를 기반으로 동작한다.
• 비동기 처리가 가능하며, 동기 방식인 Tomcat 서버가 아닌 비동기 방식인 Netty 서버로 실행된다.

 

---

비동기 방식이란?

비동기 방식은 작업을 동기적으로 기다리지 않고, Reactive Programming을 통해 blocking process로 동작하는 애플리케이션을 non-blocking process로 변환하는 프로그래밍 방식이다.

 

기존 Spring - Blocking 방식

• Web에서 서버에 요청이 왔을 때 서버는 요청에 대한 적절한 응답을 보내야 하는데 만약 작업이 오래 걸릴 경우에는 요청에 대한 응답이 모두 종료될 때까지 Blocking 됐다.
• 이런 이유로, Spring에서는 동시 요청 처리를 위해서 멀티 Thread를 지원하였고 Thread마다 다른 요청을 할당받아서 처리한다.
• 물론 요청을 동시에 처리하니 비동기처럼 보일 수 있겠지만, Thread가 늘어날수록 Thread할당에 필요한 Resource가 늘어나게 되어 비효율적이다!

Spring 5 - Non-Blocking

• Spring 5가 도입되면서 클라이언트 요청에 별도의 Thread를 생성하지 않고 buffer를 사용해서 요청을 받고 요청을 Back단에서 처리하는 Thread를 둔다.

 

그럼 왜 Non-blocking 방식이 사용될까?

만약, 수 천 개의 Stream Data 가 초 당 계속 Update 되는 시스템이라면, 적절하게 응답을 해야 하는 경우 기존의 Blocking 방식은 상당한 부하가 걸린다. 따라서, 부하를 효율적으로 처리하는 목적을 가지고 있다.

 

---

 

Spring Cloud Gateway

1. Spring Cloud Gateway의 동작 순서

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

동작 방식

 

2. Spring Cloud Gateway 장점과 단점

장점

• 요청을 다른 서버로 라우팅 시키는 부분을 간단한 yaml 파일로 완성할 수 있다
• Non-Blocking 기술 기반이라 라우팅에 집중된(I/O 작업이 많은) 프로젝트에 최고의 성능을 보일 수 있다
• 라우티 전/후에 손쉽게 부가 기능을 추가할 수 있다.
  • GatewayFilter를 등록할 수 있고, 이미 많은 필터를 제공해주고 있다.
  • 예시) 헤더 추가 필터, RateLimit 필터 등

 

단점

• 추가 기능의 구현을 WebFlux 기반(리액티브)으로 작성해야 하므로 어려울 수 있다.
• 라우팅 대상 서버가 많아진다면 관리가 어려울 수 있다.

 

---

 

참고자료

https://mangkyu.tistory.com/230

https://velog.io/@jkijki12/Zuul%EC%9D%B4%EB%9E%80

https://wildeveloperetrain.tistory.com/205

https://velog.io/@sungjin0757/Spring-Cloud%EB%A1%9C-%EA%B0%9C%EB%B0%9C%ED%95%98%EB%8A%94-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-API-GATEWAY