![API 게이트웨이 패턴과 클라이언트-마이크로 서비스 간 직접 통신 Microsoft Docs](https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/media/direct-client-to-microservice-communication-versus-the-api-gateway-pattern/custom-service-api-gateway.png)

여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 된다면 매우 복잡한 호출 관계가 만들어질 것이다. 이러한 복잡성을 통제하기 위한 방법이 필요하다.

한 가지 해결책이 API 게이트웨이(Gateway)다. 다양한 클라이언트가 다양한 서비스에 접근하기 위해 단일 진입점을 만들어 놓으면 여러가지로 효율적이다. 다른 유형의 클라이언트에게 서로 다른 API 조합을 제공할 수도 있고, 각 서비스에 접근할 때 필요한 인증/인가 기능을 한번에 처리할 수도 있다. 정상적으로 동작하던 서비스에 문제가 생겨 서비스 요청에 대한 응답 지연이 발생하면 정상적인 다른 서비스로 요청 경로를 변경하는 기능이 작동되게 할 수 있다.

이런 서비스 흐름 제어를 위한 서비스 라우팅 기능은 L4 같은 하드웨어 장비로 구현할 수도 있고 소프트웨어로 구현할 수도 있다. 소프트웨어로 구현할 경우 API 게이트웨이가 애플리케이션 레벨의 라우팅 기능을 수행한다. 또 여러 인스턴스로 부하를 분산하는 로드 밸런싱도 수행하고, 라우팅시 필터를 둬서 라우팅 전과 후에 각각 수행되는 선행 처리와 후행 처리, 에러 처리 등을 손쉽게 구현할 수 있다.

정리하면 API 게이트웨이는 다른 서비스와 연계해서 다음과 같은 기능을 제공한다.

  • 레지스트리 서비스와 연계한 동적 라우팅, 로드 밸런싱
  • 보안: 권한 서비스와 연계한 인증/인가
  • 로그 집계 서비스와 연계한 로깅 (API 소비자 정보, 요청/응답 데이터)
  • 메트릭(Metrics) (에러율, 평균/최고 지연시간, 호출 빈도)
  • 트레이싱 서비스와 연계한 서비스 추적 (트래킹 ID 기록)
  • 모니터링 서비스와 연계한 장애 격리(서킷 브레이커 패턴)

이러한 API 게이트웨이 패턴은 스프링 클라우드의 스프링 API 게이트웨이 서비스(Spring API Gateway Service)라는 제품으로 구현할 수 있다. 스프링 게이트웨이 서비스는 스프링 웹사이트(spring.io)에서 내려받아 간단한 스프링 어노테이션(Annotation) 설정만으로 손쉽게 적용할 수 있다.

다른 클라우드 플랫폼에서도 이러한 API 게이트웨이 패턴을 지원하는데, 쿠버네티스의 경우 자체 기능인 쿠버네티스 서비스(Kubernetes Service)와 인그레스 리소스(ingress resources)로 제공한다.

참고로 앞에서 API 게이트웨이는 프론트엔드가 백엔드를 호출할 때 뿐만 아니라 외부 레거시 시스템과 단일 지점에서 서로 다른 형태의 API를 연계하는 용도로 사용되기도 한다.

원문

도메인 주도 설계로 시작하는 마이크로서비스 개발 - YES24