서비스 메시 아키텍처는 별도의 인프라 계층을 통해 마이크로서비스 간의 복잡한 상호작용을 관리하기 위해 설계되었습니다. 서비스 메시에는 자동으로 라우팅, 로드 밸런싱, 서비스 발견, 보안(mTLS 등), 로깅, 추적 및 요청 재시도와 같은 기능이 포함되어 있으며, 이를 각 서비스에서 구현할 필요가 없습니다. 이를 가능하게 하는 것은 각 마이크로서비스 옆에 배치되어 모든 네트워크 트래픽을 가로채는 특별한 프록시(sidecar)입니다.
전통적인 마이크로서비스 아키텍처는 이러한 대부분 기능을 각 서비스 내에서 또는 플랫폼 수준에서 구현해야 하므로, 서비스 수가 많을 경우 프로젝트의 발전 및 유지 보수가 복잡해질 수 있습니다.
Kubernetes를 위한 Istio 서비스 메시 설정 코드 예시:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - route: - destination: host: my-service subset: v1
주요 특징:
중앙 집중식 라우팅 및 네트워크 상호작용 정책 관리.
각 서비스 내의 상호작용 로직 코드 중복 최소화.
애플리케이션의 비즈니스 로직을 변경하지 않고 보안 및 모니터링 개선.
서비스 메시는 API 게이트웨이를 완전히 대체하나요?
아니요, 서비스 메시와 API 게이트웨이는 서로 보완적입니다: API 게이트웨이는 입구 제어를 제공하고 서비스 메시가 서비스 간의 동서 통신을 관리합니다.
서비스 메시를 도입할 때 서비스 코드를 수정해야 하나요?
보통 필요하지 않습니다. 대부분의 경우, 서비스 프록시는 사이드카 모드로 실행되며, 비즈니스 로직 코드를 변경할 필요는 없습니다.
서비스 메시가 마이크로서비스 성능을 저하시키나요?
서비스 메시가 프록시 트래픽 처리를 위해 약간의 지연을 초래하지만, 대부분의 시나리오에서 관리성과 신뢰성의 이점에 비해 이는 무시할 수 있는 수준입니다.