[Kubernetes] MSA 및 Service Mash 소개

1. MSA 소개

1-1. MSA (MicroService) 이란?

• 1개의 시스템을 독립적으로 배포 가능한 각각의 서비스로 분할합니다. 각각의 서비스는 API를 통해 데이터를 주고받으며 1개의 큰 서비스를 구성한다.
• MSA 방식으로 구성하면 일부 서비스에 장애가 발생하여도 전체 서비스에 장애가 발생하지 않는다. 또한 각각의 서비스들은 서로 다른 언어와 프레임워크로 구성할 수 있다.
• 하기 이미지와 같이 온라인 구매 사이트를 만들 때 결제, 재고, 장바구니 페이지 등으로 서비스를 분할하여 구성한다.

https://youtu.be/16fgzklcF7Y?si=ESksQuRYYrWYckZ

1-2. Service Mash를 사용하지 않을 경우

• 서비스 메쉬 없이 각 마이크로서비스는 서비스 간 커뮤니케이션을 통제하는 로직으로 코딩해야 하기 때문에 개발자들이 비즈니스 목표에 집중하지 못하게 된다.
  • A 서비스가 추가될 경우 Business Logic에 Communication Configurations 를 통해 통신이 필요한 모든 마이크로서비스에 새 서비스 엔드포인트를 추가해야한다. 이는 배포 코드의 일부로 포함되게 된다.
  • 클러스터 내의 모든 서비스들은 다른 서비스와 자유롭게 통신할 수 있다. 즉, 보안적으로 클러스터 내부로 공격이 침투할 경우 내부에 추가적인 보안이 없기 때문에 위험하다. 
  • 이에, 하나의 마이크로서비스에 Business Logic을 제외하고 Communication Configurations, Security Logic, Retry Logic, Metrics, Tracing이 추가적으로 필요하기 때문에 개발자들은 실제 서비스 또는 애플리케이션 로직에 집중할 수 없다.
• 서비스 간 커뮤니케이션을 통제하는 로직이 각 서비스 내부에 숨겨져 있기 때문에 커뮤니케이션 장애를 진단하기가 더 어려워진다.

2. Service Mash 소개

2-1. Service Mash 란?

• Service Mesh는 마이크로서비스 간의 통신(네트워크)을 담당하는 요소이다.
• 기존에 한 마이크로서비스에 같이 존재하였던 Communication Configurations, Security Logic, Retry Logic, Metrics, Tracing 부분을 Business Logic과 분리하여 Proxy로서 네트워크 로직을 다룬다.
• third-party application (ex. Istio, Linkerd 등)을 통해 쉽게 구성할 수 있다.

https://www.youtube.com/watch?v=16fgzklcF7Y

2-2. Service Mash 작동 방식

• Control Plane을 통해 Proxy를 자동으로 추가함으로 yaml 파일에 sidecar를 직접 구성하지 않아도 된다.
• sidecar를 통해 Service Mash를 구성하는 개별 프록시는 서비스 내부가 아니라 각 서비스와 함께 실행된다.
• 각 서비스에서 분리된 이러한 sidecar 프록시들이 모여 메쉬 네트워크를 형성한다.

https://www.youtube.com/watch?v=16fgzklcF7Y

2-3. Service Mash 기능

• 트래픽 분산: 새 버전을 릴리즈 할 때 들어오는 트래픽을 서로 다른 서비스 버전에 분하여 전달한다. (Canary 배포)
• 모니터링, 로깅, 추적, 트래픽 제어

2-4. Service Mash 장단점

• 장점
  • Proxy 연계를 통해 인프라 복잡성이 감소된다.
  • 서비스 간 통신을 손쉽게 모니터링, 제어 및 디버깅할 수 있다.
• 단점
  • SideCar를 통해 Proxy를 구성하기 때문에 성능 저하가 발생할 수 있다. 
  • 적용해야 하는 정책이 많아 지면서 관리가 어려워 진다.

3. Service Mash 서비스

3-1. Istion

• 서비스 메시를 구현하기 위한 오픈 소스 플랫폼이다.
• 마이크로서비스 아키텍처를 위한 서비스 간 통신, 보안, 모니터링, 트래픽 관리,Telemetry (k8s 서비스 간의 트래픽 가시화)를 제공한다.
• Istio는 Envoy라는 사이드카 프록시를 사용하여 이러한 기능을 구현한다.
• Envoy는 각 서비스 컨테이너와 함께 실행되며, 모든 네트워크 트래픽을 가로채고 제어한다.

https://istio.io/latest/about/service-mesh/

 

3-2. Linkerd

• Linkerd는 마이크로 프록시인 Rust를 사용하기 때문에 Istio보다 가볍고 빠르다.
• Istio의 Virtual Service, Destnation Rule과 같은 CRD 없이 쉽게 구성 가능하다.
• Linkerd는 Control plane과 Data plane으로 구성된다.
  • Control plane:  Linkerd 전체를 제어하는 역할 담당한다.
  • Data plane: 각 서비스 인스턴스 옆에 "sidecar" 컨테이너로서 실행되는 투명한 마이크로 프록시로 구성된다. 이러한 프록시는 서비스와의 모든 TCP 트래픽을 자동으로 처리하고 구성을 위해 control plane과 통신한다.

https://linkerd.io/2.12/reference/architecture/#

---

 

참고

서비스 메쉬(service mesh) 개념, 기능, 작동방식, 최적화 방법