API Gateway란?
사용자나 외부 시스템으로부터의 요청을 단일화하여 처리할 수 있도록 해주는 API Gateway Service에 대해 알아보자.
1. API Gateway Service
역할
API Gateway Service는 사용자가 설정한 라우팅 설정에 따라 각각의 엔드포인트로 클라이언트를 대신해 요청하고,
응답을 받으면 다시 클라이언트에게 전달해주는는 프록시 역할을 하게 된다.
시스템의 내부 구조는 숨기고, 외부 요청에 대해 적절한 형태로 가공해서 응답할 수 있다는 장점을 가지고 있다.
위 그림은 마이크로 소프트웨어 사에서 클라우드 아키텍처에 대해 설명한 그림이다.
마이크로 서비스가 세 가지 있다고 가정했을 때, 클라이언트 사이드에서 마이크로 서비스를 직접 호출하는 그림으로 볼 수 있다.
모바일 앱이든 웹앱이든 클라이언트 측에서 마이크로서비스의 주소를 이용해 직접 파라미터 전달을 하고 요청하는 형태이다.
새로운 마이크로 서비스가 추가되거나, 기존에 사용하던 마이크로 서비스의 주소가 변경되거나, 파라미터의 인자 값이 변경되었다고 가정해보자.
마이크로 서비스는 독립적으로 빌드가 되고 배포될 수 있으므로 마이크로 서비스 쪽에는 문제가 없다.
문제는 클라이언트 사이드에서 발생하는데,
클라이언트 사이드에서 마이크로 서비스의 엔드포인트를 직접 호출했을 경우에는, 클라이언트 사이드애 있는 어플리케이션도 같이 수정, 배포가 되어야한다.
따라서 단일 진입점을 가지고 있는 형태로 개발하는 방식이 필요하게 되었다.
서버단(백엔드단) 중간에 게이트웨이(진입로) 역할을 해줄 수 있는 API Gateway를 하나 두고,
각각의 마이크로 서비스로 요청되는 모든 정보에 대해 API Gateway가 일괄적으로 처리하게 된다.
모바일 앱도 상관 없고, SPA 웹앱도 상관 없고, 전통적인 웹앱도 상관없을 것이다.
클라이언트 사이드에 있는 어플리케이션은 마이크로 서비스를 직접 호출하지 않고 API Gateway만 상대하게 된다.
사용 시 이점
- 인증 및 권한 부여
- (마이크로) 서비스 검색 통합
- 응답 캐싱
- 정책, 회로 차단기 및 QoS 다시 시도
- 속도 제한
- 부하 분산 (로드밸런싱)
- 로깅, 추적, 상관 관계
- 헤더, 쿼리 문자열 및 청구 변환
- IP 허용 목록에 추가
2. Netflix Ribbon
API Gateway Service를 실제로 구현하기 전에, Netflix Ribbon에 대해 알아보자.
Spring Cloud에서의 MSA 간 통신
- RestTemplate
- Feign Client
RestTemplate
RestTemplate은 전통적으로 하나의 웹 어플리케이션에서 다른 어플리케이션을 사용하기 위해 사용되었던 api 이다.
사용법은 다음과 같다.
- 인스턴스를 만든다.
- 접속하고자하는 서버의 주소와 포트번호, 파라미터를 입력한다
- get 메서드 혹은 post 메서드 형식으로 호출한다. (ex.
getForObject)
Feign Client
Spring Cloud에서는 Feign Client라는 api를 이용해 다른 마이크로 서비스를 호출할 수 있다.
사용법은 다음과 같다.
- 특정 인터페이스를 만든다.
- 해당 인터페이스에서 호출하고 싶은 마이크로 서비스의 이름을 등록한다. (ex.
@FeignClient("stores")) - 마이크로 서비스의 이름을 통해 호출한다. (ex.
getStores())
만약, user 서비스에서 store 서비스를 페인 클라이언트를 등록하면,
store 서비스를 호출하고 싶을 때, 호출할 마이크로 서비스의 이름을 통해 호출할 수 있다. (ex.getStores())
Ribbon: 클라이언트 사이드에서 사용할 수 있는 로드밸런서
RestTemplate과 Feign Client의 문제는, 로드 밸런서를 어디에 구축할 것인가이다.
초창기의 스프링 클라우드에서는 로드 밸런서 역할을 하기 위해 Ribbon이라는 서비스를 제공했다.
넷플릭스 사의 로드 밸런싱 기술이 Ribbon이라는 서비스로 완성되었고, 이는 Spring Cloud 재단에 기부된 것이다.
- 마이크로 서비스 이름으로 클라이언트 안에서 호출
- Health Check: 서비스가 정상 작동 중인지 확인
예를 들어, 세 가지(UserService, OrderService, ProductService) 마이크로 서비스가 있다고 가정하자.
이것을 사용하는 클라이언트가 있을 때, 클라이언트가 직접적으로 마이크로 서비스를 호출하는 방식은 좋지 않다.
따라서 API Gateway를 중간에 놓아야 하는데, 이 작업을 별도의 서비스나 시스템을 구축하지 않고,
클라이언트 사이드 내부에 Ribbon이라는 서비스를 구축해서 사용했던 것이다.
따라서 클라이언트 프로그램 안에서 이동하고자하는 마이크로 서비스의 주소값을 직접 관리한다.
클라이언트 사이드에서 Ribbon을 사용할 때의 이점은,
외부에 있는 마이크로 서비스를 호출하기 위해 ip와 port 번호를 명시하는게 아니라, 마이크로 서비스의 이름만 가지고 호출할 수 있다는 것이다.
Spring Cloud Ribbon은 Spring Boot 2.4에서 Maintenance 상태
Ribbon이 비동기화 처리가 잘 되지 않기 때문에 최근에는 잘 사용하지 않는다.
(Maintenance 상태는 Spring Cloud 팀에서 해당 모듈에 더 이상 새로운 기능을 추가하지 않는다는 것을 의미한다.)
따라서 최신 버전에서는 Ribbon을 대신해 Spring Cloud Loadbalancer를 사용한다.
3. Netflix Zuul
FirstService와 SecondService 두 가지 마이크로 서비스를 구성한다.
그리고 클라이언트에서 이러한 마이크로 서비스를 호출함에 있어서 Netflix Zuul이라는 제품을 이용해 게이트웨이 테스트를 해볼 것이다.
클라이언트가 상대하는 것은 FirstService와 SecondService가 아닌, 게이트웨이(Netflix Zuul)이다.
클라이언트가 Netflix Zuul에 데이터를 요청하면, Netflix Zuul이 해당 요청을 FirstService와 SecondService에 전달한다.
Netflix Zuul의 역할
- Routing
- API Gateway
Spring Cloud Zuul은 Spring Boot 2.4에서 Maintenance 상태
따라서 최신 버전에서는 Zuul을 대신해 Spring Cloud Gateway를 사용한다.
💛 개인 공부 기록용 블로그입니다. 👻