API Gateway 개념
1. 나오게 된 배경
고객 서비스를 위한 다양한 클라이언트가 나오기 시작했고, 서비스를 위해 필요한 다양한 정보들을 요구하기 시작했다. 이에 MSA가 유행하기 시작한다. 여기서 MSA란 마이크로하게 나눈 독립적인 서비스를 의미한다.
하지만 문제점이 발생한다. 클라이언트와 MSA간의 강한 결합이 있고, 너무 많은 통신을 요구하게 된다. 개별 서비스의 엣지 기능 제공 및 구현(보안, 로깅, 모니터링, 캐싱 등)이 어려워졌다. 무엇보다 결합이 크면 변경이 어렵기에 새로운 무언가가 필요했다.
이를 해결하기 위해 API Gateway 패턴이 등장한다.
2. API Gateway란?
크게 두 가지 기능을 제공한다. 첫 번째는 단일접점으로 마이크로 서비스를 모아서 단일접점을 제공한다. 두 번째는 캡슐화로 클라이언트 입장에서 마이크로 서비스 내부가 어떻게 된지 알 필요가 없다. 자연스럽게 캡슐화가 이뤄줘서 의존성이 끊어진다.
장점으로는 마이크로 서비스를 묶어서 단일 진입점을 제공한다는 점, 한 곳에서 보안과 권한을 제어할 수 있고, API에 대한 로깅과 모니터링. 헤더, 쿼리, 요청 변환. 부하 분산 및 캐싱 등. 많은 기능들을 제공해 준다.
단점으로는 초과 네트워크 호출이 늘어나 응답 속도가 저하되고, 고가용성 장비의 필요, 그리고 단일 장애 포인트(SPoF)가 일어날 수 있다. 이에 게이트웨이가 고장나면 서비스가 다 망하는 참사가 일어날 수 있다. 그래서 고가용성 장비가 필요하고, 초과 네트워크 호출은 캐싱을 이용해서 이런 응답속도를 보완할 수 있다.
API Gateway에서 SPoF를 만들지 않는 게 중요하다. 그래서 고가용성이 제일 중요하고, 문제 발생 시 모니터링, 로깅은 필수.
3. 구현 방법
클라우드 사가 제공하는 API GateWay를 사용하거나, Spring이 제공하는 Spring Cloud Gateway를 사용하면 된다.
이 포스팅에서는 Spring Cloud Gateway에 관해 자세히 설명하겠다.
어떤 요청에도 매칭을 통한 라우팅을 제공하고, 경로에 따른 조건자와 필터를 설정 및 쉬운 조건 필터 작성이 가능하다. 또한 서킷브레이커를 통합 제공하고, 요청과 응답을 변경하는 등 많은 기능을 제공한다.
3.1. 동작 방식
- Gateway Handler: 요청과 경로의 매칭 처리
- Gateway Web Handler: 요청을 microservice에 전달하는 필터를 적용하는 역할
- Before 필터
- After 필터
- Route: 조건 만족 시 설정 경로로 라우팅 및 고유 ID, 목적지 URI, Predicate Filter로 구성된 요소
- Predicate: 요청이 조건에 충족하는지 테스트
- Filter: 하위 마이크로 서비스로 요청과 응답을 보낼 때 변경하는 기능
하지만 이 패턴에도 문제점이 있다.
SPoF, 병목, 책임 소재 등. 장애가 나면 모든 서비스가 중단한다.
3.2. BFF(Backend For Frontend) 패턴
이를 개선한 패턴이 BFF이다.
각 클라이언트별 API Gateway를 만든 패턴이다. 이로 인해 독립성이 높아져서 확장, 변경, 배포가 용이해졌다. 또한 신뢰성 향상 및 SPoF제거 등의 이점을 얻는다.
4. 결론
Gateway를 사용할 때 유용한 팁은 중앙 API 문서 저장은 필수이고, 고가용성을 확보해야 한다. 이를 위해 Swageer, rest docs 같은 API 문서들을 활용하고, 게이트웨이가 쉽게 확장할 수 있게 로깅, 모니터링 등이 필수이다.
출처: FastCampus 대용량 데이터 & 트래픽 처리