최근 진행된 Ingress Controller와 Service Mesh의 거의 모든 웨비나 중에서 우리는 몇가지의 변형된 질문들을 들었습니다.
질문으로는 NGINX의 Tool들은 API gateway와 어떻게 다릅니까? 의 질문, 또는 Kubernetes환경에서 API gateway와 Ingress Controller(또는Service Mesh) 가 모두 필요합니까? 라는 질문이었습니다.
위의 질문들에 대한 사용자의 혼란은 두 가지의 이유로 이해가 가능한 부분입니다.
- Ingress Controller와 Service Mesh는 API gateway의 많은 사용사례에 충족시킬 수 있습니다.
- 일부 벤더들은 API gateway 를 Ingress Controller 또는 Service Mesh를 대안으로 포지셔닝 하거나
세가지의 기능들을 하나의 도구로 통합합니다.
1. 기본 정의
API gateway, Ingress Controller, Service Mesh의 코어는 각 유형의 프록시이며,
사용자가 설정한 라우팅 설정에 따라 각 엔드 포인트로 클라이언트를 대리하여 요청하고
응답을 받으면 다시 클라이언트에게 전달하는 역할을 합니다.
2. API Gateway?
API gateway는 Client의 요청을 적절한 서비스로 라우팅하고 요청자에게 응답을 다시 보내는 기능을 담당합니다.
그러나 이 간단한 정의에 대한 큰 오해로 API gateway가 특별한 기술로 인식되고 있다는 점이다.
대신, “API gateway”는 다른 유형의 프록시를 통해 구현될 수 있는 일련의 사용사례로 설명됩니다.
일반적으로, API gateway는 ADC 또는 로드 밸런서, 그리고 점점 더 증가되는 Ingress Controller 또는 Service Mesh로 설명됩니다.
그러나 업계에서 API gateway 역할을 하기 위해 어떠한 툴이 수행 능력을 가진 “필수” 기능인지에 대한 합의가 많지 않습니다.
일반적으로, 다음과 같은 기능을 요구하는 고객을 볼 수 있습니다. (사용 사례별로 분류)
A. 장애 허용력 사례(Resilience Use Cases)
- A/B testing, canary 배포 및 blue-green 배포
- 프로토콜 변환(예: JSON과 XML 간)
- 속도 제한(Rate limiting)
- 서비스 발견(Service discovery)
B. 트래픽 관리 사용 사례(Traffic Management Use Cases)
- 메서드(Method) 기반 라우팅 및 매칭(Matching)
- 요청/응답 헤더 및 본문(body) 조작(manipulation)
- Layer 7에서 라우팅 요청
C. 보안 사용 사례(Security Use Cases)
- API schema enforcement
- 클라이언트 인증 및 권한 부여
- 맞춤화(Custom) 응답
- 세분화된 액세스 제어(Fine grained access control)
- TLS 종료(TLS termination)
위에 소개된 거의 모든 공통적인 사용사례는 Kubernetes 환경에서 일반적으로 사용됩니다.
프로토콜의 변환 및 요청 / 응답 헤더 및 본문 처리는 덜 흔하게 사용됩니다.
그 이유는 Kubernetes 와 마이크로 서비스 환경에 적합하지 않은 Legacy API 에 묶여 있기 때문입니다.
3. Ingress Controller ?
Ingress Controller(Kubernetes Ingress Controller – 줄여서 KIC 라고 명명됨)는 Layer 4 및 Layer 7의 프록시로
트래픽을 Kubernetes 로 가져오고 서비스로 이동하고 다시 되돌리는 기능입니다. (North-South / East-Weat Traffic )
트래픽 관리 외에도 Ingress Controller는 가시성, 문제 원인 진단, 보안, ID, 가장 고급기능의 API gateway 사용 사례를 제외하고 모든 용도로 사용이 가능합니다.
4. Service Mesh ?
Service Mesh는 Kubernetes 서비스 간의 트래픽의 흐름 ( Service to Service / East - West Traffic )을 처리하고
일반적으로 종단 간 암호화(E2EE / End to End Encryption )를 성공시키는 용도로 사용됩니다.
Service Mesh의 책임은 작지만 고급 배포를 하거나 또는 E2EE에 대한 요구 사항이 가진 조직이 증가하면서 역할이 커지게 됩니다.
Service Mesh는 어플리케이션에 매우 가까운 분산형(경량화)API gateway로 사용할 수 있으며
Service Mesh Side-car를 통해 데이터 영역 레벨(패킷 송/수신 담당)에서 가능하게 됩니다.