마이크로서비스가 수십 개로 늘어나면 서비스 간 통신 관리가 복잡해집니다. 서비스 메시는 이 통신을 인프라 레벨에서 투명하게 처리합니다.


서비스 메시란

서비스 간 통신을 관리하는 인프라 계층 입니다. 각 서비스에 사이드카 프록시 를 붙여서 트래픽을 제어합니다.

PLAINTEXT
사이드카 프록시 없이:
서비스 A ──→ 서비스 B
(직접 통신: 재시도, 타임아웃, 인증을 코드에 구현)

사이드카 프록시 있을 때:
┌──────────────┐     ┌──────────────┐
│ 서비스 A      │     │ 서비스 B      │
│ ┌──────────┐ │     │ ┌──────────┐ │
│ │ Envoy    │─┼────→│─│ Envoy    │ │
│ │ (사이드카) │ │     │ │ (사이드카) │ │
│ └──────────┘ │     │ └──────────┘ │
└──────────────┘     └──────────────┘
프록시가 재시도, mTLS, 메트릭을 자동 처리

Istio 아키텍처

PLAINTEXT
┌────────────────────────────────────┐
│  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, 재시도, 트래픽 분할을 적용할 수 있지만, 복잡성과 오버헤드가 단점입니다.

댓글 로딩 중...