MSA로 배포한다면 서비스마다 API를 갖고 있어 어떤 종류의 API를 클라이언트에 표출해야 할지 결정해야한다.
8.1 외부 API 설계 이슈
클라이언트가 서비스를 직접 호출하도록 API를 설계하면 다음과 같은 이슈가 있다.
모바일 클라이언트
- 서비스 API 가 잘게 나뉘어져 있어 클라이언트가 필요한 데이터를 가져오려면 여러 번 요청을 해야한다
- 클라이언트가 서비스 및 API를 알아야 하는 구조, 아키텍처 & API 바꾸기 어렵다
- 클라이언트에 비친화적인 IPC를 사용 중인 클라이언트도 있다 -> gRPC, AMQP 같은 프로토콜을 쓰는 서비스가 많은데 내부에선 잘 동작하나 모바일이 소비하기 어려운 경우가 많다 ㅇㅁㅇ
다른 종류의 클라이언트
모바일이 아닌 다른 클라리언트에도 이슈가 존재한다.
- 웹 애플리케이션: 백 변경하면 쉽게 수정 가능, 웹 애플리케이션이 직접 백엔드 서비스에 접근하는 건 얼마든지 가능
- 브라우저 기반의 JS 애플리케이션: 서비스 API를 효율적으로 조합하기 어려움
- 서드파티 애플리케이션: 외부 개발자용이라 업데이트가 힘들 수 있음, 직접 서비스 표출보단 별도로 퍼블릭 API를 따로 가져가는게 낫다
8.2 API 게이트웨이 패턴
서비스에 직접 호출하면 문제 많아서 API 게이트웨이를 사용하는게 훨씬 낫다.
API 게이트웨이 패턴 개요
Facade 패턴과 유사
요청 라우팅
nginx처럼 리버스 프록시와 같음, 요청이 들어오면 라우팅 맵을 찾아보고 어느 서비스로 요청을 보낼지 결정
API 조합
요청 한 번으로 필요한 데이터 조회가능하도록 대단위 API 제공
프로토콜 변환
외부 REST API <-> 내부 gRPC API 변환
API 게이트웨이는 클라마다 적합한 API 제공
모바일/웹에 맞게 적합한 API 제공하도록 함
엣지 기능 구현
인증/인가, 사용량 제한, 캐싱, 지표 수집, 요청 로깅 등 엣지 기능도 가능
전용 엣지 서비스를 사용할 수 있지만, 인증 같은 엣지 기능은 API 게이트웨이에 구현하는게 간편하고 좋다.
API 게이트웨이 아키텍처
API 계층 + 공통 계층
BFF
각 클라이언트 종류마다 API 게이트웨이 따로 구현
API 모듈이 서로 격리되어 신뢰성이 향상된다라는 장점 존재
API 게이트웨이의 장단점
장점
- 애플리케이션 내부 구조 캡슐화
- 클라이언트 - 애플리케이션 간 왕복 횟수 줄고 클라 코드 간단
단점
- 개발, 배포, 관리 해야하는 고가용 컴포넌트 하나 더 늘어남, API 게이트웨이가 개발 병목 지점이 될 우려 존재
API 게이트웨이 설계 이슈
-
성능과 확장성
- 동기: 스레드 하나씩 배정되므로 동시 접속 다능 개수 제한
- 비동기: 다중스레드 오버헤드가 없기에 확장성 좋음, 실제로 적용했을 때 접속 비용은 감소했으나 CPU 로직은 개선되지 않았음
-
리액티브 프로그래밍 추상체를 이용해 관리 가능한 코드 작성
- 서비스 순차호출하면 결국 기다려야 함 -> 콜백 방식 사용
-
부분 실패 처리
- 실패한 요청, 지연 시간 긴 요청 잘 처리해야함, 회로 차단기 패턴 이용
-
애플리케이션 아키텍처에서 선량한 시민 되기
- 서비스 디스커버리 패턴 사용해서 네트워크 위치 파악 가능, observability 패턴 이용해서 모니터링
💻 ☕️ 🏝 🍑 🍹 🏊♀️