[개요]
Service Mesh 아키텍쳐는 MicroService 아키텍쳐와 더불어 활발하게 언급되고 있는 아키텍쳐이다.
왜 Service Mesh 아키텍쳐가 무엇인지 그리고 왜 활발하게 언급되고있는지, 구현체인 Istio에 대해서도 정리한다.
[Service Mesh?]
- 마이크로서비스 구조를 띄는 시스템의 통신이 Mesh 네트워크의 형태를 띄는 것에 빗대어 Service Mesh로 명명되었다고 한다.
- 애플리케이션 계층이 아닌 인프라 플랫폼 계층에 특정 모듈을 삽입하여 애플리케이션에 대한 라우팅, 보안 등의 기능을 추가하는 것.
- 마이크로서비스에서 각 서비스들이 상호 통신을 할 때 코딩수준에서 통신방법을 정의해서 사용하는 방식을 많이 사용하였다. 하지만 통신이 복잡해지기 시작하면 이처럼 직접 구현하는 것이 점점 복잡해지는 한계가 있었고, 이를 극복하기 위해 통신방식을 개별 서비스에서 구현하는 방식이 아닌 인프라 계층으로 추상화하는 방법이 나타나게 되었다.
ServiceMesh가 없는 마이크로서비스는 서비스 간의 통신 방법과 로직을 직접 코딩해야하기 때문에 집중해야할 비즈니스 로직에 집중하지 못하게되고, 통신과 관련된 코드가 서비스 내부에 있어서 디버깅하기도 쉽지 않다.
예를 들어, Circuit Breaker기능을 Hystrix Resilience4j를 App수준에서 구현할 수도 있지만, 이럴 경우 Application에 종속성이 생기고, 변경이 일어나는 경우마다 비용이 발생한다.
이 상태에서 서비스들간의 통신이 늘어날수록 커뮤니케이션을 정리하기가 점점 더 복잡해지는 문제를 갖게 된다.
결국 마이크로서비스를 운영할 때에는 별도의 소스코드 수정이 없이 인프라레벨에서 이러한 것들을 관리해주는 역할을 하는 Service Mesh가 필요하다.
[Service Mesh를 왜 적용해야 할까?]
마이크로서비스는 기존의 모놀리틱 아키텍쳐의 단점을 극복하고 클라우드 환경에서 시스템을 운영할때의 이점을 극대화하기위해 많이 사용되고 있는 구조이다.
이를 통해 기존 서비스들의 많은 문제가 해결되었지만 새로운 문제가 발생하기도 했다. 그것은 시스템의 '런타임 복잡성'이다.
기존의 strace, tcpdump를 마이크로 서비스에서 사용하기에는 너무 '둔하다'.
마이크로 서비스는 수많은 수의 서비스로 구성되는데, 여기서 일일이 tcmdump를 실행하기에는 너무 힘들고 어렵다.
[API Gateway와의 차이]
API Gateway는 기본적으로 외부에서 들어오는 트래픽에 대한 제어를 담당.
Service Mesh는 서비스 내부 통신에 대한 제어를 담당.
MSA구조에서 API Gateway는 외부에 노출되는 External 영역에 위치하고, Service Mesh는 Internal 영역에서 서비스간 통신을 제어하는 구조로 많이 사용한다고 한다.
[Service Mesh의 동작방식]
Service Mesh는 네트워크 프록시 배열로 앱에 구축된다. 이러한 프록시들은 마이크로서비스 내부에서 실행되는 것이 아니라 'sidecar' 형태로 수행되고, 이러한 프록시들이모여 메시네트워크를 형성하게 된다.
Sidecar Pattern
클라우드 디자인 패턴의 일종.
Pod을 구동할 때 App 컨테이너외에 네트워크 트래픽만을 위한 추가적인 컨테이너를 함께 배포한다. 이 상황에서 A서비스에서 B서비스를 호출하는 경우 서비스가 직접 서비스를 호출하는 것이 아니라 Proxy를 통해서 호출하게 된다.
이를 통해 대규모의 마이크로 서비스 환경에서도 개발자가 별도의 작업 없이 서비스간 연결 뿐아니라 로깅, 모니터링, 트래픽 제어와 같은 이점을 누릴 수 있다.
Service Mesh를 구성할 때 가장 추천되는 방식이라고 한다.
ex) Istio, Consul, Linkerd
[Service Mesh의 장단점]
장점
- 마이크로 서비스에서 발생하는 런타임 복잡성 이슈를 해소해준다.
- 서비스들 간에 발생하는 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡쳐하여 준다.
- 개발자들은 서비스간의 커뮤니케이션에 신경쓰지 않고, 비즈니스 로직 구현에 좀 더 집중할 수 있다.
- Jaeger와 같은 분산 추적 시스템을 통해 서비스와 함께 한 눈에 보이는 인프라를 구축할 수 있어서 관리 편의성이 늘어나게 된다.
- 장애가 발생한 서비스로부터의 요청을 다시 라우팅할 수 있기 때문에 다운타임이 발생 시 애플리케이션 복구 능력을 향상시켜줄 수 있다.
단점
- 시스템의 런타임 인스턴스 수가 증가한다. (최소 2배. sidecar container가 하나씩 더 붙으므로)
- 서비스 간 통신에 네트워크 레이어가 추가된다.
- 신기술이다
[Service Mesh의 주요기능]
- Service Discovery
- Load Balancing
- Dynamic Request Routing
- Circuit Breaking
- 암호화 (TLS)
- 보안
- Health Check, Retry and timeout
- Metric 수집
- Access Control
- A/B Testing
[결론]
- Service Mesh는 마이크로서비스가 유발하는 새로운 문제점을 보완하는 인프라 수준의 아키텍쳐
- 서비스마다 Proxy가 sidecar 형태로 구현됨
- 비즈니스로직과 공통기능을 분리하여 소스코드 재배포없이 기능 제어를 할 수 있음.
- 서비스간 통신에 추가적인 레이어가 발생함
- 아직까지 신기술로 평가받고 있고, 안정화에는 좀 더 시간이 필요할 수 있다.
[참조]
[Service Mesh]서비스 메시란? (tistory.com)
MSA 제대로 이해하기 -(4)Service Mesh (velog.io)
서비스 메시(Service Mesh)란? + API Gateway와 차이점 :: 매일매일 꾸준히 (tistory.com)
'Kubernetes' 카테고리의 다른 글
Istio (0) | 2023.01.31 |
---|---|
Service란? (0) | 2022.12.06 |
ConfigMap이란? (0) | 2022.12.06 |
Kubernetes Ingress? (0) | 2022.11.02 |