마이크로서비스 패턴(8)

외부 API 패턴

핵심 내용

• 다양한 클라이언트에서 사용 가능한 API를 설계하는 과제
• API 게이트웨이 패턴, BFF 패턴 적용
• API 게이트웨이 설계와 구현
• 리액티브 프로그래밍을 응용하여 API 조합을 단순화
• GraphQL로 API 게이트웨이 구현

외부 API 설계 이슈

• 애플리케이션의 외부 API는 클라이언트 종류가 다양한 만큼 설계가 어려움
• FTGO 애플리케이션의 서비스 API 소비 클라이언트
  • 웹 애플리케이션, 자바스크립트 애플리케이션, 소비자용/배달원용 모바일 앱, 서드파티 애플리케이션
• 웹 애플리케이션은 서비스 API가 방화벽 내부에서 실행되기 때문에 대역폭이 높고 지연 시간이 짧은 LAN을 통해 서비스 접속
• 다른 클라이언트는 서비스 API가 방화벽 외부에 있으므로 상대적으로 대역폭이 낮고 지연이 높은 환경에서 서비스에 접근

API 설계 이슈: FTGO 모바일 클라이언트

• 모놀리식 버전에서는 주문 내역 API가 하나만 필요
• 마이크로서비스 버전에서는 서비스를 여러번 호출해서 데이터를 가져와야함(모바일 앱이 API 조합기 역할)

클라이언트가 요청을 여러번 전송하기 떄문에 UX가 나빠짐

• 네트워크 지연 발생

캡슐화가 되지 않아 프런트엔드 개발자가 백엔드와 맞물려 코드를 변경해야함

• 애플리케이션이 발전함에 따라 기존 클라이언트와 호환되지 않는 변경을 해야할 일이 생길 수 있음

클라이언트에 비친화적인 IPC를 사용 중인 클라이언트도 존재 가능

• 클라이언트가 소비하기 어려운 프로토콜을 사용하는 서비스도 존재
• gRPC, AMQP 등 내부에서는 잘 작동하지만, 모바일 클라이언트가 소비하기 어려운 경우가 많음

API 설계 이슈: 다른 종류의 클라이언트

• 모바일 클라이언트뿐만 아니라 방화벽 외부에 있는 다른 종류의 클라이언트도 이슈 존재
• 웹 애플리케이션
  • 웹 애플리케이션은 직접 백엔드 서비스에 접근하는 것이 얼마든지 가능
• 브라우저 기반의 자바스크립트 애플리케이션
  • 최근 브라우저 애플리케이션에서 자바스크립트를 많이 사용
  • 서비스 API 변경 시업데이트하기는 쉽지만, 모바일 앱처럼 인터넷을 통해 서비스에 접근하기 때문에 네트워크 지연 문제는 별반 차이 없음
• 서드파티 애플리케이션
  • 인터넷을 통해 API에 접속하기 때문에 API 조합이 비효율적인 공산이 큼
  • API 조합의 비효율성은 서드파티 애플리케이션용 API를 설계하는 어려움에 비하면 비교적 사소한 문제

API 게이트웨이 패턴

• API 게이트웨이 패턴
  • 마이크로서비스 애플리케이션에 외부 API 클라이언트의 진입점에 해당하는 서비스를 구현

API 게이트웨이 패턴 개요

• API 게이트웨이는 방화벽 외부의 클라이언트가 애플리케이션에 API 요청을 하는 단일 창구 역할을 하는 서비스
• 퍼사드 패턴과 유사하며 내부 애플리케이션 아케틱처를 캡슐화하고 자신의 클라이언트에는 API를 제공함
• 인증, 모니터링, 사용량 제한 등 부수적인 일도 담당
• 요청 라우팅, API 조합, 프로토콜 변환을 관장

요청 라우팅

• 요청이 들어오면 API 게이트웨이는 라우팅 맵을 찾아보고 어느 서비스로 요청을 보낼지 결정
• 라우팅 맵은 예를 들자면 HTTP 메서드와 HTTP URL을 매핑한 것

API 조합

• 요청 한 번으로 필요한 데이터를 조회할 수 있도록 대단위 API 제공(API 조합)

프로토콜 변환

• REST와 gRPC를 혼용할 경우에도 외부 클라이언트에는 REST API로 제공 가능
• API 작업을 구현한 코드에서 외부 REST API <-> 내부 gRPC API 변환 처리

API 게이트웨이는 클라이언트마다 적합한 API를 제공

• 각 클라이언트에 맞춤 API 제공하는 방법이 좋음

엣지 기능 구현

• 인증, 인가, 사용량 제한, 캐싱, 지표 수집, 요청 로깅 등 애플리케이션 주변에 구현된 요청 처리 기능 제공

API 게이트웨이 아키텍처

• API 게이트웨이는 API 계층과 공통 계층으로 구성된 모듈 아키텍처 구조
• API 계층
  • 독립적인 하나 이상의 API 모듈이 있고, 각 API 모듈에는 특정 클라이언트용 API가 구현되어 있음
• 공통 계층
  • 엣지 기능 등 공통 기능이 구현되어 있음

API 게이트웨이 소유권 모델

• API 게이트웨이 개발/운영 주체
  • API 게이트웨이 전담할 팀을 따로 신설하는 방법(MSA 사상과 배치됨)
  • API가 표출된 모듈은 해당 클라이언트 팀이 소유하는 구조(넷플릭스에서 권장)

프런트엔드 패턴을 위한 백엔드

• 각 클라이언트마다 API 게이트웨이를 따로 두는 BFF(Backends For Frontends) 패턴 적용
• BFF(프런트엔드를 위한 백엔드) 패턴
  • 각 클라이언트 종류마다 API 게이트웨이를 따로 구현
  • 하나의 클라이언트 팀이 개발/운영하는 스탠드얼론 API 게이트웨이가 되는 구조
• 모바일 클라이언트 팀, 브라우저 클라이언트 팀, 퍼블릭 API 팀 등 개별로 API 게이트웨이 구현

API 게이트웨이의 장단점

• API 게이트웨이 장점
  • 애플리케이션 내부 구조를 캡슐화
  • 각 클라이언트마다 최적의 API 제공
• API 게이트웨이 단점
  • 개발, 배포, 관리를 해야 하는 고가용 컴포넌트가 늘어남
  • 서비스 API 표출 시 반드시 API 게이트웨이를 업데이트가 필요하여 개발 병목 지점이 될 가능성이 있음

API 게이트웨이 설계 이슈

• 성능과 확장성
  • 블로킹 I/O를 사용할지 논블로킹 I/O를 사용할지 선택 문제
  • 블로킹 I/O
    • OS 스레드를 사용하기 떄문에 스레드 개수에 제약을 받고 API 게이트웨이의 동시 접속 가능 개수도 제한적
  • 논블로킹 I/O
    • 단일 이벤트 루프 스레드가 I/O 요청을 각 이벤트 핸들러로 디스패치 처리
    • 다중 스레드를 사용하는 오버헤드가 없기 때문에 확정성이 더 좋음
    • 블로킹에 비해 훨씬 복잡한 편이라서 코드 작성 및 이해가 어렵고 디버깅하기 어려운 단점 존재
• 리액티브 프로그래밍 추상체
  • API 조합 코드는 리액티브하게 선언형 스타일로 작성하는 것이 좋음
• 부분 실패 처리
  • 로드 벨런서 후면에 여러 게이트웨이 인스턴스를 두고 가동
  • 실패한 요청, 지연 시간이 너무 긴 요청에 대해서는 서킷 브레이커 패턴 적용으로 해결
• 아키텍처의 선량한 시민 되기
  • 서비스 디스커버리 패턴을 이용하여 API 게이트웨이 같은 서비스 클라이언트가 자신이 호출할 서비스 인스턴스의 네트워크 위치를 파악
  • 관층성 패턴 활용하여 애플리케이션 동작 상태를 모니터링하고 문제를 진단하는데 도움이 됨

API 게이트웨이 구현

• 기성 API 게이트웨이 제품/서비스를 활용하는 방법
• API 게이트웨이 프레임워크 또는 웹 프레임워크를 기반으로 API 게이트웨이를 직접 개발

참고

• 마이크로서비스 패턴 자바(저 : 크리스 리처드슨)