서비스 메시란? 서비스 간의 통신을 제어하고 표시하고 관리할 수 있도록 하는데 특화된 마이크로 서비스를 위한 인프라 계층
MSA의 단점 서비스가 분산이 되서 이점도 많이 생겼지만 그만큼 단점도 많이 생김. 복잡해진 MSA시스템을 보면 수십개의 마이크로서비스가 분리되어있고 운영환경에는 수천개의 서비스 인스턴스가 동작하고 있음. 이에 따라 중앙로그수집, 분산트랜잭션 추적, 중복인증처리 등의 문제가 생기게 됨 그만큼 모니터링도 힘들어짐
• 결국 긴박한 장애상황에 덤프를 떠서 분석을 하는 것은 시간이 많이 걸림.
• 마이크로서비스팀이 사용하는 프레임워크가 다 다르고 네트워크 설정이 다 다름.
• 어떤 서비스가 문제인지 원인구간을 특정하는 시간이 오래걸림
• 서비스별 모니터링 도구도 다르고 로깅 정책도 다름
그래서 나온 것이?
서비스메시 아키텍처
기존의 서비스 아키텍처에서의 호출이 직접 호출방식에서 어플리케이션마다 추가된 proxy 사이드카로 통신을 하도록 만듬
서비스의 트래픽을 네트워크단에서 통제할 수 있게 하고, 또한 Client의 요구에 따라 proxy단에서 라우팅 설정도 가능
이런 다양한 기능을 수행하려면 기존 TCP기반의 proxy로는 한계가 있음
그래서 Service Mesh에서의 통신은 사이드카로 배치된 경량화되고 L7계층기반의 proxy를 사용하게 됩니다.
프록시를 사용해서 트래픽을 통제할 수 있다는 것 까지는 좋은데, 서비스가 거대해짐에 따라 프록시 수도 증가
이런 문제를 해결하기 위해서 각 프록시에 대한 설정정보를 중앙집중화된 컨트롤러(컨트롤플레인)가 통제할 수 있게 설계.
-
프록시 사이드카
- 해당 어플리케이션 전용 프록시를 파드마다 컨테이너로 띄워줌
- 전용 프록시에 일관된 메트릭 처리와 일관된 정책관리가 가능함
-
컨트롤플레인: 프록시들에 설정값을 전달하고 관리하는 컨트롤러 역할
-
데이터 플레인: 프록시들로 이루어져 트래픽을 설정값에 따라 컨트롤하는 역할
다음 글에서는 서비스 메시 구현체인 Istio에 대해서 알아보자
