[Microservice] Service Mesh

https://www.edwith.org/ncloudsaas/lecture/1371540?isDesc=false 

[LECTURE] 누구나 쉽게 이해할수 있는 마이크로서비스아키텍처(MSA) #1편 : edwith

 

 

 

MSA 를 구성하는 주요 Component

 

 

1. Config Management

서비스의 재빌드나 재부팅 없이 설정사항을 반영(Netflix Archaius, Kubernetes Configmap)

2. Service Discovery

MSA 기반 서비스 배포 시 서비스 검색 및 등록(Netflix Eureka, Kubernetes Service, Istio)

3. API Management

클라이언트 접근 요청을 일언화(Netflix Zuul, Kubernets Ingress)

4. Centralized Logging

서비스별 로그의 중앙집중화(ELK Stack)

5. Distributed Tracing

Microservice 간의 호출 추정(Spring Cloud Sleuth, Zipkin)

6. Centralized Monitoring

Service별 metric 정보의 중앙집중화(Netflix Spectator, Heapster)

7. Resilience & Fault Tolerance

MSA 구조에서 하나의 실패 서비스가 체인에 연결된 전체 서비스들에 파급 효과를 발생시키지 않도록 하기 위한

계단식 실패 방지 구조(Netflix Hystrix, Kubernetes Health check)

8. Auto-Scaling & Self-Healing

오토스케일링, 복구 자동화를 통한 서비스 관리 효율화

 

 

 

 

 

 

 

MSA 통신을 위해 각 서비스를 식별(Discovery), 경로를 파악(Routing) 하며 로드밸런싱(Load balancing),

전체 서비스의 장애 전파를 차단(Circult Break) 하며 Telemetry와 통합되어 로깅, 모니터링, 트레이싱 기능을 담당하는 Service Mesh 에 대한 이해가 필요

 

 

 

 

 

Service Mesh는 분산된 마이크로서비스 애플리케이션을 관리하기 위한 인프라스트럭처 계층이다.

이 계층은 서비스 간의 통신을 추상화하고, 로드 밸런싱, 서비스 디스커버리, 인증 및 권한 부여, 모니터링 및 로깅 등의 네트워크 서비스를 제공한다.

Service Mesh는 두 가지 기본 컴포넌트로 구성된다.

하나는 마이크로서비스 간의 통신을 대신해서 인프라스트럭처 계층에서 라우팅하는 Sidecar 프록시이고,

다른 하나는 Sidecar 프록시를 관리하고 서비스 메쉬를 구성하는 컨트롤 플레인 컴포넌트이다.

Sidecar 프록시는 각 마이크로서비스 인스턴스에 함께 배포되며, 서비스 간의 모든 통신을 중개한다.

프록시는 프로토콜 강제 적용, 트래픽 제어, 서비스 디스커버리, 인증 및 권한 부여, 트랜잭션 관리 및 모니터링을 수행하는 등 다양한 기능을 제공한다.

컨트롤 플레인 컴포넌트는 여러 Sidecar 프록시를 관리하고, 서비스 디스커버리, 로드 밸런싱, 인증 및 권한 부여, 모니터링 및 로깅 등과 같은 기능을 수행한다.

이 컴포넌트는 서비스 매쉬의 구성과 모니터링을 위한 API를 제공하며, 서비스 매쉬의 상태를 관리한다.

Service Mesh의 목표는 마이크로서비스 애플리케이션에서 인프라스트럭처 관리의 복잡성을 줄이고, 

서비스 간의 통신을 안전하고 안정적으로 유지하는 것이다.

 

 

 

Service Mesh Sidecar Pattern

Service Mesh의 한 구현 방식 중 하나로, 서비스 메시에 속한 각각의 마이크로서비스에 대해 별도의 Sidecar 프로세스를 실행하는 방식이다.

이 Sidecar 프로세스는 마이크로서비스와 함께 컨테이너화되어 배포되며, 마이크로서비스가 필요로 하는 서비스 메시 기능을 제공한다.

Sidecar는 마이크로서비스의 네트워크 트래픽을 모니터링하고, 서비스 디스커버리, 로드밸런싱, 서킷 브레이킹, 트래픽 증감 제어 등의 서비스 메시의 기능들을 수행한다.

이는 마이크로서비스의 소스 코드에 이러한 기능들을 넣지 않아도 되게 하여, 마이크로서비스 개발자들이 주로 비즈니스 로직에만 집중할 수 있도록 해준다.

서비스 메시 Sidecar 패턴은 Envoy와 같은 프록시 서버를 사용하여 구현될 수 있다.

이를 통해 표준화된 프록시 기능을 사용할 수 있고, 여러 언어와 플랫폼에서 동일하게 작동한다.

 

 

 

 

 

 

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

 

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

 

 

 

 

 

 

사이드카 Application은 기본 Application과 별도의 Application이다.
기본 Application의 로직을 수정하지 않고도 추가 기능을 수행할 수 있다.
기본 Application을 polyglot 프로그래밍을 적용해 요구 사항에 최적화된 환경에서 개발을 진행할 수 있다.
사이드카 Application은 기본 Application과 리소스를 공유할 수 있고 이를 통해 모니터링에 필요한 Metrics 수집, 프록시 동작 등을 수행할 수 있다.

 

 

Service Mesh를 구현할 수 있는 다양한 오픈소스 프로젝트가 있는데,

그 중에서도 대표적인 Service Mesh 구현체는 세가지이다.

Istio: Google, IBM, Lyft 등이 개발한 오픈소스 Service Mesh.

Envoy 프록시를 기반으로 하며, Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼에서 이용되는 것이 일반적이다.

Linkerd: Buoyant가 개발한 오픈소스 Service Mesh.

다른 Service Mesh 구현체와는 달리, 서비스 디스커버리와 로드 밸런싱을 위해 별도의 컨트롤 플레인이 필요하지않다.

다른 Service Mesh와는 달리, 작은 규모의 애플리케이션에서도 적용이 가능하다.

Consul: HashiCorp이 개발한 Service Mesh.

서비스 디스커버리와 분산 시스템 관리를 위한 도구들을 모두 포함하고 있다.

Consul은 다른 Service Mesh와 달리, 서비스 디스커버리를 위해 별도의 디스커버리 서비스를 제공한다.

또한, Kubernetes 외의 다른 인프라에서도 사용할 수 있다.

 

 

Service Mesh의 장단점

장점:
고도로 분산화된 시스템에서 많은 서비스 인스턴스를 관리하기 쉬워짐.
인프라 관리자와 개발자 간의 관심사 분리가 가능함.
트래픽 제어, 모니터링, 로깅 및 보안과 같은 중요한 기능을 지원함.
서비스 간의 통신을 투명하게 만들어줌.
트래픽에 대한 감시와 측정을 통해 서비스를 최적화하고 개선
서비스간 통신 기능을 쉽게 추가, 변경 및 삭제.

 

단점:
서비스 메시 구현체의 추가적인 인프라스트럭처 비용이 발생.
서비스 간의 지연 시간이 증가.
서비스 메시 구현체에 대한 추가적인 학습 및 스킬셋이 필요.
서비스간의 인터페이스와 커뮤니케이션 프로토콜이 일관이 필요.
잘못된 구성으로 인해 문제가 발생할 가능성.