💡API Gateway란?
API Gateway는 클라이언트와 백엔드 서비스 컬렉션 사이에 위치하는 API 관리 툴이며, 모든 서버로의 요청을 단일 지점을 거쳐서 처리하도록 한다. 이를 통해 공통된 로직 처리나 인증 및 인가 처리, 라우팅 처리 등을 할 수 있다.
API 게이트웨이는 모든 애플리케이션 프로그래밍 인터페이스 즉, API 호출을 수락하고 호출 이행에 필요한 다양한 서비스를 집계하며 적절한 결과를 반환하는 리버스 프록시 역할을 한다.
리버스 프록시(역방향 프록시)란 웹 서버 앞에 위치하여 클라이언트 요청을 해당 웹 서버에 전달한다. 이는 일반적으로 보안, 성능, 안정성을 향상하기 위해 구현된다.
1. API Gateway의 역할
- 클라이언트 요청을 수신하여 적절한 백엔드 서비스로 전달하는 L7(애플리케이션 계층) 프록시 역할 수행한다
- 트래픽의 단일 진입점(single entry point) 으로 동작한다
- 인증, 속도 제한, 요청 변형, 로깅, 응답 조합 등 API 중심의 정책 제어 기능 내장
2. API Gateway를 사용하는 이유
- 단일 진입점(Single entry Point) 제공
클라이언트는 하나의 진입점을 통해 모든 마이크로서비스에 접근할 수 있어, 관리가 용이하다. - 마이크로서비스의 복잡성 감소
클라이언트가 각 마이크로서비스의 엔드포인트를 알 필요가 없으며, API 게이트웨이가 이를 추상화한다. - 중앙 집중식 관리
인증, 로깅, 모니터링 등 공통 기능을 중앙에서 관리할 수 있어 코드의 중복을 줄이고 유지보수를 용이하게 한다. - 유연한 확장성
새로운 마이크로서비스를 추가하거나 기존 서비스를 변경할 때, API 게이트웨이의 라우팅 규칙만 수정하면 되어, 클라이언트의 변경 없이 확장이 가능하다
문제 시나리오 예시
여러 개의 마이크로서비스가 분산되어 각각 다음과 같은 도메인으로 운영되고 있다고 가정:
- auth.example.com → 로그인/회원가입 처리
- user.example.com → 유저 정보 조회/수정
- payment.example.com → 결제 처리
이 경우 클라이언트는 다음과 같은 문제에 직면한다:
- API 엔드포인트 주소를 전부 알아야 함
- 서비스마다 인증 방식이 다를 수 있음 (ex. 어떤 서비스는 JWT, 어떤 서비스는 세션 기반)
- 트래픽 제어 불가 → 요청 폭주 시 각 API 서버가 개별적으로 대응해야 함
- 보안 정책 분산 → IP 제한, TLS 설정 등 중복 관리 필요
- 배포 및 버전 관리 어려움
결국 클라이언트는 각 API의 존재와 구조를 전부 알아야 하고, 요청마다 별도로 처리해야 한다. 서비스가 커질수록 유지보수 난이도는 기하급수적으로 증가한다.
▶️ API Gateway 도입 시
POST <https://api.example.com/users/signin>
GET <https://api.example.com/users/me>
POST <https://api.example.com/payments/pay>
- 클라이언트는 하나의 주소만 알면 된다.
- Gateway가 각 요청을 알맞은 서비스로 라우팅
- 클라이언트는 하나의 주소만 알면 된다.
- 실제 내부 주소는 Gateway 뒤에 숨김 (추상화)
3. API Gateway가 제공하는 핵심 기능
- 인증 / 인가 처리
- 라우팅
- 메디에이션
- 로깅 및 미터링
- 보안 정책 일원화
📌API 게이트웨이의 인증/인가
API 게이트웨이의 가장 기본적인 기능은 API에 대한 인증과 인가 관련 기능이다.
인증은 요청을 보내는 사용자의 신원을 확인하는 것 인가는 사용자가 이 요청에 대한 요구를 할 권한이 있는지 확인하는 과정이다.
위는 스트링 기반 토큰(ex: OAuth)을 사용할 경우, 위와 같은 구조로 인증/인가가 진행된다.
인증 시, API Gateway가 인증 서버에서 받아온 토큰을 토큰 저장소에 저장하고 클라이언트 전달 인가 시, 토큰 저장소에 저장되어 있는 토큰과 API호출 헤더의 토큰을 검증 후 리소스 서버에 전달
위는 클레임 기반 토큰(JWT)을 사용할 경우. 위와 같은 구조로 인증/인가가 진행된다.
인증 시, 인증 서버에서 받아온 토큰을 클라이언트에 전달. 인가 시, API호출 헤더의 토큰을 API Gateway에서 검증 후 리소스 서버에 전달
📌API 라우팅
API Gateway의 주요 기능 중 하나는 같은 API 요청이라도 서비스나 클라이언트 종류에 따라서 다른 엔드포인트로 라우팅을 해줘나 로드밸런싱 기능을 지원해주기도 한다.
백엔드 API 서버로의 로드 밸런싱
가장 기본적인 기능으로, 로드밸런서 기능이다.
API Gateway 뒷단에 여러 동일한 서버가 대기하고 있다면 API Gateway에서 로드밸런싱 기능을 지원해줄 수 있다.
단순하게 로드밸런싱을 라운드 로빈으로도 제공해 줄 수 있고, 원하는 트래픽에 따라 분산시킬 수도 있다. 무엇보다 API 서버가 장애가 났을 경우에 이를 알아채고 그쪽으로 트래픽을 전달하지 않을 수도 있다.
서비스 및 클라이언트 별 엔드포인트 제공
또 다른 유용한 기능으로는 같은 API 요청이라도 여러 개의 엔드포인트를 이용해 각 서비스마다 클라이언트마다 라우팅해 줄 수 있다는 점이다.
예를 들면 IOT 센서가 있고 이런 데이터를 수집하는 같은 API가 있다라고 생각해 보자.
- 선반 센서용 : /ship/sensors
- 비행기 센서용 : /airplane/sensors
- 차량 센서용 : /cars/sensors
이런 식으로 다양한 엔드포인트로 요청을 하지만 API Gateway에서는 같은 경로(센서 로그 수집 API)로 전달해줄 수 있다.
메세지 또는 헤더기반 라우팅
라우팅에서 유용한 기능중의 하나는 메시지 내용을 기반으로 하는 라우팅이다.
예를 들어 그림과같이 HTTP 헤더에 country code가 있을 경우, country code에 따라서 유럽에 있는 API를 호출하거나 또는 미국에 있는 API 서버를 호출할 수 있도록 Routing을 할 수 있다.
메시지 헤더를 파싱해서 메시지 헤더에 있는 내용을 기반으로 라우팅할 수도 있다. 다만 이런 오버헤드에 대한 고려를 하면 된다. 메시지 기반으로 라우팅할 땐 웬만하면 헤더에 라우팅 정보를 넣어서 전달하면 좋다. 메시지 바디까지 파싱하는 건 좀 부담스럽기 때문에.
공통 로직 처리
API Gateway는 특성상 모든 API 서버 앞쪽에 위치하기 때문에 모든 API 호출이 Gateway를 거치기 때문에 공통된 로직 처리가 필요하다면 Gateway에다가 넣으면 좋다. 이를 통해 각각의 서비스는 자신의 비즈니스 로직에 집중하면 되므로 API 로깅이나 인증같은 기능은 공통 로직으로 포함된다.
📌메디에이션 (Mediation)
메디에이션이란, 한글로 “중재”또는 “조정” 이라는 의미를 갖는데, API서버에서 제공되는 API가 클라이언트가 원하는 API 형태와 다를때, API 게이트웨이가 이를 변경해주는 기능을 이야기 한다.
메시지 포맷 변환
메시지 포맷 변환 기능이란 클라이언트에서 들어온 요청을 API 서버로 보낼 때 데이터를 변환해서 보내주거나 API 서버에서 응답하는 데이터를 클라이언트가 원하는 데이터로 변경해주는 기능을 말한다.
예를 들면 사용자의 연봉을 원하는 API 요청이 들어왔다고 하자. 연봉 정보만 주는 API 서버는 없지만 사용자의 정보를 리턴해주는 API 가 있다고 했을 때 이 데이터를 서버에서 응답으로 가지고 와서 API Gateway에서 클라이언트가 필요로 하는 데이터만 추려서 전달해줄 수 있다.
프로토콜 변환
다양한 서비스나 클라이언트를 지원하게 되면 다양한 통신 프로토콜을 지원해야 하는 경우가 있다.
예를들면 웹이서는 Json이나 HTTP를 이용한 REST 기반의 통신을 많이 쓰지만 배나 비행기에서는 REST도 무겁기 때문에 바이너리 기반의 경량 프로토콜을 사용하게 된다. 이렇게 다양한 타입의 프로토콜을 지원하기 위해서 프로토콜마다 새로운 서비스를 구현하는 게 아니라 API Gateway에서 프로토콜 변환을 이용해 서비스를 호출할 수 있도록 하면 된다.
실제로 유용한 기능인데 내부로는 REST 통신이 아니라 페이스북의 Thrift나 구글의 Protocol Buffer로 구현을 해서 성능을 올리고 외부로는 REST를 이용해서 범용성을 올리는 사례가 있다.
메시지 호출 패턴 변환
메시지 호출 패턴 변환이란 동기 비동기 호출같은 통신을 변경시킬 수 있다. API 클라이언트는 동기 호출을 했지만 API Gateway에서는 메시지 큐 서비스를 이용해 비동기 통신을 이용하여 요청을 처리해주고 응답을 줄 수 있다.
어그리게이션 (Aggregation)
API Gateway에서는 여러 개의 API를 묶어서 하나의 API처럼 처리하게 보이는 동작을 만들 수 있다.
이렇게 만들면 API Gateway에 부하가 집중되므로 조심해야 한다. 그리고 로깅과 디버깅이 어렵다는 단점이 있다.
📌로깅 및 미터링
API Gateway의 비기능적인 요건으로 중요한 기능이 로깅과 미터링이다.
API 호출 로깅
API Gateway의 주요 기능인 공통 로직 처리 기능에서 봤듯이 API Gateway는 공통적으로 처리하는 기능에 유용하고 이에는 로깅이 있다. 모든 API 시작 지점이 Gateway부터 시작하므로 이부터 시작해서 서비스간 호출 패턴을 파악해서 사용자 패턴을 파악할 수 있다. 이는 빅데이터와 연계해서 유용하다.
또는 문제가 발생했을 때 문제를 추적하기 위한 용도로 많이 사용되기도 한다.
API 미터링 & 차징
API 미터링과 차징은 유료 API 서비스를 위한 기능으로 미터링은 API 호출 횟수, 클라이언트 IP, API 종류, In/Out 용량 등을 측정할 수 있는 지표들을 기록하는 서비스이다.
QoS 조정 (Quality of service)
QoS 조정 기능이란 API 서비스를 클라이언트 대상에 따라서 서비스 레벨을 조정하는 기능이다.
유료 서비스가 있는 API 서비스라고 가정했을 때, 무료 사용자의 경우 1일 1000건으로 호출횟수를 제한한다거나, 전송 용량이나, 네트워크 대역폭을 유료/무료 사용자에 따라 다르게 적용하는 것과 같은 기능을 QoS 기능이라고 한다.
유료 서비스인 경우만 아니라, 플랫폼 차원에서 다양한 클라이언트나 다양한 서비스로 API를 제공하는 경우, 각 클라이언트나 서비스에 따라서 이 QoS를 조정하는 기능은 유용하게 사용될 수 있다. 특정 서비스나 클라이언트가 폭주하여 API를 과도하게 사용하여 다른 서비스들이 API를 사용할 수 없게 한다던가 그런 문제를 미연에 예방할 수 있다.
참고한 블로그
https://wildeveloperetrain.tistory.com/205
'Infra&Cloud > Infra' 카테고리의 다른 글
| 3계층 구조 ( 3-tier Architecture ) 란? (0) | 2026.01.26 |
|---|---|
| API Gateway Solution ( Feat. Kong, Apache, Spring Cloud Gateway) (0) | 2025.10.21 |
