이전 글에서 서비스 메시에 대해서 간략히 언급했었습니다. 서비스 메시가 무엇인지 아직 모르시는 분은 링크 를 통해 읽어보세요.
본 글에서는 서비스 메시의 아키텍처 스타일에 대해서 얘기하고자 합니다.
우리가 이미 알고 있는 방법일 수 도 있습니다.
- Library 방식: 라이브러리로 필요 기능들이 제공되며, 애플리케이션의 코드 레벨로 사용되어야 합니다. (어찌 보면, 서비스 메시라고 할 순 없지만 서비스 메시를 구현하기 위한 대안? 으로 이해하시면 될 것 같습니다.)
- Node Agent 방식: Node Agent나 Daemon에 의해서 기능들이 제공됩니다.
- Sidecar 방식: 컨테이너내에 sidecar로 proxy가 적용되어 기능들이 제공됩니다.
이제 각각의 아키텍처 스타일에 대해 상세히 살펴 볼까요?
타입별 Service Mesh Architectures
Library Architecture
라이브러리를 이용하게 되면 위의 그림에서 표현했듯이 각 마이크로 서비스 애플리케이션에 서비스 메시 기능을 구현하는 라이브러리 코드가 포함됩니다. (e.g. Hystrix, Ribbon)
이 기능은 서비스내에서 독점적으로 하나의 프로그래밍 언어만 사용하는 경우에 적합합니다. 라이브러리로 접근하게 되면 인프라 환경에 크게 영향을 받지 않습니다.
하지만, 대부분은 Polyglot 형태로 마이크로 서비스를 실행하고 있습니다. 이 경우 사용하는 프로그래밍 언어마다 라이브러리가 존재해야 합니다. 따라서 라이브러리 방식을 채택할 경우에는 제약이 존재합니다.
Node Agent Architecture
라이브러리 아키텍처 이후에 나온 대안입니다. 모든 노드에서 실행되는 별도의 Agent가 존재하며, 이 기종간 쉽게 혼합될 수 있는 이점을 제공합니다.
모든 노드에 하나의 노드 에이전트가 필요하기에 이 아키텍처를 채택하기 위해서는 인프라와 협업이 필요합니다. 즉, 운영체제에 TCP 패킷을 보내거나 받을 수 있도록 역할을 위임합니다.
공유를 한다는 것은 리소스 차원에서 효율적으로 보일 수 있지만, 여러개의 마이크로 서비스가 하나의 노드를 공유하는 모델이기 때문에, 선점에 대한 문제가 있을 수 있습니다. 예를 들어서 노드에 속해 있는 모든 마이크로 서비스가 노드 에이전트에 요청을 하면 노드 에이전트는 먼저 요청한 마이크로 서비스의 업무를 처리해야 합니다. 효율적으로 리소스를 공유할 수 있다면, 나쁘지 않은 방법이라고 생각합니다.
사이드카는 가장 마지막에 나온 아키텍처입니다. Istio가 Envoy와 함께 사용되는 모델입니다. 서비스 메시의 경우 사이드카는 애플리케이션 안팎의 모든 네트워크 트래픽을 처리합니다.
이 접근법은 지금까지 설명한 라이브러리와 노드 에이전트 접근법 사이에 존재합니다. 예를 들어서, 모든 노드에서 새 에이전트를 실행하지 않고도 사이드카 서비스 메시를 배포할 수 있습니다. (사이드카에 대한 내용은 이전 포스팅에서 설명했습니다.) 노드 에이전트와는 달리 각 Pod에 배포가 되기에 더 많은 리소스가 필요합니다만, 개인적인 관점에서는 얻는 이득이 더 크다고 생각됩니다.
어떤 방식을 채택하는 것이 효율적일까요? 여러 상황들을 고려하여 적합한 방식을 선택해보세요.
다음 포스팅에서는 각 아키텍처 타입별 오픈소스/상용 솔루션에 대해서 이야기 하도록 하겠습니다.
