마이크로서비스패턴[8] — 8장
8장 외부 API 패턴
1장 모놀리식 지옥에서 벗어나라
2장 분해 전략
3장 프로세스 간 통신
4장 트랜잭션 관리: 사가
5장 비즈니스 로직 설계
6장 비즈니스 로직 개발: 이벤트 소싱
7장 마이크로서비스 쿼리 구현
8장 외부 API 패턴
9장 마이크로서비스 테스트 1부
10장 마이크로서비스 테스트 2부
11장 프로덕션 레디 서비스 개발
12장 마이크로서비스 배포
13장 마이크로서비스로 리팩터링
어플리케이션의 외부 API는 클라이언트의 종류가 다양한 만큼 설계하기 어렵다. 이번 장에서는 마이크로서비스환경에서 외부에 제공할 API를 어떻게 설계하는지, 그리고 API Gateway에 대해 설계/구현하는 방법에 대해 얘기한다.
8. 외부 API 패턴
8.1. 외부 API 설계 이슈
클라이언트가 직접 서비스를 호출하도록 API를 설계할 수도 있지만, 아래와 같은 단점이 있어서 마이크로서비스 환경에서는 거의 사용하지 않는다.
- API가 잘게 나누어져있어 여러번 요청을 해야하는만큼 효율이 떨어지고 UX가 나빠진다.
- 클라이언트가 서비스 및 API를 알아야 하는 구조라서 캡슐화가 되지 않고, 추후 아키텍처와 API를 변경하기 어렵다.
- 클라이언트가 사용하기에 불편하거나 실용적이지 못한 IPC를 서비스에서 사용중인 경우가 있다.
8.2. API 게이트웨이 패턴
API 게이트웨이는 방화벽 외부의 클라이언트가 어플리케이션에 API요청을 하는 단일 창구 역할을 하는 서비스이다. API 게이트웨이는 말 그대로 서비스 로 들어오는 요청의 관문역할을 하지만, 뿐만 아니라 서비스에 필요한 다양한 기능들을 제공한다.
- 인증
- 인가
- 사용량 제한
- 캐싱
- 지표 수집
- 요청 로깅
API 게이트웨이 또한 모놀리식과 마이크로서비스에 적합한 BFF 패턴으로 나눌 수 있다.
8.2.1. 모놀리식 API 게이트웨이 패턴
위 그림에서 별개의 클라이언트들은 하나의 Public API를 통해서 서비스를 호출하고 있다. 위의 경우 여러 사람들이 동일한 코드베이스에 접근하게 되고, API 게이트웨이를 관리하는 팀은 운영만 맡게 되므로 책임소재가 흐릿해지는 문제점이 발생한다.
그리고 ‘if you build it,you own it’ (빌드한 사람이 주인이다.) 라는 마이크로서비스 아키텍처의 철학과 맞지 않게 된다.
이를 개선할 수 있는 패턴이 아래의 BFF 패턴이다.
8.2.2. Backends for Frontend (프론트엔드를 위한 백엔드) 패턴
BFF 패턴은 각 API 모듈을 하나의 클라이언트 팀이 개발/운영하는 Stand Alone API 게이트웨이가 되는 구조이다.
이론적으로는 API 게이트웨이마다 다른 기술을 사용하여 개발할 수 있지만, 공통 기능 코드가 중복될 우려가 있기에 모든 API 게이트웨이에 동일한 기술 스택을 적용하는 것 좋다.
8.2.3. API 게이트웨이의 장단점
- 장점
클라이언트가 특정 서비스를 호출할 필요 없이 무조건 API 게이트웨이를 호출하면 된다. 클라이언트마다 최적의 API가 제공되므로, 외부서비스와의 트랜잭션 호출수가 줄어든다. - 단점
관리할 범위가 많아진다. 하지만 BFF 패턴을 팀별로 분리하여 독립적으로 개발/포할 수 있게되어 합리적이다.
8.2.4. API 게이트웨이 설계 이슈
- 성능과 확장성
모든 외부 요청은 API 게이트웨이를 거쳐야만 한다. API 게이트웨이가 동기/비동기를 지원할 것인지, 그에 따른 성능과 확장성 관리는 어떻게 할 것인지 고민해야 한다. - 리엑티브 프로그래밍 추상체를 이용한 관리 가능한 코드 작성
링크참조 - 부분 실패 처리
인스턴스 실패시 다른 인스턴스로 라우팅을 할 수 있도록 고민할 필요가 있다. - 선량한 시민 되기
API 게이트웨이는 자신이 호출하는 서비스 인스턴스 위치를 파악할 수 있어야 한다. 서비스가 복잡해짐에도 불구하고 API 게이트웨이의 목적에 맞게 사용되어야 한다는 것이다.
8.3. API 게이트웨이 구현
API 게이트웨이 구현에 필요한 기능은 4가지이다.
- 요청 라우팅
- 클라언트의 요청을 HTTP 메서드, 경로에 따라 지정된 서비스로 라우팅한다. - API 조합
- REST의 엔트포인트를 담당하고, 요청 핸들러는 여러 서비스를 호출한 결과를 조합한다. - 엣지 기능
- 대표적인 기능이 인증이다. - 프로토콜 변환
- 클라이언트에 친화적인 프로토콜을 서비스에 친화적인 프로토콜로 변환한다. ex) REST -> GraphGL
API 게이트웨이를 구현하는 방법은 2가지이다.
- 기성 제품/서비스 사용
- 직접 구현
8.3.1. 기성 API 게이트웨이 사용
- AWS API gateway
- kong gategay
- traefik gateway
8.3.2. 직접 구현
- Netflix Zuul
- Spring Cloud Gateway
- GraphQL기반 API gateway 구현
