서비스 메쉬, API 게이트웨이가 둘 다 써야 할까?

이 글은 이 포스트를 보고 요약 정리한 것임을 밝힙니다.

기본적으로 API 게이트웨이는 외부에서 들어오는 트래픽에 대한 제어, 즉 North-South 트래픽 제어를 담당한다. 반면 서비스 메쉬는 서비스 간의 통신, East-West 트래픽을 위한 것이다. 하고자 하는 일이 다른데 왜 이런 혼선이 생기는걸까? 첫째로 프록시와 같은 기술을 기본적으로 공유하고 있다.
또 트래픽 제어, 라우팅, 메트릭 수집, 보안/정책 적용 등 기능이 중복된다. 서비스 메시가 자체로 Ingress Gateway 같은 것을 갖는 경우가 있어서 더 혼란스럽게 된다.

아래는 Istio (+Istio Gateway)와 다른 API 게이트웨이들이 공통적으로 제공하는 기능들이다.

• 분산추적
• 서비스 검색
• 부하분산
• TLS termination
• JWT 유효성 검사
• 요청 라우팅
• 트래픽 분할
• 카나리 배포
• 트래픽 미러링
• Rate limiting

그렇지만 서비스 메쉬는 API GW 보다 낮은 수준에서 동작하며 아키텍처 내 모든 개별 서비스에서 작동한다. '더 낮은 수준'이라 함은 조금 덜 추상화된 상태로 많은 작업과 데이터를 처리한다는 의미이다. 토폴로지 제공(클라이언트 사이드 로드밸런싱, 서비스 디스커버리, 라우팅), 구현해야 하는 복원 메커니즘(타임아웃, 리트라이 제한, Circuit breaker), 트레이스 및 지표 측정, mTLS와 RBAC과 같은 보안 흐름 유지 등을 제공한다. 이 기능들이 사이드카로 주로 제공된다. 서비스 메쉬는 어플리케이션 코드 안에 들어가고 싶어하는 것이 아니라, 코드의 통합 없이 서비스에 '얹혀지는' 방식으로 이런 문제들을 해결한다.

API Gateway 에서만 제공되는 기능들

반면 API GW는 특정 API를 대신하여 사용자와의 경계 부분에 위치해서 모든 서비스에 대한 추상화를 제공하는 것을 목표로 한다. API GW는 서비스 메쉬의 존재 여부와 관계 없이 어플리케이션/서비스 위에 존재한다. 근본적으로 제로 트러스트를 전제하며 사용자들에게 대문 역할을 수행해준다. 마이크로서비스 환경에서 API GW는 1) 경계 디커플링 2) 데이터에 대한 엄격한 통제 3) 도메인 간 안전한 연결이라는 중요한 기능을 제공하는데, 이는 서비스 메쉬가 해결해주지 못하는 것들이다.

경계 디커플링 Edge Decoupling

요청/응답 변환, REST/SOAP/XSLT와 같은 프로토콜 변환, 오류/속도 제한에 따른 응답 사용자 지정, 자체적으로 직접 응답, API 그룹화 등이 여기에 포함된다.

1. 요청/응답 변환: 실제 백엔드 API가 구현되어 있는 세부 정보가 노출되지 않게 하기 위해 Request를 변경, 헤더 제거/추가, 헤더를 페이로드로 옮기거나 등등을 할 수 있다.
2. 애플리케이션 프로토콜 변환: 많은 어플리케이션들은 XML, JSON 등 다양한 방식으로 소통한다. 상호운용성을 확보하기 위해 프로토콜 변환 과정이 필요할 수 있다.
3. 오류/속도 제한에 대한 응답 사용자 지정: 게이트웨이 자체에서 응답을 보내는 경우 이를 커스터마이즈 할 수 있어야 한다. 
4. 직접 응답: 클라이언트가 이용이 불가능한 자원을 요청하거나 어떤 이유로 업스트림이 차단된 경우, 프록시를 종료하고 사전 통제된 응답으로 대응할 수 있어야 한다.
5. 프록시 파이프라인에 대한 제어: API GW는 세부 기능이 적용되는 순서 (Rate limit, Auth, 라우팅, 요청 변환 등)를 변경할 수 있어야 한다. 또한 상황이 잘못되었을 경우 디버깅할 수 있는 방법을 제공할 수 있어야 한다.
6. API 구성/그룹화: 여러 API를 단일 API로 마스킹해야 하는 경우도 생긴다. GraphQL 같은 것들이 그 예가 될 수 있다.

데이터에 대한 엄격한 통제

어떤 데이터와 요청, 응답이 허용되는지 관리하는 것 역시 API GW의 큰 역할이다. 게이트웨이는 아키텍처에 들어오는 요청이나 나가는 응답을 깊이 이해할 필요가 있다. SQL Injection 같은 것이 예가 될 수 있다. 이런 기능은 단순히 클러스터에 HTTP 트래픽을 허용하는 것과는 다르다.

사용자 지정 트러스트 도메인 관리

어플리케이션 아키텍처가 외부에 존재하는 사용자와 서비스에 대해 액세스가 제한될 수 있도록 ID 및 인가 정책을 제공하는 것이 포함된다. Open ID Connect를 포함한 OAuth/SSO와의 통합이 얼마나 잘되냐 하는 것이다. API GW는 자체로 사용자 정의를 할 수 있는 것 뿐 아니라 이런 환경에 유연하게 적응할 수 있는 방법을 갖추고 있어야 한다.

그래서 둘 다 있어야 해요?

일단 엣지와의 연결, 즉 외부와의 연결을 어떻게 할 것인지에서부터 생각해봐야 한다. 여기에서 Ingress Controller, API GW를 선택한다.  API GW는 기능 면에서 서비스 메시와 중복된다. 맞다. 그러나 역할 자체는 상당히 다르기 때문에 함께 사용을 고려해야 한다.