[마이크로서비스패턴] 8장 외부 API 패턴
8장. 외부 API 패턴
8장 핵심내용
- API 게이트웨이 패턴 & BFF 패턴
- 리액티브 프로그래밍 응용 API 조합
- GraphQL 활용 API 게이트웨이 구현
1. 외부 API 설계 이슈
클라이언트가 직접 API 호출 시 단점
- 효율성 낮으며, UX 부정적 영향 : 클라이언트가 여러 번 요청하기 때문
- 캡슐화 X : 백엔드의 영향을 받는 프론트 엔드
- 클라이언트 비친화적 IPC : gRPC, 메시징 프로토콜 등
2. API 게이트웨이 패턴
API 게이트웨이 마이크로서비스 애플리케이션에 외부 API 클라이언트의 진입점에 해당하는 서비스 구현 방화벽 외부 클라이언트가 애플리케이션에 API 요청을 하는 단일 창구 역할 서비스
API 게이트웨이는 진입점을 제공하면서 요청 라우팅, API 조합, 프로토콜 변환의 주요 기능과 더불어 인증, 모니터링, 사용량 제한 등의 부수적인 기능도 포함.
2.1 API 게이트웨이
요청 라우팅
- 라우팅 맵을 찾아보고 어느 서비스로 요청 보낼지 결정
- 라우팅 맵? HTTP 메서드 & HTTP URL 매핑
- nginx와 같은 리버스 프록시와 동일
API 조합
- 여러 서비스의 API를 호출하여 데이터 조합
프로토콜 변환
- 외부 REST API 호출 <-> 내부 gRPC API 간의 변환 기능 제공
클라이언트별 API 제공
- 모바일, 앱, 웹 등 API 구분 제공 가능
엣지 기능
- 인증(authentication) : 요청 클라이언트 신원 확인
- 인가(authorization) : 특정 작업 수행 허가 클라이언트 확인
- 사용량 제한 : 클라이언트 초당 요청 개수 제한
- 캐싱 : 응답 캐시
- 지표 수집 : 과금 분석용 API 사용 지표 수집 등
- 요청 로깅
엣지 기능 구현 세 지점 1. 백엔드 서비스, 2. API 게이트웨이 upstream, 3. 전용 엣지 서비스
전용 엣지 서비스를 구현할 경우 API 라우팅/조합 기능에 집중하는 API 게이트웨이와 엣지 기능에 집중하는 엣지 서비스로 관심 분리 가능.
다만, 네트워크 홉이 늘어난다는 단점.
API 게이트웨이 아키텍처
API 계층과 공통 계층으로 구성.
API 계층 : 독립적인 하나 이상의 API 모듈. 모바일 API, 브라우저 API, 퍼블릭 API 와 같이 구성 가능.
- API 모듈 작업 방식 2
- 서비스 API 직접 매핑 : 각각의 서비스 API로 요청. 라우팅 규칙 기술 구성 파일 읽어 라우팅.
- API 조합 : 직접 구현
공통 계층 : 엣지 기능 등 공통 기능 구현 계층
API 게이트웨이 장단점
장점
- 애플리케이션 내부 구조 캡슐화
- 클라이언트-서버 간의 통신 감소
- 클라이언트 간결화
단점
- 또 다른 관리 지점 (개발, 배포, 운영 등)
- 개발 병목 지점 : 최대한 가볍게
BFF 패턴
각 클라이언트 종류 마다 API 게이트웨이 따로 구현
API 계층에서의 모호한 책임을 구분하기 위해 나온 패턴. 각 API 모듈에 대해 책임을 나누는 방식.
BFF 장점
- 신뢰성 향상 : 서로 독립적인 API 게이트웨이
- observability : 서로 다른 프로세스로 처리되는 API 모듈
- 독립적인 확장성
- 서버 올라가는 속도 개선
2.2. API 게이트웨이 설계 이슈
- 성능과 확장
- 리액티브 프로그래밍 추상체 이용 관리 가능 코드 작성
- 부분 실패 처리
- 애플리케이션 아키텍처 해치지 않기
성능과 확장성
- API 게이트웨이는 동기, 비동기 I/O 사용에 영향을 받음
- 동기 I/O
- 전용 스레드로 각 네트워크 연결을 처리
- os 쓰레드는 과도한 작업을 쓰레드의 제한 존재.
- 비동기 I/O
- 싱글 이벤트 루프 스레드가 I/O 요청을 각 이벤트 핸들러에 보냄.
- JVM 기반 Netty, Vertx, Spring Reactor, JBoss Undertow. 비 JVM rlqks Node.js
- 동기 I/O보다 확장성이 좋음. 그러나 콜백 기반 프로그래밍 모델은 복잡하다는 단점이 있음. 코드 작성, 이해, 디버깅 어려움 존재.
넷플리스는 동기 I/O 방식을 NIO 방식으로 전환
- I/O 중심 로직(요청 라우팅) : 25% 처리량 증가. CPU 사용량 25% 감소
- CPI 중심 로직(복호화, 압축) : 별 다른 개선 없었음
리액티브 프로그래밍 추상체
연속적으로 API 호출의 단점 : 각 API 응답 시간의 총합이 서버 응답 시간.
비동기로 호출하는 것이 응답 시간을 줄여줌.
비동기 콜백 방식은 콜백 지옥에 빠지게 만듦.
선언형으로 작성하는 것이 좋음.
리액티브 선언형 스타일 작성 가능 JVM 추상체
- Java 8
CompletableFutures - Reator
Monos - RxJava
Observables - Sacla
Futures
Node.js 는 promise, RxJS.
부분 실패 처리
실패 요청, 너무 오래 걸리는 요청으로 API 게이트웨이가 영향을 받을 수 있음.
리소스를 계속 소모 + 응답 불가 상태.
서킷 브레이커 적용 등 대책 필요.
애플리케이션 구조 해치지 않기
다른 서비스처럼 아키텍처에 맞게 API 게이트웨이 적용.
3. API 게이트웨이 구현
API 게이트웨이 구현 방법 2가지
- 기성 API 게이트웨이 제품/서비스 사용
- API 게이트웨이 프레임워크 또는 웹 프레임워크를 기반으로 API 게이트웨이 직접 개발
3.1 기성 API 게이트웨이 제품/서비스 활용
- AWS API GATEWAY
- 단점 : API 조합 불가
- AWS APPLICATION LOAD BALANCER
- 기능 제한적 : HTTP 메서드 기반 라우팅, API 조합, 인증 로직 X
- 기타 API GATEWAY 제품
- Kong
- Nginx HTTP 서버 기반
- Traefik
- Go 언어
- 두 제품 모두 API 조합 지원 X
- Kong
