MSA 환경에서의 API Gateway

Gemini가 그려준 API GATEWAY

 

요즘 MSA에 대한 지식을 새로 정의하고 있습니다.
그러다보니, API Gateway의 역할과 중요성에 대해서 깨닫고 있는데요.
이번 글에서 관련된 내용을 정리해보고자 합니다.

MSA에 관련한 내용은 아래 글 참고해주세요!

https://deep-flame.tistory.com/48

클라우드 네이티브 애플리케이션 디자인 패턴: AI 플랫폼 개발자의 아키텍처 성찰

 

 

API Gateway란 무엇이며, 왜 필요한가?

마이크로서비스 아키텍처(MSA)에서는 수많은 서비스가 존재합니다.
API Gateway는 이러한 서비스들의 단일 진입점(Single Entry Point) 역할을 수행하는 서버입니다.
클라이언트(웹, SDK, CLI)가 수십 개의 마이크로서비스 주소를 일일이 알 필요 없이, 이 '대문' 하나만 호출하면 나머지는 알아서 배달해 주는 것이죠.

https://learn.microsoft.com/ko-kr/azure/architecture/microservices/design/gateway

API 게이트웨이는 중개자 역할을 하며 애플리케이션 서비스가 클라이언트에 직접 노출되는 것을 방지합니다. 
API 게이트웨이가 없으면 클라이언트는 개별 애플리케이션 서비스와 직접 통신해야 하므로 다음과 같은 문제가 발생할 수 있습니다.

• 복잡한 클라이언트 코드: 클라이언트는 여러 엔드포인트를 추적하고 오류를 탄력적으로 처리해야 합니다.
• 결합도 상승: 클라이언트는 개별 서비스가 변경될 때마다 이를 반영하는 작업이 필요합니다.
• 대기 시간증가: 클라이언트와 서버 간에 여러 네트워크 왕복이 발생할 수 있으므로 대기 시간이 상당히 늘어나게 됩니다.
• 에러 사항 중복 처리: 각 공용 서비스는 인증, SSL 및 클라이언트 속도 제한과 같은 문제를 처리해야 합니다.

이러한 문제를 해결하기 위해서 API Gateway가 정의되었습니다.

 

API Gateway의 역할

1. 인증 및 인가

모든 마이크로서비스가 각자 "너 누구니?"라고 물어보는 것은 비효율적입니다.
아래와 같이 인증/인가를 처리할 수 있지만, 각자 요구사항에 따라 얼마든지 달라질 수 있습니다.

• 중앙 집중식 검증: Gateway가 입구에서 JWT의 서명을 확인하고 만료 여부를 체크합니다.
• 권한 부여: 사용자 토큰에 담긴 권한(Role)을 확인하여, 일반 사용자가 '모델 삭제' API에 접근하지 못하도록 입구에서 컷합니다.
• 신원 전달: 인증에 성공하면 Gateway는 X-User-ID 같은 커스텀 헤더에 사용자 정보를 담아 내부 서비스로 전달합니다.

2. 동적 라우팅 및 로드 밸런싱

클라이언트는 하나의 주소만 알면 되지만, 내부적으로는 수십 개의 서비스로 흩어집니다.

• 경로 기반 라우팅: /v1/train/ 요청은 학습 서비스로, /v1/predict/ 요청은 서빙 서비스로 지능적으로 라우팅합니다.
• 서비스 디스커버리 연동: Kubernetes 환경에서 파드(Pod)의 IP가 수시로 변해도, Gateway는 서비스 이름을 통해 살아있는 파드를 찾아 트래픽을 보냅니다.
• 카나리(Canary) 테스트: 새로운 모델 서빙 코드를 배포했을 때, 전체 트래픽의 5%만 신규 버전으로 보내는 등의 정교한 제어가 가능합니다.

3. 처리율 제한 및 서킷 브레이킹

• API 할당량 관리: LLM 인퍼런스는 비용이 비싸기 때문에, 사용자 등급에 따라 분당 호출 횟수(RPM)를 제한합니다.
• 장애 전파 방지: 특정 서비스가 응답 불능 상태라면, Gateway가 즉시 서킷 브레이커를 작동시켜 사용자에게 "잠시 후 다시 시도해 주세요"라는 응답을 빠르게 돌려줍니다. 이는 시스템 전체가 연쇄적으로 마비되는 것을 막습니다.

4. 요청 및 응답 변환

• 프로토콜 변환: 외부 클라이언트는 다루기 쉬운 REST/JSON으로 요청하지만, 내부 서비스끼리는 고성능 통신을 위해 gRPC를 사용할 때 Gateway가 중간에서 이를 변환해 줍니다
• 데이터 가공: 보안을 위해 응답에서 민감한 필드를 삭제하거나, 여러 서비스의 응답을 하나로 합쳐서(API Aggregation) 클라이언트에 전달하기도 합니다.

5. 관찰 가능성

• 통합 로깅: 모든 요청의 시작과 끝을 기록하므로, 에러 발생 시 추적이 매우 용이합니다.
• 지표 수집: API별 응답 시간(Latency), 성공률, 트래픽 양 등을 수집하여 Prometheus나 Grafana 대시보드에 뿌려줍니다.

 

 

API Gateway 솔루션

그럼 API Gateway 솔루션들은 무엇이 있을까요?
사실 Public Cloud 환경을 사용한다면 각각의 환경에 맞는 완전 관리형 솔루션을 제공하기 때문에 접근성이 좋습니다.

• AWS: Amazon API Gateway
• GCP: Apigee
• Azure: Azure API Management

 

그 외에 오픈소스를 살펴보겠습니다.

Kong

전 세계적으로 가장 널리 사용되는 오픈소스 API Gateway로, 고성능 웹 서버인 NGINX를 기반으로 구축되었습니다.

• Cloud Native: 컨테이너 환경에 최적화되어 있으며, 특히 Kubernetes Ingress Controller로서의 인기가 매우 높습니다.
• Plug-and-Play: 기본 기능은 최소화하고, 필요한 기능(JWT 인증, Rate Limiting 등)은 '플러그인'을 꽂듯이 추가하는 구조입니다.

https://developer.konghq.com/gateway/

 

Istio Ingress Gateway

Istio Ingress Gateway는 고성능 프록시인 Envoy를 Data Plane으로 사용합니다.
최근에는 Kubernetes 표준인 Gateway API의 표준 구현체로서 입지를 굳히고 있습니다.

• 인프라 중심: 트래픽 분할, mTLS 암호화, 서킷 브레이킹 등 네트워크 계층의 복잡한 제어에 특화되어 있습니다.
• 서비스 메시 통합: 클러스터 내부 통신과 외부 통신을 동일한 Envoy 기반 정책으로 일관되게 관리할 수 있습니다.

https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/

Ingress Gateways