서비스 메시 vs API 게이트웨이
이전 서비스 메시 관련 글에서 저는 서비스 메시와 API 게이트웨이 간의 관계에 대한 몇 가지 질문을 언급했습니다. 이 글에서는 서비스 메시와 API 게이트웨이의 용도에 대해 더 자세히 논의할 예정입니다.
API 게이트웨이와 서비스 메시를 구별하기 위해 먼저 각자의 주요 특징을 살펴보겠습니다.
API 게이트웨이: 서비스를 관리형 API로 외부에 노출
API 게이트웨이를 사용하는 주된 목적은 마이크로서비스를 관리형 API로 (외부 시스템에) 노출하는 것입니다. 따라서 API 게이트웨이 계층에서 개발된 API 또는 경계 서비스는 외부로 비즈니스 기능을 제공합니다.
API/경계 서비스는 하위의 조합 또는 원자적 마이크로서비스를 호출하며, 여러 하위 마이크로서비스를 조합/혼합하는 방식으로 비즈니스 로직을 제공합니다.
API/엣지 서비스가 하위 서비스를 호출할 때, 회로 차단기, 타임아웃, 로드 밸런싱/장애 조치와 같은 신뢰성 패턴이 적용된 신뢰할 수 있는 통신 방식을 사용해야 합니다. 따라서 대부분의 API 게이트웨이 솔루션은 이러한 기능을 내장하고 있습니다.
API 게이트웨이는 또한 서비스 디스커버리, 분석 (가시성: 성능 지표, 모니터링, 분산 로깅, 분산 호출 추적) 및 보안을 포함한 다음 기능에 대한 지원을 내장하고 있습니다.
API 게이트웨이는 API 마켓플레이스/스토어, API 게시 포털과 같은 API 관리 생태계의 다른 구성 요소와 밀접하게 관련되어 있습니다.
서비스 메시: 마이크로서비스의 네트워크 통신 인프라
이제 서비스 메시가 어떻게 다른지 살펴보겠습니다.
서비스 메시는 애플리케이션 계층의 네트워크 통신 기능을 서비스 코드에서 분리하는 데 사용할 수 있는 네트워크 통신 인프라입니다.
서비스 메시를 사용하면 서비스 코드에서 회로 차단기, 타임아웃과 같은 신뢰할 수 있는 통신 패턴을 구현할 필요가 없으며, 이와 유사하게 서비스 메시도 서비스 디스커버리, 서비스 가시성 등 다른 기능을 제공합니다.
API 게이트웨이와 서비스 메시의 실제 적용
API 게이트웨이와 서비스 메시의 주요 차이점은 API 게이트웨이가 API/경계 서비스를 노출하는 핵심 구성 요소인 반면, 서비스 메시는 단순히 서비스 간 통신 인프라일 뿐이며 애플리케이션의 비즈니스 로직을 알지 못한다는 것입니다.
아래 그림은 API 게이트웨이와 서비스 메시의 관계를 보여줍니다. 앞서 언급했듯이, 이 둘 사이에는 일부 중복되는 부분(예: 회로 차단기 등)이 있지만, 이 둘이 완전히 다른 용도로 사용된다는 것을 이해하는 것이 중요합니다.
그림 1: API 게이트웨이와 서비스 메시의 실제 적용
위 그림에서 볼 수 있듯이, 서비스 메시는 사이드카(Sidecar)로 서비스와 함께 배포되며, 서비스의 비즈니스 로직과는 독립적입니다.
반면에 API 게이트웨이는 모든 API 서비스(이러한 API 서비스는 명확하게 정의된 비즈니스 기능을 가짐)를 제공하며, 이는 애플리케이션 비즈니스 로직의 일부입니다. API 게이트웨이는 내장된 서비스 간 통신 기능을 가질 수 있지만, 하위 서비스를 호출하기 위해 서비스 메시를 사용할 수도 있습니다 (API 게이트웨이 -> 서비스 메시 -> 마이크로서비스).
API 관리 계층에서는 API 게이트웨이의 내장된 서비스 간 통신 기능을 사용할 수도 있고, 애플리케이션 네트워크 통신 기능을 애플리케이션에서 서비스 메시로 이전하기 위해 서비스 메시를 통해 하위 서비스를 호출할 수도 있습니다.
번역자 주
API 게이트웨이와 서비스 메시의 관계는 제가 최근에 계속 고민해왔던 문제이며, 동료 및 커뮤니티 친구들과도 몇 차례 논의했습니다. 이 짧은 글은 둘 사이의 유사점과 마이크로서비스 아키텍처에서 이 둘의 다른 용도를 명확하게 요약합니다.
이 글에서는 “API 게이트웨이의 내장된 서비스 간 통신 기능을 사용할 수도 있고, 서비스 메시를 통해 하위 서비스를 호출할 수도 있다"고 언급했습니다. 동료들과 논의할 때, API 게이트웨이에 사이드카를 도입할 경우 발생할 수 있는 추가 지연이 중요한 고려 사항으로 언급되었습니다.
API 게이트웨이는 마이크로서비스 참조의 트래픽 진입점으로서 효율성에 대한 요구 사항이 높습니다. 만약 API 게이트웨이와 함께 사이드카를 배포한다면 효율성에 어느 정도 영향을 미칠 수 있습니다.
저는 이에 대한 테스트를 수행하지 않았지만, 이론적으로 서비스 디스커버리, 재시도, 회로 차단 등 로직은 API 게이트웨이에 있든 서비스 메시 안에 있든 소요 시간은 비슷할 것입니다. 사이드카를 배포하는 것은 단순히 로컬 연결을 생성하는 데 드는 추가 비용만 발생시킵니다. 아래 그림과 같습니다:
API 게이트웨이와 서비스 메시의 기능을 명확하게 분리하여, API 게이트웨이는 애플리케이션 로직을 담당하고 서비스 메시는 서비스 통신, 메트릭 수집 등 마이크로서비스 인프라를 담당하도록 하면 아키텍처적으로 더욱 명확해집니다. 효율성 문제는 API 게이트웨이를 수평 확장하여 해결할 수 있습니다.
원문
이 번역문은 원저자의 동의를 얻어 게시되었으며, 원문은 Service Mesh vs API Gateway에서 확인할 수 있습니다.
