1. API Gateway Pattern

• API Gateway는 마이크로서비스 아키텍처에서 핵심적인 역할을 수행하는 컴포넌트입니다.
• 외부 클라이언트의 요청을 받아 적절한 내부 서비스로 라우팅하는 단일 진입점 역할을 합니다.
• 객체지향 설계의 Facade 패턴과 유사하게 시스템의 복잡성을 숨기고 단순화된 인터페이스를 제공합니다.
• 클라이언트와 백엔드 서비스 사이의 중개자 역할을 수행하여 서비스 디스커버리, 로드 밸런싱 등을 처리합니다.
• 인증, 인가, 모니터링, 로깅 등 공통 관심사를 중앙화하여 처리할 수 있습니다.

1.1 장단점

• 장점:
  • 클라이언트 요구사항에 맞춘 API를 제공할 수 있습니다
  • 내부 서비스 구조를 캡슐화하여 클라이언트와의 결합도를 낮출 수 있습니다
  • 공통 관심사를 중앙에서 처리할 수 있습니다
  • 클라이언트별 최적화된 API를 제공할 수 있습니다
• 단점:
  • 추가적인 네트워크 홉으로 인한 레이턴시 증가가 발생할 수 있습니다
  • 시스템의 복잡도가 증가하며 운영 부담이 커질 수 있습니다
  • 단일 실패 지점이 될 수 있어 고가용성 설계가 필수적입니다

2. 요청 라우팅

• API Gateway의 핵심 기능인 요청 라우팅은 다음과 같은 방식으로 동작합니다
• URI 기반 라우팅: 요청 URI 패턴에 따라 적절한 서비스로 라우팅
• 컨텐츠 기반 라우팅: 요청 헤더나 페이로드 내용을 기반으로 라우팅
• 동적 라우팅: 서비스 디스커버리와 연동하여 동적으로 라우팅 대상 결정

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/api/users/**

• Spring Cloud Gateway를 사용한 라우팅 설정 예시입니다.
• path가 /api/users/**인 요청은 user-service로 라우팅됩니다.

3. API 조합

• API Gateway는 여러 마이크로서비스의 API를 조합하여 클라이언트에 최적화된 API를 제공할 수 있습니다.
• 이는 Facade 패턴의 확장된 형태로 볼 수 있으며, 클라이언트의 복잡한 요구사항을 단순화된 인터페이스로 제공합니다.

3.1 API 조합의 예시

• 주문 내역 조회 API를 예로 들어보겠습니다:
  • 주문 서비스: 기본 주문 정보 제공
  • 배송 서비스: 배송 상태 정보 제공
  • 결제 서비스: 결제 상태 및 내역 제공
  • 상품 서비스: 주문된 상품의 상세 정보 제공
• API Gateway는 이러한 여러 서비스의 API를 호출하고 결과를 조합하여 클라이언트에게 통합된 응답을 제공합니다.
• 따라서 클라이언트는 여러 서비스에 대한 복잡한 호출을 하나의 API 호출로 단순화할 수 있습니다.

3.2 장점

• 네트워크 효율성:
  • 클라이언트가 여러 번의 저성능 네트워크(인터넷) 호출을 하는 대신, API Gateway가 한 번의 저성능 네트워크 호출로 내부의 고성능 네트워크를 통해 여러 서비스와 통신
• 응답 최적화: 클라이언트에 필요한 데이터만 선별하여 제공
• 서비스 캡슐화: 내부 서비스 구조를 숨기고 단순화된 API 제공

3.3 단점

• 게이트웨이 복잡도 증가: API 조합 로직으로 인한 복잡도 상승
• 성능 병목: 여러 서비스 호출을 동기적으로 처리할 경우 전체 응답 시간 증가
• 장애 전파: 단일 서비스의 장애가 전체 응답에 영향을 미칠 수 있음

4. 프로토콜 변환

• API Gateway는 다양한 프로토콜 간의 변환을 지원합니다:
• REST API를 GraphQL로 변환
• gRPC를 REST로 변환
• WebSocket과 HTTP 프로토콜 간 변환
• 레거시 프로토콜과 현대적인 프로토콜 간의 브릿지 역할

5. 부가 기능

5.1 인증 및 인가

• JWT 토큰 검증
• OAuth2.0 인증 처리
• RBAC(Role Based Access Control) 구현

5.2 사용량 제한

• Rate Limiting 구현
• Quota 관리
• Circuit Breaker 패턴 적용

5.3 모니터링 및 로깅

• 요청/응답 로깅
• 성능 메트릭 수집
• 분산 트레이싱 연동

6. API 게이트웨이 아키텍처

• API 게이트웨이는 크게 두 개의 계층으로 구성됩니다

6.1 API 계층

• API 계층에는 독립적인 하나 이상의 API 모듈이 있습니다.
• 각 모듈은 클라이언트별 맞춤 API가 구현되어 있습니다.
• 예를 들어, 모바일, 브라우저, 퍼블릭 API로 모듈을 구분할 수 있습니다.

6.2 공통 계층

• 인증/인가 처리와 같은 모든 API에 필요한 기능은 공통 계층에 구현됩니다.
  • 인증/인가 처리
  • 로깅 및 모니터링
  • 캐싱
  • 오류 처리

7. API 게이트웨이 소유권

• API 게이트웨이의 효율적인 운영을 위한 소유권 모델:
  • 클라이언트별 API 모듈은 해당 클라이언트 팀이 담당
  • 공통 기능은 전담 플랫폼 팀이 관리
• 이러한 관리는 책임 소재를 불분명하게 합니다.
  • 여러 팀 사람들이 동일한 코드베이스에 소스를 커밋하고 API 게이트웨이 팀이 그 운영을 맡는 구조
  • 해결 방법은 BFF 패턴을 적용하여 클라이언트별 API 게이트웨이를 구축하는 것입니다.

8. BFF (Backend For Frontend) 패턴

• BFF 패턴은 클라이언트별로 전용 API 게이트웨이를 구축하는 방식입니다:
  • 클라이언트의 특성에 최적화된 API 제공
  • 프론트엔드 팀의 자율성 보장
  • 변경의 영향도를 최소화
• 공통 계층의 기능은 API 게이트웨이 팀의 공유 라이브러리를 사용합니다.

팁

BFF 구현 시에는 프론트엔드 팀과 동일한 기술 스택을 사용하는 것이 유지보수성을 높일 수 있습니다.

9. Spring Cloud Gateway 소개

• Spring Cloud Gateway는 API 게이트웨이 구현을 위한 강력한 프레임워크입니다:
  • 비동기-논블로킹 아키텍처
  • 선언적 라우팅 설정
  • 풍부한 필터링 기능
  • Spring Boot와의 완벽한 통합
• SpringCloudGateway 참고