동적 IP 환경의 서비스 탐색을 위한 Discovery 모델 및 Service Mesh 전략 분석

System Design - 17. Service Discovery & Service Mesh: How Thousands of Services Find Each Other

Rajkiran2026년 6월 12일10분intermediate

AI 요약

Context

Monolith 구조와 달리 Microservices 환경에서는 Container의 잦은 재시작과 Auto-scaling으로 인한 IP 변동성이 극심함. 하드코딩된 IP나 정적 설정 파일로는 수십 개의 인스턴스를 관리하는 실시간 네트워크 가용성 확보에 한계가 있음.

Client-Side Discovery: 서비스가 Registry에서 직접 인스턴스 리스트를 조회하고 자체 Load-balancing을 수행하여 Network Hop을 제거한 구조 설계
Server-Side Discovery: 고정 DNS 이름을 통해 Load Balancer가 요청을 라우팅함으로써 개별 서비스의 Discovery 로직을 제거한 Language-agnostic 구조 채택
Service Registry Lifecycle: Heartbeat 메커니즘을 통한 상태 감시 및 SIGTERM 기반의 Graceful Shutdown 프로세스로 Registry 데이터 정합성 유지
Service Mesh (Sidecar Pattern): Envoy Proxy를 통해 mTLS, Circuit Breaking, Canary Routing 등 공통 관심사를 애플리케이션 코드에서 분리하여 인프라 계층으로 이동
Traffic Segmentation: 외부 유입 트래픽(North-South)은 API Gateway가 처리하고 내부 서비스 간 통신(East-West)은 Service Mesh가 전담하는 상호 보완적 구조 구성

실천 포인트

1. Polyglot 환경이며 서비스 수가 10~15개 미만인 경우 Discovery 라이브러리보다 Server-Side Discovery(K8s DNS 등) 우선 검토

2. 서비스 규모 확장에 따른 운영 복잡도 증가 시, 애플리케이션 코드 수정 없이 정책 제어가 가능한 Service Mesh 도입 고려

3. 인스턴스 제거 시 Registry에서 먼저 제거한 후 Connection Draining을 수행하는 순차적 종료 프로세스 적용 여부 확인

4. Service Mesh 도입 전 Latency 증가 및 리소스 오버헤드가 비즈니스 요구사항을 충족하는지 비용 대비 편익 분석 수행

태그