Sidecar Pattern
왜 이 아키텍처인가
사이드카 패턴을 선택하는 이유는 공통 인프라 기능(로깅, 보안, 모니터링)을 비즈니스 로직과 분리해 각 서비스에서 중복 구현하지 않기 위해서다.
| 대안 | 문제점 | 사이드카의 해결 |
|---|---|---|
| 각 서비스에 직접 구현 | mTLS, 트레이싱 코드가 모든 서비스에 복제 | 사이드카가 공통 처리, 앱은 비즈니스에만 집중 |
| 공유 라이브러리 | 언어별 구현 필요, 업그레이드 시 재배포 필요 | 언어 무관, 사이드카만 업그레이드 |
| API Gateway 집중 처리 | 게이트웨이가 단일 장애점, 레이턴시 증가 | 서비스 옆에서 처리해 네트워크 홉 감소 |
Istio/Envoy 사이드카를 붙이면 코드 한 줄 수정 없이 모든 서비스 간 통신에 mTLS, 분산 트레이싱, Circuit Breaker가 적용된다.
실무에서 자주 하는 실수
-
사이드카에 비즈니스 로직 추가 — 공통 인프라 기능만 담아야 하는 사이드카에 특정 서비스 로직을 넣으면 재사용이 불가능해지고 의존성이 복잡해진다. 라우팅, 인증, 트레이싱처럼 서비스 무관한 횡단 관심사만 사이드카에 위임해야 한다.
-
사이드카 리소스 제한 미설정 — 사이드카(Envoy 등)에 CPU/메모리 limits를 지정하지 않으면 메모리 누수 시 앱 컨테이너까지 영향을 준다. 사이드카도 별도 리소스 limits를 반드시 설정해야 한다.
-
사이드카 업그레이드 시 앱 재시작 누락 — 사이드카 이미지 버전을 올렸는데 Pod를 재시작하지 않으면 기존 컨테이너가 구버전 사이드카를 계속 사용한다. 롤링 업데이트로 순차 재시작을 적용해야 한다.
면접 포인트
Q1. 사이드카 패턴과 API Gateway의 차이점은? A. API Gateway는 외부 클라이언트와 서비스 사이의 단일 진입점으로 인증, 라우팅, 속도 제한을 중앙에서 처리한다. 사이드카는 각 서비스 인스턴스 옆에 배치돼 서비스 간 내부 통신(East-West)의 mTLS, 트레이싱, Circuit Breaker를 처리한다. 둘은 상호 보완적으로 함께 사용된다.
Q2. Istio 사이드카를 적용할 때 발생하는 오버헤드는? A. Envoy 프록시를 거치는 추가 네트워크 홉으로 레이턴시가 1~5ms 증가한다. 사이드카 컨테이너 자체가 CPU 50~100m, 메모리 50~100MB를 소비한다. 고빈도 저레이턴시 내부 호출이 많은 서비스에서는 이 오버헤드가 문제가 될 수 있어 서비스 메시 적용 범위를 선별해야 한다.
Q3. 사이드카 없이 서비스 메시 기능을 구현하는 대안은? A. eBPF 기반 사이드카리스(Cilium, Ambient Mesh)는 커널 레벨에서 트래픽을 처리해 사이드카 오버헤드를 제거한다. Istio Ambient 모드는 사이드카 없이 L4 보안과 L7 정책을 분리해 적용할 수 있다. 사이드카 방식보다 리소스 효율이 높지만 성숙도가 낮다.
댓글