핵심 인사이트 (3줄 요약)
- 본질: 서비스 메시는 각 마이크로서비스에 사이드카 프록시(Envoy)를 배치하여, 서비스 간 통신의 로드밸런싱·서킷 브레이커·mTLS·트레이싱·트래픽 제어를 애플리케이션 코드 변경 없이 인프라 레벨에서 처리하는 패턴이다.
- 가치: 서비스 간 통신 로직(재시도·타임아웃·암호화)을 각 서비스가 직접 구현하면 중복·불일치가 발생하지만, 서비스 메시는 사이드카가 일괄 처리하여 일관성을 보장한다.
- 판단 포인트: Istio(가장 기능 풍부)·Linkerd(경량)·Cilium(eBPF 기반, 사이드카 없음)이 대표이며, 컨트롤 플레인(정책 관리)과 데이터 플레인(사이드카 프록시)으로 구성된다.
Ⅰ. 개요 및 필요성
서비스 메시 구조:
데이터 플레인: Envoy 사이드카 (각 Pod 옆)
→ 트래픽 가로채기 → LB·재시도·mTLS·트레이싱
컨트롤 플레인: Istiod (정책·설정 배포)
→ VirtualService·DestinationRule 등 CRD
- 📢 섹션 요약 비유: 서비스 메시는 우체국 네트워크이다. 편지(요청)를 직접 전달하는 대신, 우체부(사이드카)가 분류·배달·보안을 대행한다.
Ⅱ~Ⅴ. 결론
서비스 메시는 MSA 통신의 인프라 표준이며, Istio(기능)·Cilium(eBPF 성능)이 주류이다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 서비스 메시 | 사이드카 통신 |
| Envoy | 사이드카 프록시 |
| Istio | 컨트롤 플레인 |
| mTLS | 서비스 간 암호화 |
| Cilium | eBPF 기반 (차세대) |
📈 관련 키워드 및 발전 흐름도
[라이브러리 기반 (Netflix OSS, 2014)] → [Linkerd v1 (2017)]
→ [Istio + Envoy (2017)] → [Linkerd2 (Rust, 경량)]
→ [현재: Cilium (eBPF, 사이드카 없음)]
👶 어린이를 위한 3줄 비유 설명
- 서비스 메시는 우체국 시스템이에요. 편지를 직접 가져가지 않고 **우체부(사이드카)**가 배달해요.
- 우체부가 분류·보안·재배달을 다 해줘서 보내는 사람은 편해요.
- 우체국 본부(컨트롤 플레인)가 모든 우체부에게 규칙을 알려줘요!