서비스 메시 — Envoy, Istio의 사이드카 프록시 모델
마이크로서비스가 수십 개로 늘어나면 서비스 간 통신 관리가 복잡해집니다. 서비스 메시는 이 통신을 인프라 레벨에서 투명하게 처리합니다.
서비스 메시란
서비스 간 통신을 관리하는 인프라 계층 입니다. 각 서비스에 사이드카 프록시 를 붙여서 트래픽을 제어합니다.
사이드카 프록시 없이:
서비스 A ──→ 서비스 B
(직접 통신: 재시도, 타임아웃, 인증을 코드에 구현)
사이드카 프록시 있을 때:
┌──────────────┐ ┌──────────────┐
│ 서비스 A │ │ 서비스 B │
│ ┌──────────┐ │ │ ┌──────────┐ │
│ │ Envoy │─┼────→│─│ Envoy │ │
│ │ (사이드카) │ │ │ │ (사이드카) │ │
│ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘
프록시가 재시도, mTLS, 메트릭을 자동 처리
Istio 아키텍처
┌────────────────────────────────────┐
│ Control Plane (istiod) │
│ ├── Pilot: 트래픽 라우팅 규칙 │
│ ├── Citadel: mTLS 인증서 관리 │
│ └── Galley: 설정 검증 │
├────────────────────────────────────┤
│ Data Plane (Envoy Sidecar) │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Svc A│ │Svc B│ │Svc C│ │
│ │+Envoy│ │+Envoy│ │+Envoy│ │
│ └─────┘ └─────┘ └─────┘ │
└────────────────────────────────────┘
핵심 기능
| 기능 | 설명 |
|---|---|
| 트래픽 관리 | 카나리 배포 (90% v1, 10% v2) |
| mTLS | 서비스 간 자동 암호화 통신 |
| 재시도/타임아웃 | 자동 재시도, 서킷 브레이커 |
| 관측 가능성 | 분산 추적, 메트릭, 로그 자동 수집 |
| 접근 제어 | 서비스 간 인가 정책 |
API 게이트웨이 vs 서비스 메시
| 항목 | API 게이트웨이 | 서비스 메시 |
|---|---|---|
| 위치 | 네트워크 경계 (North-South) | 서비스 간 (East-West) |
| 대상 | 외부 → 내부 트래픽 | 내부 서비스 간 트래픽 |
| 구현 | 중앙 프록시 | 사이드카 프록시 (분산) |
면접 포인트
- **사이드카 패턴의 장점 **: 애플리케이션 코드 수정 없이 네트워크 기능 추가
- ** 사이드카의 오버헤드 **: 각 Pod에 Envoy 추가 → 메모리/CPU 소비, 지연 추가
- Ambient Mesh: 사이드카 없이 노드 레벨 프록시로 오버헤드 감소 (Istio의 새 방향)
정리
서비스 메시는 마이크로서비스의 네트워크 통신을 인프라로 추상화합니다. 코드 변경 없이 mTLS, 재시도, 트래픽 분할을 적용할 수 있지만, 복잡성과 오버헤드가 단점입니다.
댓글 로딩 중...