[마이크로 서비스 패턴] 외부 API 패턴

본 포스팅은 마이크로서비스 패턴의 일부 내용을 정리한 내용입니다.

MSA에서는 서비스마다 API를 갖고 있기 때문에 모놀리식에서는 하나의 API가 MSA에서는 여러 API를 조합해야 할 수 있다. 이를 클라이언트에서 조합했을 때 어떤 문제점들이 있고 해결방법에는 어떤 것들이 있는지 알아보자.

외부 API 설계 이슈

클라이언트에서 직접 조합하여 호출한다면?

• 같은 API라도 클라이언트마다 필요한 데이터가 다르다.
• 서비스 API가 잘게 나뉘어져 있어서 클라이언트가 여러 번 요청을 해야 하고, 대부분 외부망을 통해 접근함으로 네트워크 지연시간이 길어진다.
• 모바일 환경에서는 네트워크 요청 횟수가 늘어날수록 전력 소모도가 커지므로 배터리 소모량이 크다.
• 클라이언트가 API를 알아야 하는 구조라서 캡슐화가 되지 않아 강한 결합을 가지게 된다.
• 클라이언트가 사용하기 실용적이 못한 프로토콜(IPC 등) 등을 서비스에서 사용하고 있을 수 있다.

API 게이트웨이 패턴 개요

• API 게이트웨이는 요청 라우팅, API 조합, 프로토콜 변환등을 관장한다.
• 외부 클라이언트는 API 게이트웨이로 향하고 API 게이트웨이가 적절한 서비스로 요청을 보낸다.
• BFF(Backend for Frontend)
  - 클라이언트마다 API 게이트웨이를 따로 둔다. 이 게이트웨이는 하나의 클라이언트 팀이 개발/운영하는 스탠드 얼론 게이트웨이가 되는 구조이다.
  • 공통 기능은 API 게이트웨이 팀이 개발한 공유 라이브러리를 사용한다.
  • API 모듈이 서로 격리되어 신뢰성이 향상된다.

API 게이트웨이의 장단점

• 가장 큰 장점은 애플리케이션의 내부 구조를 캡슐화하는 것이다.
• 개발, 배포, 관리를 해야하는 고가용 컴포넌트가 하나 더 늘어나는 부담이 있다.
• 성능과 확장성
  • 동기 I/O를 사용할 것인가, 비동기 I/O를 사용할 것인가는 성능 및 확장성에 가장 큰 영향을 미치는 설계 결정이다.
  • 동기 I/O 모델은 네트워크 접속마다 스레드를 하나씩 배정한다. 또한 프로그래밍 모델이 간단하고 잘 동작하는 편이다. 그러나 다소 무거운 OS 스레드를 사용하기 때문에 개수에 제약을 받고 동시 접속 가능 개수도 제한적이다.
  • 비동기 I/O 모델은 단일 이벤트 루프 스레드가 I/O 요청을 각 이벤트 핸들러로 디스패치한다. 다숭 스레드를 사용하는 오버헤드가 없기때문에 확장성이 좋으나 훨씬 복잡하고 디거빙이 어려운 단점이 있다. 또한 이벤트 핸들러는 이벤트 루프 스레드가 블로킹되지 않도록 제어권을 신속하게 반환해야 한다.
• 게이트웨이는 서킷브레이크 패턴등을 이용해 실패한 요청이나 지연 시간이 긴 요청도 적절히 처리 할 수 있어야 한다.