이 연재글은 Service Mesh Architecture의 1번째 글입니다.

Service Mesh Architecture

서비스 메시(Service Mesh)란?

서비스 메시는 서비스 간의 통신을 제어하고 표시하고 관리할 수 있도록 하는 데 특화된 마이크로 서비스를 위한 인프라 계층입니다. 기존의 서비스 아키텍처에서의 호출이 직접 호출 방식이었다면, 서비스 메시에서의 호출은 자체 인프라 계층의 proxy를 통해 이뤄지게 됩니다.

서비스 메시를 구성하는 개별 proxy는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 ‘sidecar’라고도 합니다. 각 서비스에서 분리된 이러한 sidecar proxy들이 모여 Mesh Network를 형성합니다.

Mesh Network

마이크로 서비스의 단점

서비스 메시 없이 동작하는 마이크로 서비스는 서비스 간 커뮤니케이션을 통제하는 로직으로 코딩해야 하기 때문에 개발자들이 비즈니스 로직에 집중하지 못하게 됩니다.
또한 서비스 간 커뮤니케이션을 통제하는 로직이 각 서비스 내부에 숨겨져 있기 때문에 커뮤니케이션 장애를 진단하기가 더 어려워집니다.

거대해진 MSA시스템은 수십개의 MicroService가 분리되어있고 운영환경에는 수천개의 서비스 인스턴스가 동작하고 있으며 서비스간의 통신도 매우 복잡하여 새로운 장애 지점이 계속해서 나타나게 됩니다. 이러한 복잡한 마이크로서비스 아키텍처 내에서 서비스 메시 없이는 문제가 발생한 지점을 찾아내기가 거의 불가능합니다.

서비스 메시로 얻는 이점

서비스 메시는 서비스 간 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡처하게 되며 서비스 메시를 활용하면 다음 내용을 실현할 수 있습니다.

  • 개발자들이 서비스 간의 안정적인 연동에 집중하는 대신 대신 비즈니스 가치를 추구하는 일에 좀 더 집중할 수 있습니다.
  • Jaeger를 통한 요청의 분산 추적은 서비스와 함께 가시적인 인프라 계층을 제공하므로 문제를 손쉽게 인식하고 진단할 수 있습니다.
  • 서비스 메시는 장애가 발생한 서비스로부터 요청을 재 라우팅 할 수 있기 때문에 다운 타임 발생 시 애플리케이션 복구 능력이 향상됩니다.
  • 성능 메트릭을 통해 런타임 환경에서 커뮤니케이션을 최적화하는 방법을 제안할 수 있습니다.

서비스 메시 주요 기능

  • 요청 라우팅 제어
  • 계단식 장애 방지 (서킷브레이크)
  • 부하 분산 알고리즘(로드밸런싱)
  • 보안 기능 (TLS, 암호화, 인증 및 권한 부여)
  • 서비스 간 계층에서 계측 정보를 제공하는 메트릭

서비스 메시 구조

기존의 서비스 아키텍처에서의 호출이 직접 호출 방식이었다면, Service Mesh에서의 호출은 서비스에 딸린 proxy끼리 이뤄지게 됩니다. 이는 서비스의 트래픽을 네트워크단에서 통제할 수 있게 하고, 또한 Client의 요구에 따라 proxy단에서 라우팅 서비스도 가능하게 할 수 있습니다.

이런 다양한 기능을 수행하려면 기존 TCP 기반의 proxy로는 한계가 있습니다. Service Mesh에서의 통신은 사이드카로 배치된 경량화되고 L7 계층 기반의 proxy를 사용하게 됩니다.

Control Plain과 Data Plain

서비스 메시는 Control Plain과 Data Plain으로 구성되어 있습니다.

Control Plain

Control Plain은 트래픽을 제어하는 정책 및 구성에 따라 proxy에게 설정값을 전달하고 관리하는 컨트롤러 역할을 합니다. 

Data Plain

Data Plain은 Proxy를 통해 마이크로 서비스 간에 오고 가는 모든 네트워크 통신을 조정하고 제어합니다. Service discovery, Load balancing, TLS termination, Circuit breaker 등의 기능을 제공하며 가장 인기 있는 Data Plain인 Envoy proxy가 많이 사용됩니다.

Envoy Proxy

Data Plain에서 사용되는 Envoy는 C++로 개발된 고성능 프록시이며 아래와 같은 기능을 수행합니다.

  • Dynamic service discovery
  • Load balancing
  • TLS termination
  • HTTP/2 and gRPC proxies
  • Circuit breakers
  • Health checks
  • Staged rollouts with %-based traffic split
  • Fault injection
  • Rich metrics

API Gateway vs Service Mesh

두 서비스 모두 서비스 검색, 요청 라우팅, 인증, 속도 제한 및 모니터링을 모두 처리할 수 있지만 적용되는 위치와 아키텍쳐 형태등에 차이가 있습니다.

적용되는 위치
API Gateway는 마이크로서비스 그룹의 외부 경계에 위치하여 역할을 수행하지만, ServiceMesh는 경계 내부에서 그 역할을 수행합니다. API Gateway의 주요 목적은 네트워크 외부의 트래픽을 수락하고 내부적으로 배포하는 것입니다. 서비스 메시의 주요 목적은 네트워크 내부에서 트래픽을 라우팅하고 관리하는 것입니다.

아키텍쳐 형태
API Gateway가 중앙집중형 아키텍쳐여서 SPOF(Single Point of Failure)을 생성한다면, Service Mesh는 분산형 아키텍쳐를 취하기 때문에 SPOF를 생성하지 않고 확장이 용이합니다.

패턴
API Gateway는 일반적으로 Gateway proxy pattern을 사용해서 수행됩니다. Consumer(호출자)은 구현 내용을 알 필요 없이 Gateway를 호출하는 방법만 알면 Gateway가 알아서 수행해주는 방식입니다. 반면 Service Mesh는 일반적으로 Sidecar proxy pattern을 사용합니다. Consumer(호출자)의 코드에는 Provider(공급자)의 주소를 찾는방법, failover와 관련된 코드 등의 내용이 들어가게 됩니다. 다만, 호출자의 코드는 어플리케이션 코드(비즈니스 로직)에 내장되는 것이 아니라 sidecar 형태로 별개로 관리됩니다.

둘다 필요한가?

Service Mesh와 API Gateway는 함께 작동하여 외부 트래픽을 효율적으로 수락 한 다음 해당 트래픽이 네트워크에 있으면 효과적으로 라우팅 할 수 있습니다. API 게이트웨이와 서비스 메시가 있는 배포에서 클러스터 외부에서 들어오는 트래픽은 먼저 API 게이트웨이를 통해 라우팅 된 다음 메시로 라우팅 됩니다. API 게이트웨이는 인증, 에지 라우팅 및 기타 에지 기능을 처리할 수 있으며 서비스 메시는 아키텍처에 대한 세밀한 관찰 및 제어를 제공할 수 있습니다.

향후 전망

서비스 메시 기술은 빠르게 발전하고 있으며 API 게이트웨이의 일부 기능을 수행하기 시작했습니다. 클라우드 네이티브 공간이 발전하고 더 많은 조직이 Docker 및 Kubernetes를 사용하여 마이크로 서비스 아키텍처를 관리하는 방식으로 이동함에 따라 서비스 메시와 API 게이트웨이 기능이 병합될 가능성이 높습니다. 앞으로 몇 년 안에는 독립형 API 게이트웨이의 많은 기능이 서비스 메시에 흡수되어 점점 더 적게 사용될 것으로 예측됩니다.

Istio vs AWS App Mesh

Istio

ISTIO 는 한동안 서비스 메시 분야에서 주요 역할을 해왔으며 Envoy를 데이터 플레인으로 래핑 한다는 점에서 AWS App Mesh와 유사점을 공유합니다. 두 가지 모두 마이크로 서비스 간의 트래픽 흐름을 모니터링하고 제어할 수 있도록 하는 유사한 요구 사항을 가지고 있습니다. 또한 Istio는 오픈 소스이며 공급 업체에 구애받지 않으며 AWS App Mesh보다 훨씬 오랫동안 사용되어 왔으므로 현재 더 많은 기능을 제공하고 다양한 플랫폼을 지원합니다.

AWS App Mesh

AWS가 제공하는 자체 서비스 메시입니다. AWS App Mesh는 ECS, EKS 및 EC2에서 구동되는 Kubernetes 환경 하의 마이크로 서비스 애플리케이션에서 통신을 모니터링하고 제어하는 ​​데 사용할 수 있습니다.

App Mesh는 현재 Envoy를 사용하므로 마이크로 서비스 모니터링을 위해 다른 오픈 소스 및 AWS 파트너 도구와 호환됩니다. 수집되는 데이터는 AWS X-Ray, Amazon CloudWatch 및 Envoy와 통합되는 타사 모니터링 및 추적 도구를 비롯한 다양한 AWS 및 타사 도구로 내보낼 수 있습니다. 서비스에 대한 블루 / 그린 카나리아 배포를 활성화하도록 새로운 트래픽 라우팅 제어를 구성할 수 있습니다.

또한 ECS / EKS / EC2 등에서 이미 사용하고 있는 컴퓨팅 리소스 외에는 App Mesh에 대한 추가 가격이 없습니다.

AWS는 거대한 엔지니어링 리소스를 처리할 뿐만 아니라 대규모 엔지니어링 커뮤니티 내에서 널리 보급되어 있으므로 현재 일부 기능이 부족함에도 불구하고 Istio를 대체할 것으로 예상됩니다.

BenchMark

Service Mesh를 적용할 경우 각각의 서비스가 sidecar proxy를 통해 통신하므로 성능에 문제가 있는지 체크하기 위해 테스트를 진행하였습니다.

EKS Worker Node 사양 : EC2 t3.medium ( 2cpu, 4G memory )
Demo로 제공되는 Sample 페이지 호출( yelb )하여 TPS 측정
LoadBalancer, ISTIO, AWS App Mesh를 사용해서 서비스했을때의 성능 비교

결과부터 이야기하면 Service mesh 적용 전 후의 처리 성능에 대해서는 유의미한 차이를 발견하기 어려웠습니다.

LoadBalancer

ISTIO

AWS App Mesh

[참고]

연재글 이동
[다음글] Istio Service Mesh

RELATED ARTICLESMORE FROM AUTHOR