[MSA] Service Mesh란

출처: https://www.redhat.com/cms/managed-files/service-mesh-1680.png

기존의 Monolithic 방식에서 MSA로 전환되면서 독립성, 확장성과 같은 많은 이점을 얻었다.

하지만, MSA를 적용하며 겪는 단점도 존재한다.

• 서비스가 분산되어 있어, 서비스 간 통신에 복잡성 증가
• 장애 추적 및 모니터링에 대한 어려움
• Service Discovery : callee 서비스의 논리적, 물리적 위치가 변경되었을 때 caller에서 찾는데 어려움
• Circuit breaking : callee 서비스의 문제가 있을 때, caller 서비스에 해당 장애가 전파되지 않도록 하기 위한 추가적인 노력 필요 

이러한 단점들을 극복하기 위해서는 MSA 서비스들은 서비스 간 커뮤니케이션을 통제하는 추가적인 로직이 필요하게 된다.

이러한 작업들을 각각의 서비스에 중복으로 넣지 않고 인프라에서 해당 작업을 할 수 있게 하는 것이 Service Mesh이다. 

 

Service Mesh

서비스 간 모든 통신을 처리하는 인프라 계층

애플리케이션 계층이 아닌 인프라 플랫폼 계층에 특정 모듈을 삽입하여 애플리케이션에 대한 다양한 추가 기능을 제공

(라우팅, 보안, 안정성, 관측성..)

 

이러한 기능을 제공하기 위해서 Service Mesh는 애플리케이션 앞에 Proxy를 둔다.

보통 이 Proxy를 Sidecar Proxy라고 부른다. 

 

Proxy

일반적인 MSA 환경에서 아래와 같은 서비스와 서비스 간에 호출이 있을 경우

service mesh의 경우에는 각 서비스마다 proxy가 존재한다.

• 서비스로 들어오거나 나가는 모든 트래픽에 대한 통제가 가능해진다

 

다만, MSA 환경에서는 수 없이 많은 서비스들이 존재하는데, 각각의 서비스들의 호출에 대한 proxy 설정을 개별적으로 해주기는 어렵다.

이러한 문제를 해결하기 위해서, 각 proxy에 대한 설정 정보를 중앙 집중화된 컨트롤러가 통제하는 구조를 취할 수 있다.

이를 Control Plane이라고 부른다. 

 

Benefits of a service mesh

service mesh를 이용하면 아래와 같은 이점을 얻을 수 있다.

각각에 대한 자세한 설정은 추후 차근차근 학습해 볼 예정이다. 

 

• Service discovery
• Application health monitoring
• Load balancing
• Automatic failover
• Traffic management
• Encryption
• Observability and traceability
• Authentication and authorization
• Network automation