API 게이트웨이
"API Gateway: The single entry point for all client requests."
— 마이크로서비스 패턴의 창시자 크리스 리처드슨(Chris Richardson)의 아키텍처 설계 명언 중 하나.
뒤쪽에 백만 개로 쪼개놓은 마이크로서비스의 온갖 오물 트래픽을 정면에서 묵묵히 받아내는 고독한 방패막이. 여기가 맛이 가면 프론트엔드는 404도 아니고 무조건 502/504 에러의 지옥을 맛보며 울부짖게 된다
1. 개요
API 게이트웨이는 마이크로서비스 아키텍처(MSA)의 핵심 컴포넌트로, 클라이언트와 내부 백엔드 서비스들 사이에서 단일 진입점(Single Entry Point) 역할을 수행하는 전방위 프록시(Proxy) 서버다. 클라이언트가 어떤 마이크로서비스가 어디서 돌고 있는지 일일이 알 필요 없이, 오직 이 게이트웨이만 바라보고 요청을 던지면 똑똑하게 알맞은 백엔드로 요청을 리다이렉트해 주는 고마운 존재다.
겉보기에는 단순한 로드 밸런서나 프록시처럼 보이지만, 라우팅뿐만 아니라 JWT 기반 인증/인가 검증, SSL 터미네이션(Termination), 속도 제한(Rate Limiting), 서킷 브레이커(Circuit Breaker) 역할까지 전담하며 현대 MSA 환경의 필수 수문장으로 군림하고 있다. 만약 이게 없다면 모바일 앱은 API 하나 호출하려고 각 마이크로서비스의 주소 백 개를 다 외우고 다녀야 하는 파국을 맞이하게 된다.(...)
2. 주요 핵심 기능 및 이점
2.1. 동적 라우팅 (Dynamic Routing)
클라이언트의 요청 경로(URL, Header 등)에 따라 적절한 백엔드 서비스로 전달한다. 서비스들의 인스턴스 주소가 수시로 바뀌더라도, 서비스 디스커버리와 연동하여 알아서 실시간 경로를 찾아가기 때문에 클라이언트는 알 바 아니다.
2.2. 통합 인증 및 인가 (Authentication & Authorization)
마이크로서비스마다 똑같은 인증 로직을 복사 붙여넣기 하는 중복 삽질을 방지해 준다. API 게이트웨이에서 유효한 JWT 토큰인지 먼저 검증한 뒤, 뒤쪽 서비스들에게는 사용자 신원 정보를 헤더에 얹어서 가볍게 패스해 주기만 하면 된다. 이를 통해 백엔드 개발자들의 일요일 저녁이 조금이나마 지켜진다.
2.3. 보안 및 SSL 터미네이션 (SSL Termination)
외부 인터넷과의 통신에서는 복잡한 복호화 비용이 드는 HTTPS(SSL/TLS)를 적용하고, 게이트웨이를 넘어선 내부망 안에서는 가벼운 HTTP로 통신하여 뒤쪽 마이크로서비스들의 연산 부담을 덜어주는 매우 실리적인 아키텍처 꼼수를 부린다.1
3. 치명적인 한계와 단일 장애점 (SPOF)
3.1. 단일 장애점: 성문이 무너지면 성 안은 끝장이다
API 게이트웨이의 최대 장점인 '단일 진입점'은 역설적으로 '단일 장애점 (Single Point of Failure)'이라는 최대의 치명상을 낳는다. 수많은 서비스가 분리되어 독립적으로 동작하는 완벽한 MSA를 구축해 뒀다 한들, 트래픽을 최초로 받아내는 API 게이트웨이 한 놈이 고꾸라지면 뒤쪽에 살려둔 천 개의 서버는 억울하게 손가락만 빨아야 한다.
따라서 기업들은 게이트웨이를 다중화하고 이중 삼중의 이중화 설정을 곁들여 절대 꺼지지 않는 불멸의 성문을 만들기 위해 안간힘을 쓴다. 그럼에도 블랙 프라이데이와 같은 폭풍 같은 트래픽 앞에서는 게이트웨이가 먼저 숨을 거두는 일이 비일비재하다.(...)
3.2. 레이턴시 병목 현상
모든 요청이 중간에 한 단계를 추가로 거치는 셈이므로, 무거운 게이트웨이를 구축하면 오히려 응답 속도가 전체적으로 느려지는 현상이 발생한다. 특히 불필요하게 복잡한 필터나 로깅 로직을 게이트웨이 내부에 덕지덕지 집어넣는 실수를 범하면, 시스템 전체가 거대한 병목이라는 늪에 빠지게 된다.2
4. 관련 밈 및 드립
4.1. Netflix Zuul의 명복을 빕니다
한때 Spring Cloud 생태계를 평정했던 넷플릭스의 API 게이트웨이 'Zuul 1'. 하지만 블로킹(Blocking) 방식의 비효율성과 넷플릭스의 자체 유지보수 중단 선언이 겹치면서, 수많은 개발자들이 밤을 새워가며 논블로킹 방식의 Spring Cloud Gateway나 고성능 Kong Gateway로 이사 가느라 피눈물을 흘렸다. 현재 Zuul을 아직도 메인으로 쓴다는 말을 면접에서 들으면, 경력직 개발자들은 은근히 퇴사를 고려할 수준이 된다.
5. 여담
- 인증 처리의 무법지대: 게이트웨이에서 토큰을 이미 까봤으니 내부 서비스들끼리는 아무런 인증 없이 통신하게 두는 경우가 많은데, 이를 노린 내부 침입자에게 뚫릴 경우 모든 마이크로서비스가 발가벗겨진 채 털리는 끔찍한 엔딩이 벌어질 수 있다.
- Kong의 은밀한 지배: 오픈소스계에서 가장 인기 있는 'Kong API Gateway'는 내부적으로 고성능 웹 서버인 Nginx와 Lua 스크립팅 엔진을 기막히게 버무려 만들었다. 그래서 겉은 킹콩이지만 속은 아주 예리한 엔진이 숨겨져 있다.
- 게이트웨이에서 비즈니스 짜지 마라: 초보 아키트들이 흔히 저지르는 실수가 게이트웨이 필터 내부에 복잡한 비즈니스 로직(예: DB 조회해서 조건 처리하기 등)을 넣는 것이다. 이는 게이트웨이를 또 하나의 거대한 레거시 똥덩어리로 만드는 직행열차다.