서비스 메시
Service Mesh
서비스 메시는 마이크로서비스 간 통신을 애플리케이션 코드와 분리된 인프라 계층(사이드카 프록시 등)에서 처리하여 트래픽 관리·보안(mTLS)·관측성을 일관되게 제공하는 아키텍처이다.
핵심 키워드
사이드카 프록시(Sidecar Proxy)데이터 플레인(Data Plane)컨트롤 플레인(Control Plane)EnvoyIstio(istiod)mTLS(상호 TLS)트래픽 관리(카나리·서킷 브레이커·재시도)관측성(Observability)xDS API앰비언트 모드(Sidecarless)
암기: 서비스 메시 3대 기능 "트·보·관" (트래픽 관리·보안·관측성)
구성도
정리
1. 개요
- 정의: 서비스 간(East-West) 통신을 전담하는 전용 인프라 계층
- 배경
- MSA 환경에서 서비스 수 증가 → 서비스 디스커버리·재시도·타임아웃·암호화를 각 서비스 코드에 중복 구현하는 문제
- 언어별 라이브러리 방식(예: Netflix OSS)의 언어 종속·업그레이드 부담
- 서비스 간 호출 경로 가시성·제로 트러스트 보안 요구 증가
2. 구성/원리
- 데이터 플레인
- 각 서비스 옆에 배치된 사이드카 프록시(예: Envoy)가 모든 인바운드/아웃바운드 트래픽 가로챔
- 로드밸런싱, 재시도, 타임아웃, 서킷 브레이커, mTLS 암호화, 메트릭·트레이스 수집 수행
- 컨트롤 플레인
- 프록시 설정 배포, 서비스 디스커버리, 인증서 발급·순환, 정책 관리
- Istio는 istiod가 컨트롤 플레인 역할, xDS API로 Envoy에 설정 전달
- 동작 흐름: 서비스 A → A의 사이드카 → (mTLS) → B의 사이드카 → 서비스 B
- 주요 기능
- 트래픽 관리: 가중치 기반 라우팅(카나리), 미러링, 장애 주입
- 보안: mTLS 자동화, 서비스 ID 기반 인가 정책
- 관측성: 분산 추적, 메트릭, 접근 로그 자동 수집
3. 특징 또는 비교
| 구분 | 라이브러리 방식 | 사이드카 방식 | 앰비언트(사이드카리스) |
|---|---|---|---|
| 위치 | 애플리케이션 내부 | 파드마다 프록시 | 노드 단위 L4 프록시 + 선택적 L7 프록시 |
| 언어 종속 | 있음 | 없음 | 없음 |
| 자원 오버헤드 | 낮음 | 높음(파드별 프록시) | 상대적으로 낮음 |
| 업그레이드 | 앱 재배포 필요 | 프록시 재주입 필요 | 앱과 분리 |
| 구분 | API 게이트웨이 | 서비스 메시 |
|---|---|---|
| 트래픽 방향 | 외부 ↔ 내부(North-South) | 서비스 간(East-West) |
| 주요 역할 | 인증, 요청 라우팅, 속도 제한 | mTLS, 복원력, 관측성 |
- 대표 솔루션: Istio(+Envoy), Linkerd, Consul Connect
4. 고려사항·최신 동향
- 오버헤드: 프록시 홉 추가로 지연·CPU·메모리 증가 → 규모 대비 도입 효과 검토
- 복잡성: 설정 오류 시 장애 전파, 운영 역량 필요 → 점진적 도입(관측성 → mTLS → 트래픽 정책)
- 장애 영향: 컨트롤 플레인 장애 시에도 데이터 플레인은 기존 설정으로 동작하도록 설계
- 동향
- Istio 앰비언트 모드(ztunnel + waypoint 프록시)로 사이드카 없는 메시 확산
- eBPF 기반 데이터 플레인(Cilium 등)으로 커널 수준 처리
- Kubernetes Gateway API와 메시 설정 통합, 제로 트러스트 구현 수단으로 활용
함께 볼 토픽
v1 · 2026. 10. 19. 갱신 · 틀린 내용을 발견하면 알려 주세요.