1 API Gateway 기초
1.1 API Gateway 란
image source : https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
하나의 입구에서 다양한 API(Application Programming Interface)의 요청을 받아주고, 요청에 따라 백엔드의 구성을 유연하게 가져갈 수 있도록 하는 Gateway이다.
API Gateway는 온라인 API로 제공되는 서비스들이 많아지고, 백엔드의 구성이 monolithic 에서 microservice로의 전환되면서 Client 가 사용해야하는 API의 종류와 수가 늘어나면서 필요성이 높아졌다.
문지기처럼 우리가 구성하는 여러 서비스에 가장 앞단에 둬서 유저가 웹브라우저로 접속하던지, 모바일로 접속하던지, IoT(Tcp 등 경령화 된 프로토콜)쓰던지, 다른 곳에서 보호된 환경으로 접속을 하던지 하나의 입구로 맞춰주는 것.
API Gateway는 요청에 따라 논리적으로 판단해서 그 뒤에 어떤 서비스를 연결할지 다양하게 가져갈 수 있다.
장점
- Client 는 하나(또는 적은 수)의 endpoint만을 이용해서 다양한 서비스를 이용할 수 있다.
- Gateway를 통해서 구현에 종속되지 않고 추상화되고 논리적인 서비스 구조를 만들 수 있다.
- Backend service 로의 direct access를 피하고, 유연성을 가져갈 수 있다.
API Gateway 활용 예시
예를 들어, 개발 초기 단계에서 User API와 Customer API를 만들 계획이라면, 먼저 프론트엔드 개발자와의 협의를 통해 인터페이스(API 명세)만 정의할 수 있다. 이때, API Gateway 상에 해당 API 엔드포인트만 미리 만들어두고, 응답은 일단 "200 OK"로 고정해둔다.그 이후 백엔드 개발자는 실제 구현에 착수하며, 어떤 아키텍처로 구성할지, 네트워크 포트는 어떻게 설정할지, 어떤 DB를 사용할지 등을 자유롭게 결정할 수 있다. 이러한 방식은 개발 진행 중 아키텍처나 내부 구현이 변경되더라도, 인터페이스(API)는 변경하지 않아도 되기 때문에 프론트엔드와의 연동에는 영향을 주지 않는다.
API Gateway는 프론트엔드와 백엔드 사이의 계약(API 인터페이스)을 먼저 정의하고, 그 이후에 내부 아키텍처를 유연하게 구성할 수 있게 해주는 구조적 이점을 제공한다. 이는 API 일관성 유지, 개발 병렬화, 변경 최소화 등의 장점을 가져온다.
단점
- Direct access 보다 network hop이 하나 더 생긴다. latency 가 늘어날 수 있다.
- Gateway에 장애가나면 SPOF(Single Point of Failure)가 될 수 있다.
- 요구사항에 따라 API의 Gateway의 복잡성이 늘어날 수 있다.
1.2 API Gateway의 종류
API Gateway는 특별히 API Gateway 전용으로 나온 product들이 있다기 보다는, 어떤 product에서 API Gateway 기능도 할 수 있도록 지원하는 것으로 이해하는 것이 좋다.
제품이 다양하지만, 오픈소스 프로젝트들은 시간이 지나면 하나둘씩 기능들을 채워나가게 돼서, 기능에서 큰 차이가 없다.
1.2.1 Cloud Service API Gateway
AWS, Azure, GCP 등에서 서비스 형태로 제공하는 Gateway이다. 전문 지식이 없더라도 UI를 통해서 설정하면 바로 이용할 수 있고, 고가용성 제공, 버전 관리의 용이성 등이 있다.
단점은 제공하는 기능 외에 custom 한 로직이 상세하게 필요하다면 사용할 수 없다. 또한 API call수가 많아지면 비용이 부담될 수 있다. 작은 규모의 서비스라면 무료로 제공하기도 한다. 서비스 규모가 크지 않으면 Cloud Sevice 를 쓰는 것을 가장 추천한다.
1.2.2 NGINX
어? 앞에서 Web Server라고 하지 않았었나?
NGINX의 기능을 보면 요청에 따라 연결할 수 있는 대상을 변경할 수 있다. (어떤 서버한테 이 트레픽을 연결해줘 이런 기능.)
즉, API Gateway로서도 기능할 수 있다는 것이다. 다만, NGINX의 구조적 한계 때문에 설정을 변경하고 배포하는 것이 어렵고(API Gateway스럽지 않고 static하다), 설정의 형식 때문에 (옛날 방식으로 되어 있어서) 추상화된 수준을 설정으로 녹여내기 어렵다는 단점이 있다.
다만, 소규모의 서비스이고 어차피 NGINX를 써야한다면 API Gateway를 따로 구축하는 것 보다는 비용을 아낄 수 있다.
1.2.3 KONG
NGINX를 기반으로 만들어진 API 서비스 및 통합형 관리도구. 비슷한 것으로 APISIX라는 오픈소스 있다.
1.2.4 Istio
Istio는 Envoy 프록시를 기반으로 설계된 Service Mesh 플랫폼으로, 마이크로서비스 아키텍처 환경에서의 트래픽 관리, 보안, 모니터링 등을 효과적으로 지원한다. 특히 서비스 디스커버리(service discovery) 기능과 통합되어 다양한 마이크로서비스 간의 통신을 유연하고 안정적으로 구성할 수 있도록 돕는다.
(현재는 Istio 외에도 다양한 도구들이 서비스 디스커버리를 지원한다.)
Sidecar Proxy 구조
Istio는 각 애플리케이션 컨테이너 옆에 사이드카 프록시(sidecar proxy)를 배치한다. 이 프록시는 애플리케이션과는 독립된 가상 네트워크 환경에서 동작하며, 해당 애플리케이션의 네트워크 트래픽을 모두 제어한다. 이 구조 덕분에 클라이언트(예: 서비스 A)는 DNS 조회 없이도 직접 서비스 B에 접근할 수 있고, 분산 환경에서도 빠르고 안정적인 통신을 할 수 있게 된다.
image source : https://sigridjin.medium.com/istio-and-service-mesh-c1a76a1b0593
Istio가 적합한 이유
분산 환경에서 여러 서비스를 컨테이너로 배포한다고 가정한다. 예를 들어, 서비스 A(Java 애플리케이션)가 서비스 B에 요청을 보낸다고 하자.
- 기존 방식 (Service Discovery 미지원)
서비스 디스커버리를 지원하지 않는 경우, 각 서비스는 DNS를 통해 상대 서비스의 위치를 알아낸다.
예: 서비스 A →serviceb.com/customerAPI
이때, 서비스 A는 외부 DNS 서버에 질의해 IP 주소를 받아오고, 해당 IP로 요청을 전달한다.
이 방식은 다음과 같은 단점이 존재한다.
- 새로운 컨테이너가 뜨면 DNS 갱신 필요
- DNS 캐시로 인해 반영까지 수 분이 소요됨
- 네트워크 홉 수 증가로 인한 성능 저하 가능성
- Istio 방식 (Sidecar + Service Mesh)
Istio를 도입한 경우, 서비스 A가 배포될 때 함께 배포되는 사이드카 프록시가 Istio 컨트롤 플레인으로부터 서비스 B의 최신 위치 정보를 공유받는다.
서비스 A가 서비스 B의 API를 호출하면, 프록시는 DNS 조회 없이 서비스 B의 위치를 즉시 파악해 요청을 전달한다. 서비스 B가 죽고 새로 띄워진 컨테이너로 이동하더라도, 사이드카들은 이 변경사항을 자동으로 반영한다.
이 방식은 다음과 같은 장점이 있다.
- DNS 없이 직접 라우팅하므로 네트워크 홉 수 감소
- IP 변경 및 컨테이너 재배포 상황에서도 자동 처리
- 서비스 간 통합 속도 및 개발 생산성 향상
Istio와 같은 서비스 메시 아키텍처는 마이크로서비스 기반 시스템에서 유지보수성, 확장성, 가시성 확보에 매우 유리하다. 특히 Kubernetes와 결합할 경우 자동화된 통신 제어와 서비스 정책 적용이 가능하므로, 복잡한 시스템에서의 통신 구조를 단순화하고 효율화할 수 있다.
Istio는 다음과 같은 흐름 속에서 발전해 왔다.
- 마이크로서비스 아키텍처 확산
- 컨테이너 및 Kubernetes의 대중화
- Apache Mesos 등 초기 분산 시스템 도구들의 한계 극복
Istio는 사이드카 프록시 기반의 서비스 메시 구조를 통해 마이크로서비스 간의 통신을 중앙에서 제어하고, 성능, 안정성, 개발 속도, 확장성 측면에서 큰 이점을 제공하는 도구이다. 분산 시스템의 복잡도를 줄이고, 대규모 시스템 운영을 수월하게 만들어준다.
1.2.5 Spring Cloud Gateway
Spring Cloud Gateway는 Spring 프레임워크를 기반으로 직접 API Gateway 로직을 구현하고 배포할 수 있는 솔루션이다. 대부분의 백엔드 서비스가 Spring 기반으로 구성되어 있다면, Spring Cloud Gateway를 통해 서비스 디스커버리를 손쉽게 적용할 수 있다.
Spring Cloud Gateway는 애플리케이션 레벨 7(L7)에서 요청의 내용을 분석한 후 라우팅 및 필터링 로직을 수행하기 때문에, 고성능을 요하는 환경에서는 상대적으로 성능 저하가 발생하기 쉽다. 또한 별도의 게이트웨이 서버를 운영해야 하므로, 리소스 관리와 확장성에 대한 고려가 필요하다.
image source : https://medium.com/@niral22/spring-cloud-gateway-tutorial-5311ddd59816
Spring Cloud Gateway는 Spring 생태계와의 통합이 뛰어나고, 사용자 정의 로직을 자유롭게 작성할 수 있다는 점에서 매우 유연한 API Gateway이다. 하지만 L7 계층에서 동작하며, Spring Cloud에 종속된 구조적 제약과 서버 자원 관리 문제를 수반하므로, 개발 생산성 vs 운영 효율성 간의 균형을 잘 고려해야 한다.
1.3 스타트업을 위한 조언
스타트업이라면 Gateway의 기능이 꼭 필요하지 않더라도, 클라우드 서비스에서 제공하는 API Gateway를 적극 활용하여 서비스를 구성하는 것을 추천한다. 다음은 그 이유에 대한 설명이다.
1) 잦은 변경사항에 유연하게 대응할 수 있다
스타트업은 초기에 API 수정, 추가, 삭제가 자주 발생한다.
이때 API Gateway가 앞단에 위치해 있다면, 다음과 같은 이점이 있다.
-
엔드포인트 규칙을 Gateway에서 통제할 수 있으므로 버전 관리 및 정책 변경이 용이하다.
-
실제 서비스 코드 변경 없이도, 경로, 인증, 라우팅 조건을 Gateway 수준에서 처리할 수 있다.
2) 트래픽이 적을 경우 비용이 거의 발생하지 않는다
API Gateway는 사용량 기반 과금이 일반적이다.
초기에는 트래픽이 적기 때문에, 비용 부담이 크지 않으며, 고정 인프라를 구성할 필요도 없다.
3) 고가용성 및 로깅을 통해 운영 리스크를 줄일 수 있다
클라우드 기반 API Gateway는 기본적으로 고가용성(High Availability)을 지원한다.
이는 다음과 같은 운영 이점을 제공한다.
-
스타트업은 제한된 인력으로 웹 서버, 애플리케이션 서버, API Gateway 등을 동시에 운영해야 한다.
-
이러한 구성 요소 중 하나라도 장애가 발생하면, 고객 신뢰도 하락과 비용 손실로 이어질 수 있다.
API Gateway를 사용하면 다음과 같은 문제를 예방하거나 최소화할 수 있다.
-
API Gateway는 모든 요청의 입구 역할을 수행하므로, 중앙 집중식 로깅 포인트가 된다.
-
시스템 구성이나 운영 경험이 부족한 상황에서도 디버깅 및 원인 분석이 쉬워진다.
-
예기치 않은 오류가 발생했을 때, Gateway 로그를 통해 다음 사항을 빠르게 확인할 수 있다.
-
요청이 실제로 전달되었는가?
-
백엔드 서비스가 응답했는가?
-
응답이 성공인가 실패인가?
-
4) 클라이언트 개발자와의 커뮤니케이션 비용을 줄일 수 있다
프론트엔드 개발자 입장에서는 백엔드 API의 변경이 자주 발생하면, 다음과 같은 문제가 발생한다.
-
특정 API가 없어졌거나, 경로가 바뀌었거나, 응답 형식이 달라졌을 수 있다.
-
이로 인해 커뮤니케이션 비용이 증가하고, 개발 일정에도 영향을 준다.
하지만 API Gateway를 사용하면, 백엔드 변경이 있어도 Gateway에서 추상화하여 대응할 수 있다.
즉, 프론트엔드는 동일한 엔드포인트를 사용하고, 백엔드의 세부 구조나 변화에 대해 신경 쓸 필요가 없다.
결론
스타트업은 인력이 부족하고, 빠르게 제품을 개발하며, 변화가 잦은 특성을 갖는다.
이러한 환경에서 클라우드 기반 API Gateway는 다음과 같은 장점을 제공한다.
-
유연한 버전 관리와 정책 변경
-
저렴한 비용
-
고가용성과 중앙화된 로깅
-
개발자 간의 커뮤니케이션 간소화
서비스를 외부에 노출하고자 한다면, 초기부터 API Gateway를 적극 도입하여 구조화된 인프라를 구성하는 것이 바람직하다.
