**service discovery(서비스 디스커버리)**는 인스턴스가 확장, 축소, 재시작될 때 변하는 IP를 하드코딩하는 대신, 서비스들이 서로의 네트워크 위치를 동적으로 찾을 수 있게 해줍니다.
클라우드에서는 인스턴스가 오토스케일링과 장애에 따라 생겼다 사라지므로 주소가 안정적이지 않습니다. **service registry(서비스 레지스트리)**가 정상 인스턴스를 추적합니다.
1. 서비스가 자기 자신을 등록 ──▶ [ Registry: orders → 10.0.1.7, 10.0.1.9 ]
2. 호출자가 레지스트리에 "orders는 어디 있나?"라고 질의
3. 레지스트리가 정상 인스턴스를 반환
4. 호출자가 하나를 선택(로드 밸런싱)
| 클라이언트 측 | 서버 측 |
|---|
| 인스턴스를 누가 선택 | 클라이언트 | 로드 밸런서 |
| 예시 | Netflix Eureka + Ribbon | AWS ELB, Kubernetes Service |
| 클라이언트 복잡성 | 높음 | 낮음 |
클라이언트 측: Caller ─▶ Registry ─▶ 선택 ─▶ Instance
서버 측: Caller ─▶ Load Balancer ─▶ Instance (LB가 조회 수행)
오래된 레지스트리 항목은 트래픽을 죽은 인스턴스로 라우팅합니다. 이를 제거하려면 헬스 체크와 TTL이 필수적입니다.
service discovery는 탄력적 확장을 가능하게 하는 요소입니다. 누구도 설정을 편집하지 않고도 인스턴스가 나타나고 사라질 수 있습니다.
Kubernetes에서는 이것이 DNS와 Service를 통해 기본 내장되어 있어, 디스커버리를 공짜로 얻는 경우가 많습니다. 그래도 라우팅 문제를 디버깅하려면 그 모델을 이해하는 것이 중요합니다.