이 글은 '샘 뉴먼 - 마이크로소프트 아키텍처 구축' 내용을 기반으로 합니다.
서비스 메시는 마이크로서비스 간 네트워크 통신, 검색, 로드 밸런싱, 회복성, 보안, 모니터링 등을 처리하는 전용 인프라 계층을 의미한다. 복잡한 마이크로서비스 환경에서 서비스 간의 통신은 매우 중요하고 어려운데, 서비스 메시는 이러한 통신과 관련된 여러 기능들을 애플리케이션 코드 변경 없이 일관되고 효과적으로 관리할 수 있도록 도와준다.
Sidecar 프록시 패턴 (예전 방식)
서비스 메시는 일반적으로 각 마이크로서비스 인스턴스 옆에 '사이드카(Sidecar)' 형태로 네트워크 프록시(예: Envoy)를 배포하는 방식으로 구현된다. 애플리케이션 컨테이너와 동일한 배포 단위(예: 쿠버네티스 Pod) 내에서 실행되는 이 사이드카 프록시는 애플리케이션으로 들어오고 나가는 모든 네트워크 트래픽을 가로챈다. 서비스 메시는 이러한 프록시들을 중앙(Control Plane)에서 제어하여 다양한 기능을 통신 경로에 적용한다. 이 방식은 애플리케이션 코드 수정 없이 공통 기능을 주입하고 언어에 구애받지 않는다는 장점이 있다.
Sidecar-less 서비스 메시 (최신 동향)
최근에는 사이드카 프록시의 단점(리소스 오버헤드-인스턴스의 리소스를 잡아먹음-, 약간의 지연 시간 추가, 관리 복잡성 등)을 해결하기 위한 '사이드카리스(Sidecar-less)' 접근 방식이 주목받고 있다. 이는 각 애플리케이션 인스턴스마다 별도의 프록시를 두는 대신, 다른 방식으로 서비스 메시 기능을 구현한다.
- 구현 방식 예시:
- 노드(Node)당 프록시: 각 서버 노드(호스트 머신)에 하나의 공유 프록시 인스턴스를 실행하여 해당 노드의 모든 마이크로서비스 트래픽을 처리한다.
- eBPF 활용: 리눅스 커널 기술인 eBPF(Extended Berkeley Packet Filter)를 사용하여 커널 수준에서 직접 네트워크 트래픽을 관찰하고 제어함으로써 프록시 자체를 필요 없게 만들거나 기능을 최소화한다. (예: Cilium Service Mesh)
- 라이브러리 통합: 일부 기능을 애플리케이션 라이브러리 형태로 통합하는 방식도 고려될 수 있으나, 이는 서비스 메시의 핵심 장점인 '코드 변경 없는 분리' 원칙과는 다소 거리가 있다.
사이드카리스 방식은 잠재적으로 리소스 사용량을 줄이고 성능을 개선할 수 있지만, eBPF와 같이 특정 커널 기능에 대한 의존성이 생기거나, 사이드카 모델이 제공하는 수준의 격리성이 일부 저하될 수 있는 등 새로운 트레이드오프가 존재한다. 이는 서비스 메시 기술이 계속 발전하고 있음을 보여주는 예이다.
서비스 메시의 주요 기능
어떤 구현 방식(Sidecar 또는 Sidecar-less)을 사용하든, 서비스 메시는 일반적으로 다음과 같은 핵심 기능을 제공하는 것을 목표로 한다.
- 통신 관리 및 제어:
- 트래픽 관리: 서비스 간 요청 라우팅, 로드 밸런싱, 카나리 배포, A/B 테스팅 등을 세밀하게 제어할 수 있다.
- 회복성: 타임아웃, 재시도, 서킷 브레이커, 연결 풀 관리 등의 기능을 제공하여 서비스 장애 시 시스템의 안정성을 높인다.
- 보안: 서비스 간 상호 TLS(mTLS)를 통한 안전한 통신, 인증 및 인가 정책 적용, 각 마이크로서비스 주변에 마이크로 경계를 형성하여 보안을 강화한다.
- 관찰 가능성 (Observability): 서비스 간 통신에 대한 상세한 메트릭 수집, 분산 추적(Distributed Tracing), 로깅 통합 등을 용이하게 하여 시스템 상태 파악 및 문제 해결을 돕는다.
- 서비스 디스커버리 (Service Discovery): 마이크로서비스가 많아지면 서비스의 위치를 파악하는 것이 중요하다. DNS를 사용할 수도 있지만, 동적인 환경에서는 TTL 문제나 업데이트의 어려움이 있을 수 있다. Istio, Zookeeper, Consul, Eureka와 같은 동적 서비스 레지스트리는 서비스 인스턴스가 자신을 등록하고 다른 서비스가 이를 조회할 수 있는 메커니즘을 제공한다. 서비스 메시는 종종 이러한 레지스트리와 통합되거나 자체적인 디스커버리 기능을 포함한다.
'기타' 카테고리의 다른 글
[MSA] 2페이즈 커밋(2PC) 쓰지 말자 (0) | 2025.05.05 |
---|---|
[MSA] 도메인 주도 설계(Domain-Driven Design - DDD) (0) | 2025.05.05 |
[MSA] 사가 구현: 오케스트레이션 vs 코레오그래피 (0) | 2025.05.01 |
[MSA] 분산 트랜잭션의 문제 해결 - 사가(Saga) (0) | 2025.05.01 |
3-Way Handshake & 4-Way Handshake (0) | 2025.05.01 |
댓글