오늘은 Service Mesh에 대해 기록해보자.

일단 Service Mesh가 필요한 이유에 대해서 먼저 알아야한다.

📘 Service Mesh란?

Service Mesh는 애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법이다.
서비스 메쉬는 애플리케이션에 구축된 전용 인프라 계층으로, 트래픽 관리, 복원력, 정책, 보안,
신원 인증 및 관찰성과 같은 기능을 제공한다.

그럼 이 Service Mesh는 왜 필요할까? 이유는 MSA의 문제에 있었다.

• MSA의 문제
  MSA는 모놀리식의 단점을 극복하고 클라우드에서 운영할 때의 이점을 극대화 하기 위해 많이 사용한다.
  하지만 MSA를 사용하면서 “시스템의 런타임 복잡성” 문제가 발생한다.
  또한 “서비스&Instance의 증가”, “서비스 간 통신” 같은 이유로 인해 복잡성이 증가한다.

위와 같은 문제때문에 Service Mesh의 필요성이 생긴 것이다.

📜 Service Mesh의 기능

• Service Discovery
• Load Balancing
• Dynamic Request Routing
• Circuit Breaking
• Retry and Timeout
• TLS
• Distributed Tracing
• metrics 수집
• …

이들은 또한 Service Mesh의 기능이기도 하며 Service Mesh는 MSA를 보완하고 있다.

Serivce Mesh를 구성하는 가장 많이 사용되는 두가지 방법인
Proxy를 Side Car형식으로 이용하는 Mesh-Agnostic Code(istio/envoy) 방식과
Spring Cloud Eureka와 같이 프로그램 코드로 Service Mesh를 구성하는 Mesh-Aware Code 방식이 있다.

✏ Side Car 패턴

Side Car 패턴이란 오토바이에 연결된 사이드카와 유사하기에 사이드카라고 한다.

일반적으로 Side Car 패턴에서는 애플리케이션의 일부가 아니여도 되며, 연결만 되어있다.

Sidecar는 서비스에 들어오거나 나가는 모든 네트워크 트래픽을 처리한다.

가장 큰 특징은 비즈니스 로직이 포함된 실제 서비스와 sidecar가 병렬로 구성되어 있어 서비스 호출 시.
직접 호출이 아닌 proxy를 통해서 호출하는 것이다.

✏ Mesh-Aware Code 패턴

Mesh-Aware Code는 서비스 코드 작성 시 Mesh를 이해하고서 부분적으로 수정을 해야하는 수준을 말한다.
우리가 알고있던 일반적인 Spring Cloud Eureka, Hystrix, Ribbon과 같은 라이브러리 코드로 Service Mesh를 구성하는 것을 의미한다. (세부적인 컨트롤 가능)

✏ Service Mesh 구현

• Service Mesh Architecture의 구현은 보통 서비스의 앞단에 경량화 프록시를 사이드카 패턴으로 배치하여 서비스 간 통신을 제어하는 방법으로 구현한다.

• 서비스 간 통신은 사이드카로 배치된 경량화 Proxy를 통해서 동작한다.
  이 경량화 Proxy에 Routing rules, retry, timeout 등을 설정하고 로직을 작성하여 공통 기능을 기본 어플리케이션에서 분리시킬 수 있다.

• Service Mesh로 가장 많이 사용하는 오픈 소스인 Istio로 예시를 들면
  프록시의 위치를 찾게 해주는 라우팅, 로드 밸런싱, 로그 수집으로 인한 모니터링 기능을 수행한다.

• 하지만 서비스가 거대해짐에 따라 프록시 수도 증가하게 되는데, 이때 중앙 집중화된 컨트롤러가 통제할 수 있게 설계되었다.
  여기서 프록시들로 이루어져 트래픽을 설정 값에 따라 컨트롤하는 부분을 Data Plane이라고 하고,
  프록시들에 설정 값을 전달하고 관리하는 컨트롤러 역할을 Control Plane 이라고 한다.

• 이 때, Envoy proxy를 이용하는 것이 가장 일반적인 방법

• Envoy Proxy는 기존 프록시 L4기능 뿐 아니라 L7 기능도 지원하면서 HTTP 뿐아니라 HTTP 2.0,TCP,gRPC까지 다양한 프로토콜을 지원한다.

✏ 마무리

• DB는 모든 서비스에 분리가 되었지만 모두 동일하게 COPY되어 사용이 된다면
  Service끼리 통신하며 교류할 일이 없이 각 서비스에서 DB 이용을 하면 되기에 Service Mesh는 고려하지 않아도 될 것 같다.

• DB의 물리적인 분리로 우리와 같은 동일 데이터와 테이블을 사용하는 것이 아닌
  각각의 DB가 있는 서비스에서 API 호출 및 서비스끼리의 직접적인 통신의 문제를 막기 위해 나온 것인데
  서비스끼리의 통신이 없다면 Service Mesh는 사용하는 것이 타당하지 않다고 생각

• 하지만 만약 DB를 동일하게 구성하지 않고 각 서비스마다 다르게 DB를 나눈다면
  그때는 Service 간 API 호출로 데이터를 받아와야 하기 때문에 Service Mesh가 있어야 될 것 같다.

• 하지만 Istio 같은 Sidecar 방식은 각 서비스마다 Proxy를 따로 구성을 해야하기에 관리 포인트가 증가하고 네트워크 지연이 발생한다는 문제점이 있다.
  그래서 만약 Service Mesh를 구성해야 한다면 라이브러리를 이용한 Mesh-Aware Code 방식으로 구성을 하는 것이 더욱 효과적일 것 같다.

Istio는 Docker 환경에 더욱 최적화 되어 있고 Envoy 프록시를 주로 이용하는데 서비스마다 프록시가 증가하므로 네트워크 지연이 생기고
관리 포인트가 더욱 증가한다는 점에서 우리 회사에겐 적절하지 않다고 생각이 들었다.
그래서 Service Mesh가 필요하다면 Eureka와 같은 방식의 코드를 직접 작성하는 방식으로 제안했었다.
서비스가 많지 않은 경우엔 이 방법이 더욱 편리할 수도 있다는 참고 자료도 많았기에 우리의 MSA에선 Mesh-Aware Code 방식이 더욱 적절할 것 같았기 때문이다.
하지만 우리의 1안으로는 DB에 데이터를 모두 동일하게 저장하고 이용하기 때문에 서비스 간의 통신이 필요하지 않다고 생각이 들어 이 경우에는 Service Mesh가 필요 없다고
생각했다.