API 게이트웨이
IT 위키
- API Gateway
- 클라이언트와 여러 백엔드 서비스 사이에 놓여 모든 API 호출의 단일 진입점 역할을 하는 서버
마이크로서비스 구조에서 사실상 필수 구성요소다.
- 서비스가 수십 개로 쪼개지면 클라이언트가 어느 서비스가 어디 있는지 다 알아야 한다
- 인증·로깅·속도 제한 같은 공통 관심사가 모든 서비스에 중복 구현된다
- 화면 하나를 그리는 데 여러 서비스를 호출해야 해서 네트워크 왕복이 많아진다
- 내부 서비스 주소와 구조가 외부에 그대로 드러난다
- 서비스별로 프로토콜이 달라 클라이언트가 복잡해진다
게이트웨이는 이 문제들을 한 곳으로 모은다.
| 구분 | 기능 |
|---|---|
| 라우팅 | 경로·헤더·버전에 따라 알맞은 백엔드로 요청을 넘긴다. 서비스 디스커버리 연동 |
| 인증·인가 | OAuth / JWT 토큰 검증, API 키 관리. 백엔드는 인증을 신경 쓰지 않아도 된다 |
| 속도 제한 | Rate Limiting, 쿼터, 스로틀링으로 남용과 과부하를 막는다 |
| 프로토콜 변환 | REST ↔ gRPC ↔ SOAP, HTTP/2 종단 |
| 요청 집계(Aggregation) | 여러 서비스 호출을 한 번의 응답으로 합쳐 준다 |
| 부하 분산·장애 대응 | 로드밸런싱, 재시도, 서킷 브레이커, 타임아웃 |
| 캐싱 | 반복 조회 응답을 저장해 백엔드 부하를 줄인다 |
| 보안 | TLS 종단, WAF 연계, IP 제어, 페이로드 검증 |
| 관측 | 로깅, 메트릭, 분산 추적 헤더 주입 |
| 변환 | 요청·응답 헤더와 본문 변환, 버전 호환 처리 |
- 단일 장애점(SPOF) — 게이트웨이가 죽으면 전부 죽는다. 이중화와 오토스케일이 필수다
- 지연 추가 — 홉이 하나 늘어난다. 가벼운 처리만 두고 무거운 로직은 넣지 않는다
- 비즈니스 로직을 넣지 않는다. 넣기 시작하면 ESB 처럼 비대해져 배포 병목이 된다
- 팀별로 게이트웨이 설정이 충돌하지 않도록 설정의 형상관리가 필요하다
- 클라이언트 종류가 다양하면 BFF(Backend For Frontend) 패턴으로 게이트웨이를 나눈다
- 서비스 간 내부 통신은 게이트웨이가 아니라 서비스 메시로 처리하는 것이 보통이다
- 오픈소스 : Kong, Spring Cloud Gateway, APISIX, Tyk, Zuul
- 클라우드 : AWS API Gateway, Azure API Management, GCP Apigee
- 국내 공공 : 공공데이터포털의 API 관리 체계
