MSA에서의 외부 API 이슈
MSA에서 외부 API를 제공한다고 할 때에는 다음과 같은 고려사항이 발생 할 것입니다.
- 클라이언트 소스에 따라 요구되는 데이터 종류가 다를 수 있다
- 서비스 접근 경로가 다양하다
- 성능이 낮은 네트워크를 통해 접근 할 가능성이 있다
클라이언트 측에서 서비스를 직접 호출 하도록 API를 설계 할 수도 있겠지만, 다음과 같은 이슈사항들이 발견 될 것입니다.
- 서비스 API가 분리되어있어 원하는 데이터를 가져오기위해 여러번 요청해야할 가능성이 있다
- 클라이언트가 모든 서비스들에 대해서 알고 있어야한다
- 사용하기 불편한 통신을 클라이언트에서 사용 하게 될 수도 있다
- 네트워크 지연시간이 오래걸릴 것이다
- 기능 캡슐화가 되지 않는다
API 게이트웨이
클라이언트에서 다양한 서비스들에 직접접근하게되면 여러가지 문제가 있기에, MSA에서는 API 게이트웨이 패턴을 적용하여 사용합니다.
API 게이트웨이는 다음과같은 역할을 할 수 있습니다.
- 내부 애플리케이션 아키텍쳐 캡슐화
- 클라이언트 요청 라우팅
- API 조합
- 프로토콜 변환
- 클라이언트 친화 API 제공
- 인증, 모니터링, 사용량 제한, 캐싱 등의 역할 제공
또한 API 게이트웨이는 다음과같은 아키텍처를 통해 클라이언트 소스따라 친화적인 API 데이터를 제공 해 줄 수 있습니다.
API 게이트웨이 고려할점
API 게이트웨이의 도입은 서비스의 품질 향상에는 분명히 좋겠지만, 당연하게도 개발, 배포, 관리를 해야하는 고가용의 컴포넌트가 하나 더 추가 되었다는점을 잊으면 안됩니다.
API 게이트웨이를 구축 할 때에는 다음과같은 문제를 검토 해야합니다.
- 성능
- 확장성
- 에러처리
- 목적성
모든 외부 요청은 API 게이트웨이가 사용되기 때문에 성능이슈가 있을경우 모든 서비스에 영향을 주는 병목 포인트가 될 수 있습니다. 따라서 언제든 성능을 빠르게 향상 시킬 수 있도록 확장성이 고려 되어야 합니다.
또한 클라이언트의 요청을 직접 받기때문에 적절한 에러처리 및 전달을 신경 써 줘야하고, 클라이언트 요청의 목적에 맞는 데이터를 적절히 라우팅 혹은 조합해서 전달 해 줄 수 있어야 합니다.
API 게이트웨이 구현
API 게이트웨이를 구현하는 방법은 여러가지가 있습니다.
- 게이트웨이 제품 활용
- AWS Gateway
- AWS ALB
- Kong
- Traefik
- 게이트웨이 직접 구현
- Netflix zuul
- Spring cloud gateway
Netflix zuul을 활용하여 API Gateway를 직접 구현한 예제 포스팅을 공유드립니다.
(https://taes-k.github.io/2019/06/16/spring-msa-3/)
Netflix Zuul 라이브러리를 사용하면 사전 필터, 라우팅 필터, 사후 필터, 에러 필터등 여러 필터를 제공하여 서비스들을 커스터마이징하여 손쉽게 API Gateway를 구현 할 수 있습니다.