서비스 메쉬, 데이터 플레인, 컨트롤 플레인 뜻
최근 k8s와 istio에 대해 조사하면서 새로운 용어들을 만나게 되었다.
구현체에 너무 얽매이지 않도록 주의하면서 개념을 정리해 보자.
Service Mesh
서비스 메쉬란 한 애플리케이션의 다양한 부분들이 통신하는 것을 제어하는 방법이다. 한 애플리케이션 안에서 여러 서비스들이 서로 통신하며 데이터를 주고받는 것을 서비스의 소스코드와 상관없이 제어하는 것이다.
MSA =! Service Mesh |
MSA는 그러면 서비스 메쉬인가? 아니다. MSA는 애플리케이션 구조에 대한 개념이다.
서비스 메쉬는 애플리케이션을 구성하는 여러 서비스들의 내부 통신을 어떻게 제어할 것인가에 대한 이야기다.
근데 MSA는 당연히 내부 서비스들끼리 http를 비롯하여 다양한 프로토콜로 서로 소통하니까
서비스 메쉬까지 항상 포함하는 것 아닐까?
답은 "아니오"다. 서비스 메쉬의 요점은 추상화다.
각 서비스에 소통을 위한 로직을 직접 코딩할 수도 있을 것이다.
(이런 방식은 서비스 개수가 늘어날수록, 커뮤니케이션이 복잡해질수록 비효율적이다.)
MSA가 항상 서비스 메쉬라는 레이어를 항상 포함하는 것은 아니다.
서비스 메쉬는 추상화된 계층에서 개별 서비스 간의 소통 규칙을 관리한다.
그러면 어떻게 통제할 것인가? 서비스로 요청이 직접 가는 것이 아니라, 네트워크 프록시가 요청을 받아서 라우팅한다.
각각의 네트워크 프록시는 서비스 내부에 들어있는 게 아니라 서비스와 별개로 외부에 존재한다.
네트워크 프록시는 서비스와 함께 실행되기 때문에 사이드카라고도 한다.
서비스 입장에서는 전체 네트워크에 대해서 알지 못한다. 정확히는, 서비스 입장에서 전체 네트워크는 관심사가 아니다.
A라는 서비스는 B라는 서비스의 url이 뭔지, ip가 뭔지 등 관심이 없다.
로컬 프록시인 자신의 사이드카에 대해 인지하고 있으며,
모든 요청들은 사이드카가 라우팅한다. 사이드카만 바라보고 있으면, 다른 서비스들과 소통하는데 아무런 문제가 없다.
서비스 간의 통신을 추상화해서 관리하면, 서비스 코드에 커뮤니케이션에 대한 로직을 넣을 필요가 없다.
서비스 메쉬를 이용하면 서비스 본연의 목표에 좀 더 집중해서 개발할 수 있고,
커뮤니케이션 장애가 발생했을 때도 수월하게 조사할 수 있다.
예를 들어, A 서비스가 B 서비스로 요청을 하는데 에러가 발생할 경우,
요청을 재시도했을 때 성공하기까지의 시간 같은 데이터를 수집할 수 있다.
Data Plane
서비스 간 네트워크 트래픽을 관리하는 서비스 메쉬 애플리케이션을 데이터 플레인이라고 한다.
쉽게 생각하면 사이드카(정확히는 로컬 프록시들의 모음)가 곧 데이터플레인인 것이다.
데이터 플레인은 다음과 같은 다양한 기능들을 한다.
- 서비스 디스커버리: 어떤 서비스 인스턴스가 다른 서비스와 커뮤니케이션해야할 때,
살아있고(healthy) 사용 가능한 인스턴스를 찾아야 한다.
네트워크 안에서 자동으로 필요한 서비스를 찾는 것을 서비스 디스커버리라고 한다.
자세한 내용은 아래 링크 참고.
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
- 로드 밸런싱
- 헬스 체크
- 라우팅
- 인증과 인가
- 로깅
Control Plane
그럼 데이터 플레인은 앞서 언급한 다양한 기능들을 어떻게 수행하는가?
누구를 인증해주고, 특정 요청을 어느 서비스로 넘겨줘야되는지 어떻게 아는가?
프로그래머는 데이터 플레인이 어떻게 동작할지 컨트롤 플레인을 통해 설정한다.
일반적으로 컨트롤 플레인은 데이터 플레인을 관리하기 위한 API, CLI를 포함하며 GUI를 지원하기도 한다.
논리적으로 정리하면 깔끔한데, 구현체에 집착하게 되면 도리어 헷갈리는 것 같다.
참고 링크들)