169. 클라이언트 사이드 디스커버리 (Client-side) vs 서버 사이드 디스커버리

핵심 인사이트: 주문 서버가 결제 서버를 찾을 때(디스커버리), 주문 서버가 직접 전화번호부(레지스트리)를 뒤져서 전화를 걸면 '클라이언트 사이드'이고, 묻지도 따지지도 않고 교환원(로드밸런서)에게 전화를 넘기면 그 교환원이 대신 전화번호부를 찾아 걸어주는 것이 '서버 사이드'다. 대세는 깔끔한 서버 사이드다.

Ⅰ. 서비스 디스커버리 구현의 2가지 아키텍처 패턴

MSA 환경에서 동적으로 IP가 변하는 타겟 마이크로서비스를 찾아 통신하기 위해, '누가 서비스 레지스트리(Eureka, Consul 등)를 조회할 것인가?' 의 주체에 따라 아키텍처가 2가지 패턴으로 갈라집니다.

Ⅱ. 클라이언트 사이드 디스커버리 (Client-side Discovery)

서비스를 호출하는 클라이언트(Client 마이크로서비스) 내부에 소프트웨어 라우팅 로직이 탑재되어 직접 목적지를 찾는 방식입니다.

[ Client-side Discovery 구조 ]
1. [주문 서비스] ──(질의)──▶ [서비스 레지스트리(Eureka)]
                 ◀─(IP 목록: 10.0.0.1, 10.0.0.2)─
                 
2. [주문 서비스 내부의 로드밸런서(Ribbon)]가 IP 하나를 고름 (10.0.0.2 선택)

3. [주문 서비스] ──(직접 호출 HTTP)──▶ [결제 서비스 (10.0.0.2)]

• 장점: 중간에 거치는 홉(Hop, L4/L7 스위치 등)이 없어서 네트워크 지연이 가장 적습니다.
• 단점: '주문 서비스'의 코드 안에 레지스트리와 통신하고 로드밸런싱을 수행하는 코드가 강제로 삽입되어야 하므로(예: Spring Cloud Netflix Ribbon), 서비스의 언어(Java, Node.js)마다 전용 라이브러리를 모두 개발/유지보수해야 하는 지옥이 펼쳐집니다.

Ⅲ. 서버 사이드 디스커버리 (Server-side Discovery)

서비스를 호출하는 클라이언트는 레지스트리의 존재를 아예 모르며, 오직 앞단의 로드밸런서(Load Balancer)나 API 게이트웨이(서버 사이드 프록시) 에게 요청을 던지고 책임을 위임하는 방식입니다.

[ Server-side Discovery 구조 ]
1. [주문 서비스] ──(요청: 결제해 줘)──▶ [ Load Balancer (Proxy) ]
                                          │  ▲
                                          │  │ (질의 및 IP 목록 획득)
                                          ▼  │
                                    [ 서비스 레지스트리 ]

2. [ Load Balancer ] ──(라우팅 HTTP)──▶ [결제 서비스 (10.0.0.2)]

• 장점: '주문 서비스(클라이언트)' 코드가 극도로 단순해집니다. 어떤 언어로 짜든 상관없이(Polyglot 지원) 그냥 하나의 도메인(예: pay-service)으로만 던지면 되므로, 코드가 인프라 환경에 전혀 종속되지 않습니다.
• 단점: 모든 통신이 중간 로드밸런서(프록시)를 거쳐야 하므로 1 Hop이 추가되어 약간의 지연이 발생하고 로드밸런서가 단일 장애점(SPOF)이 될 수 있습니다.
• 대세: AWS의 ELB, 그리고 Kubernetes(K8s)의 CoreDNS 및 Service(Kube-proxy) 메커니즘이 완벽하게 이 서버 사이드 패턴을 채택하면서 현재 IT 산업의 절대적인 표준(대세)으로 굳어졌습니다.

📢 섹션 요약 비유: 클라이언트 사이드는 배달원이 직접 114 전화번호부 책(레지스트리)을 뒤져서 식당 주소를 찾아 오토바이를 몰고 가는 방식입니다. 서버 사이드는 배달원은 그냥 무조건 '콜센터 교환원(로드밸런서)'에게 물건을 던져주면, 교환원이 알아서 114를 뒤져서 목적지까지 배송을 처리해 주는 분업화된 방식입니다.