서비스 매시 아키텍처(Service Mesh Architecture)

서비스 매시?

서비스 매시(Service Mesh)란 MSA(Micro Service Architecture)를 적용한 시스템의 내부 통신이 매시(Mesh) 네트워크 형태를 띄는것에 빗대어 서비스 매시라 부르게 되었고, 어플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법입니다. 서비스 간 커뮤니케이션을 관리하는 다른 시스템들과 달리, 서비스 매시는 어플리케이션에 구축된 전용 인프라 계층이며 가시적입니다. 이 인프라 계층은 서로 다른 어플리케이션이 얼마나 원활하게 상호작용하는지를 기록하며, 더욱 손쉽게 커뮤니케이션을 최적화 시킬 수 있는 기능을 제공합니다.

 

서비스 매시 아키텍처의 필요성

MSA는 기존의 모놀리식 아키텍처(Monolithic Architecture)의 단점 극복, 클라우드 환경에서 시스템을 운영할 때의 이점을 극대화 하기 위해 사용됩니다. MSA의 사용으로 모놀리식 아키텍처의 많은 문제점이 해결되었지만, 또 다른 문제점도 발생했습니다. 하나의 어플리케이션에서 동작하는 모놀리식 아키텍처와 달리 대규모 서비스에 적용되는 MSA 의 특성상 나뉘어진 서비스와 인스턴스 수만큼 관리해야 하는 대상이 급격히 증가합니다. 또한 서비스간 복잡한 연결구조로 인하여 장애 경로 추적이 어렵고, 장애가 발생한 서비스로 인해 타 서비스를 호출하는 로직이 수행되지 않아 결과적으로 다른 서비스도 동작하지 않는 장애 전파 현상이 발생하게 됩니다.

이런 문제를 해결하기 위해 서비스 매시 아키텍처에서는 서비스 간 직접적인 호출 대신에 서비스 앞단의 경량화된 프록시를 사이드카(side-car) 패턴으로 배치합니다. 이렇게 배치된 프록시를 통해 네트워크를 제어하고 추적하여 안정성, 신뢰성, 가시성, 보안성 등을 확보합니다.

(** 사이드 카(Side-Car) 패턴 : 사이드카 패턴은 클라우드 디자인 패턴의 일종으로, 기본 어플리케이션 외에 필요한 추가 기능을 별도의 어플리케이션으로 구현하고 이를 동일한 서비스 또는 컨테이너 내부에 배치하는 것을 말합니다.)

 

주요 구성

1. 프록시(Proxy)

기존 마이크로 서비스에서는 각 서비스간 직접적인 호출을 통해 통신했지만, 서비스 매시 아키텍처에서는 서비스 앞단의 프록시를 두어 이를 통해 서비스간 통신을 하게 됩니다.

 

   

[그림] 서비스 호출 방식의 차이 (마이크로 서비스 vs 서비스 매시)

 

2.  구조

이렇게 마이크로 서비스에 대한 문제를 해결하기 위해 배치된 프록시는 각각의 서비스 마다 필요하기 때문에 한 두개가 아닌 수 백, 수 천의 서비스 앞단에 구성됩니다. 마이크로 서비스의 늘어난 인스턴스의 관리 문제와 동일하게 프록시 까지 관리해야 하기때문에 이 프록시에 대한 설정과 관리를 위한 방법으로 각 프록시에 대한 정보를 모아 관리하고 컨트롤하는 통제 구조를 가지게 되었습니다.

 

[그림] 서비스 매시 아키텍처

 

각 프록시를 통해 설정된 값에 따라 트래픽을 컨트롤 하는 부분을 데이터 플레인(Data Plane)이라 하고, 데이터 플레인의 설정 값들을 저장하고 전달하는 컨트롤러 역할을 하는 부분을 컨트롤 플레인(Control Plane)이라고 합니다.

 

구글에서는 Istio라는 솔루션을 통해 서비스 매시를 적용할 수 있게 하고 있습니다. 더 자세한 정보는 https://istio.io/를 참고하시면 됩니다.