마이크로서비스 패턴 8장

애플리케이션에서 서비스 API를 소비하는 클라이언트 종류(웹,앱,TV등등...)가 많은 경우, 아래와 같은 문제가 생긴다.

• 매번 그 클라이언트를 위한 API를 만들어줘야하고, 여러번 요청해야하는 문제. 뿐만 아니라, 여러번 요청이 LAN이 아닌 경우, 지연이 생길 수 있음
• 클라이언트가 서비스 및 API를 알아야하는 구조라서 캡슐화가 되지않고, 나중에 아키텍처와 API를 바꾸기 어렵다. (기존 API를 삭제하기 어려운 구조)
• 클라이언트가 사용하기 불편한 API일 수 있음 (프로토콜을 내부에서는 AMQP를 사용하지만, 모바일 클라이언트는 소비하기 어려울 수 있음)

API 게이트웨이 패턴

API 게이트웨이 : 애플리케이션에 API 요청을 하는 단일 창구.

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

• 게이트웨이 엣지 기능

  • 인증(authentication): 요청한 클라이언트의 신원을 확인
  • 인가(authorization): 특정 작업을 수행하도록 허가받은 클라이언트인지 확인
  • 사용량 제한(rate limiting): 특정(또는 전체) 클라이언트의 초당 요청 개수를 제한
  • 캐싱(caching): 서비스 요청 횟수를 줄이고자 응답을 캐시
  • 지표 수집(metrics collection): 과금 분석용 API 사용 지표 수집
  • 요청 로깅: 요청을 기록.

• API 게이트웨이 장점

  • API 게이트웨이의 가장 큰 장점은 애플리케이션의 내부 구조를 캡슐화. 클라이언트가 특정 서비스를 호출할 필요 없이 무조건 게이트웨이에 이야기를 하면 됌. API 게이트웨이는 클라이언트마다 최적의 API를 제공하므로 클라이언트 - 애플리케이션 간 왕복 횟수도 줄고 클라이언트 코드 역시 단순.

• API 게이트웨이 단점

  • 개발, 배포, 관리를 해야 하는 고가용 컴포넌트가 하나 더 늘어나는 부담은 감수해야 함. API 게이트웨이가 개발 병목 지점이 발생할 수 있음. 이를 위해 BFF 패턴(클라이언트 종류당 API Gateway를 따로 두는 방식)을 도입할 수도 있다.

API 게이트웨이 구현

• AWS API Gateway의 사용 (API 조합이 필요없는 경우)
• 콩 (엔진엑스 HTTP 서버
• 트래픽(Traefik) (Go언어 기반 API Gateway)
• 넷플릭스 주울
• 스프링 클라우드 게이트웨이
• GraphQL
  • 매번 구현을 하지 않아도 되고, 클라이언트가 반환 데이터를 제어 가능.
  • graphQL 스키마 필드에 리졸버함수를 붙여 활용
  • 서버쪽 배칭/캐싱을 통한 성능향상