168. 서비스 디스커버리 (Service Discovery)

⚠️ 이 문서는 클라우드와 MSA 환경에서 끊임없이 생성되고 소멸하는 수많은 마이크로서비스(컨테이너)들의 IP 주소와 포트 번호를 자동으로 추적하고 연결해주는 서비스 디스커버리 패턴을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 오토스케일링(Auto-scaling)이나 배포에 의해 동적으로 변하는 서비스 인스턴스의 네트워크 위치(IP/Port)를 실시간으로 등록(Registry)하고 조회(Lookup)하는 자동화된 '전화번호부'다.
  2. 가치: 서비스 간의 의존성을 설정 파일(IP 하드코딩)에서 분리하여, 클라우드 환경의 탄력성과 유연성을 100% 활용할 수 있게 해주는 MSA의 핵심 기반 기술이다.
  3. 기술 체계: Client-Side Discovery(클라이언트가 직접 레지스트리 조회 후 로드밸런싱)와 Server-Side Discovery(로드밸런서나 API 게이트웨이가 대신 조회) 방식으로 나뉘며, 대표 솔루션으로 Netflix Eureka, Consul, ZooKeeper가 있다.

Ⅰ. 고정 IP의 종말: 클라우드 네이티브의 통신 문제

전통적인 서버 환경에서는 서비스 A가 서비스 B를 호출할 때 IP 주소를 설정 파일에 고정(Hard-coding)해 두면 충분했다.

  1. 동적 인스턴스 환경 (Dynamic Instances):
    • 컨테이너 기반의 MSA에서는 트래픽이 증가하면 서비스 B의 인스턴스가 순식간에 10개로 늘어나고, 줄어들면 2개로 감소한다.
  2. IP/Port의 불확실성:
    • 새로 뜬 컨테이너는 매번 다른 IP와 무작위 Port를 할당받는다. 호출하는 쪽(서비스 A)은 바뀐 주소를 알 방법이 없다.
  3. 서비스 디스커버리의 필요성:
    • 변경된 주소를 사람이 수동으로 업데이트하는 것은 불가능하므로, 인스턴스 스스로 자신의 생존과 위치를 알리고, 다른 서비스는 이를 동적으로 찾아내는 중앙 집중식 명부가 필요해졌다.

📢 섹션 요약 비유: 이사(오토스케일링)를 자주 다니는 친구(서비스)의 바뀐 집 주소(IP)를 매번 물어보는 대신, 친구가 동사무소(레지스트리)에 실시간 전입신고를 가장 먼저 하고 우리는 동사무소에 전화해서 친구 위치를 찾는 것과 같습니다.

Ⅱ. 서비스 디스커버리 아키텍처 패턴

서비스 디스커버리는 '누가 전화를 걸어 주소를 묻느냐'에 따라 두 가지 주요 패턴으로 나뉜다.

  1. 클라이언트 사이드 디스커버리 (Client-Side Discovery):

    • 클라이언트(호출자)가 직접 서비스 레지스트리에 접근해 사용 가능한 인스턴스 목록을 받아온 뒤, 클라이언트 내부에서 로드밸런싱(Ribbon 등)을 수행하여 호출한다.
    • 장점: 중간 로드밸런서(LB)가 없어 홉(Hop)이 줄고 성능이 빠름. (예: Netflix Eureka)
    • ┌────────────────────────────────────────────────────────┐ │ [Service A] ---(1. IP 목록 요청)---> [Service Registry] │ │ │ │ │ └-------(2. 직접 선택 호출)-------> [Service B] │ └────────────────────────────────────────────────────────┘

  2. 서버 사이드 디스커버리 (Server-Side Discovery):

    • 클라이언트가 고정된 API 게이트웨이나 로드밸런서로 요청을 보내면, LB가 레지스트리를 조회하여 트래픽을 적절한 인스턴스로 라우팅한다.
    • 장점: 클라이언트는 레지스트리의 존재를 몰라도 됨(단순화). AWS ELB나 Kubernetes의 Kube-Proxy가 이 방식을 사용함.

📢 섹션 요약 비유: 배달 음식을 시킬 때 내가 직접 '배달앱(Registry)'을 켜서 식당을 고르는 것이 Client-Side라면, '비서(Load Balancer)'에게 "중식 시켜줘"라고 하면 비서가 알아서 식당을 찾아 배달시키는 것이 Server-Side입니다.