[Service Mesh]서비스 메시란?

서비스 메시(Service Mesh)란 무엇일까?

---

개요

  Istio에 관해 알아보던 중, Service Mesh라는 용어가 나와 이 용어가 의미하는 바를 알아보고 이해한다.

 

목차

• 서비스 메시(Service Mesh)란?
• 마이크로서비스(MicroService)와의 차이점
• 서비스 메시(Service Mesh)는 어떻게 동작하는가?
• 서비스 메시(Service Mesh)의 이점

 

소개

 1. 서비스 메시(Service Mesh)란? 

서비스 메시(Service Mesh)의 정의

  서비스 메시란 애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법이다. 서비스 메시는 각 서비스(애플리케이션의 각 부분)에서 서비스간에 커뮤니케이션을 관리해야하는 다른 시스템과는 다르게 애플리케이션에 구축된 전용 인프라 계층을 통해, 서로 다른 애플리케이션이 얼마나 원활하게 상호작용하는지를 기록 할 수 있어, 더욱 손쉽게 어플리케이션 간의 커뮤니케이션을 활성화 하고, 애플리케이션이 확장됨에 따라 발생하는 커뮤니케이션의 복잡함을 해소시켜 다운 타임을 방지 할 수 있도록 해준다.

 

언제 서비스 메시(Service Mesh)를 도입할까?

  현대의 애플리케이션은 각 서비스들이 다른 서비스 및 데이터베이스와 상호작용하며 데이터를 주고받는다. 이러한 상호작용은 특정한 비즈니스 기능들을 수행하는 서비스 네트워크로 분류 할 수 있는데, 이러한 네트워크 속에서 데이터들은 여러 서비스들로부터 데이터를 요청을 주고받게 되는 것이다. 이 때 특정 서비스에 데이터의 요청이 몰리는 경우를 대비해, 모든 동작들이 최적화 될 수 있도록 한 서비스에서 다음 서비스로 요청을 라우팅하는 서비스 메시를 도입한다. 

 

 2. 마이크로서비스(MicroService)와의 차이점 

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

 

마이크로서비스(MicroService)란?

마이크로서비스는 각 마이크로서비스에 대해 자체적인 도구 및 코딩언어를 선택 할 수 있는 유연성을 적용 할 수 있는 소규모팀에 의해 구축된다. 즉 각 마이크로서비스는 독립적으로 구축되어 서로 통신하며 특정 서비스가 중단되어도 전체 서비스가 중단되지 않는 특징을 갖고 있다. 

 

 

마이크로서비스(MicroService)에서 상호 통신의 한계

이러한 마이크로서비스는 서비스 메시 계층 없이 각 마이크로서비스에 코딩을 입혀 통신을 할 수 있지만, 통신이 복잡해지면 한계가 발생한다. 실제 마이크로서비스 아키텍처에 구축된 클라우드 네이티브 앱들의 서비스 메시는 수많은 개별 서비스를 기능적 애플리케이션으로 구성한 방법을 사용하였다.

 

 3. 서비스 메시(Service Mesh)는 어떻게 동작하는가? 

기존 데이터간 통신 방식과의 차이점

기존 모든 아키텍처의 앱에는 특정 요청에 대하여 A-B로 이동하는 방법을 지정하는 규칙을 항상 필요로 하였다. 하지만 서비스 메시는 기존의 서비스에서 서비스로 통신을 제어하는 개별 서비스적인 논리에서 벗어나, 인프라 계층으로 추상화 한다는 차이점이 존재한다.

 

서비스 메시(Service Mesh) 동작방식

서비스 메시는 네트워크 프록시 배열로 앱에 구축된다. 즉, 서비스 메시에서의 요청은 자체 인프라 계층의 프록시를 통해 마이크로서비스들 사이에서 라우팅된다. 즉, 서비스 메시를 구성하는 개별 프록시들은 마이크로서비스 내부에서 실행되는 것이 아닌, 각 마이크로서비스와 함께 실행되기 때문에 'sidecar'라고도 한다. 이러한 'sidecar'는 아래 그림처럼, 마이크로서비스와 나란히 위치하여 다른 프록시로 라우팅을 요청하고, 이러한 'sidecar'들이 모여 메시 네트워크를 형성한다.

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

 

서비스 메시(Service Mesh)가 없는 마이크로서비스(MicroService)

  서비스 메시가 없는 마이크로서비스는, 각 마이크로서비스에 서비스들 사이에서의 커뮤니케이션을 통제하는 로직또한 코딩해야 하기 때문에, 개발자들은 자신들이 본래 구현해야 할 비즈니스 목표에 집중하지 못하게 된다. 또한 서비스들 사이의 커뮤니케이션을 통제하는 로직이 서비스 내부에 있어, 어느 서비스들 사이의 커뮤니케이션에서 문제가 발생했는지 알기 어렵다. 또한 각 애플리케이션에 새로운 서비스가 추가된다면 이는 서비스들 사이의 커뮤니케이션을 더욱 복잡하게 만들고, 복잡해진 마이크로서비스는 애플리케이션 내에 장애 지점을 찾는데 어려움을 유발시킨다.

 

 4. 서비스 메시(Service Mesh)의 이점 

1. 서비스들 사이에서 발생하는 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡쳐하여 준다.
2. 이러한 성능 메트릭은 시간이 지남에 따라 데이터가 누적되면서, 커뮤니케이션에 대한 룰에 적용이 가능하게 되며, 이는 서비스들이 효율적이고 안정적으로 서비스를 요청 할 수 있도록 한다.
3. 개발자들은 서비스들 사이의 커뮤니케이션에 신경을 쓰지 않고, 비즈니스 목표에 더욱 집중 할 수 있게 된다.
4. Jaeger(분산 추적 시스템)와 같은 소프트웨어를 통해 서비스와 함께 눈에 보이는 인프라 계층을 형성하여 문제를 더욱 손쉽게 인식하고 진단 할 수 있도록 해준다.
5. 서비스 메시(Service Mesh)는 장애가 발생한 서비스로부터의 요청을 다시 라우팅 할 수 있기 때문에 다운타임이 발생 시 애플리케이션 복구 능력을 향상 시켜 줄 수 있다.

 

Jaeger(예거) 란?

  분산 서비스들 사이에서의 트랜잭션을 추적하는 오픈소스 소프트웨어로 복잡한 마이크로서비스 환경을 모니터링하고 문제를 해결하는데 사용된다. 이 때 분산 추적이란, 마이크로서비스 간 복잡한 상호 작용에서 사건 발생의 전체를 파악하는 방식이다.

 

 

참고사이트

https://www.redhat.com/ko/topics/microservices/what-is-a-service-mesh

서비스 메쉬란 무엇일까요?