[MSA] 마이크로서비스 코딩 공작소 - 6장

서정범·2024년 2월 13일

architecture msa

MSA

목록 보기

8/10

서비스 디스커버리

서비스 디스커버리(Service Discovery)는 MSA에서 굉장히 중요한 기능을 수행합니다.

마이크로서비스는 일시적인 만큼 유연성이 좋아야 합니다. 인스턴스를 빠르게 생성했다가 삭제하는 작업이 가능하려면 서버에 대한 IP 주소 추적이 자동으로 빠르게 이루어져야 합니다.

또한, 인스턴스가 여러 개라면 요청을 어느 서버에 보낼지도 중요합니다.

문제가 발생되는 서버에 대한 확인도 빠르게 이루어져야 하고, 이것이 확인되면 요청을 해당 서버로 보내면 안될 것입니다.

이러한 작업들을 수행하기 위해서 사용하는 것이 서비스 디스커버리입니다.

서비스 디스커버리는 두 가지 핵심적인 이유로 마이크로서비스와 클라우드 기반 애플리케이션에서 매우 중요합니다.

수평 확장(horizontal scaling or scale out)
회복성(resiliency)

1. 서비스 위치 확인

애플리케이션이 여러 서버에 분산된 자원을 호출하는 경우 이 자원들의 물리적 위치를 알고 있어야 합니다. 클라우드가 아닌 환경에서 서비스 위치 확인(location resolution)은 대개 DNS와 네트워크 로드 밸런서의 조합으로 해결했습니다.

이러한 방식이 가능했던 이유는 서버의 수가 고정적인 점이 컸습니다.

만약 서비스 서버의 인스턴스를 확장하고 싶은 경우에는 DNS 서버에 등록해야되는 절차가 요구될 것입니다.
또한, 해당 방식은 고장난 서버에 대한 확인을 자동적으로 수행하는 것이 불가능하므로 로드 밸런싱 과정에서 요청을 고장난 서버로 보낼 수 있습니다.
추가적으로 해당 로드 밸런서는 단일 장애 지점 문제를 회피하기 위해서 핫스왑 모델을 사용하여 이중화를 수행하지만 이것은 수평적 확장 능력이 제한됩니다.

정리해보자면 다음과 같습니다.

고가용성 로드 밸런서를 만들 수 있더라도 전체 인프라스트럭처에서 보면 단일 장애 지점(Single Point of Failure)입니다.
서비스를 하나의 로드 밸런서 클러스터에 집중시키면 여러 서버에 부하를 분산하는 인프라스트럭처의 수평 확장 능력이 제한됩니다.
전통적인 로드 밸런서 대부분은 고정적으로 관리됩니다.
로드 밸런서가 프록시(Proxy) 역할을 하므로 서비스 소비자 요청은 물리적 서비스에 매칭되어야 합니다.

2. 클라우드에서 서비스 디스커버리

서비스 디스커버리는 다음과 같은 특징을 가지고 있습니다.

고가용성(highly available): 서비스 디스커버리는 서비스 디스커버리 클러스터의 노드 간 서비스 검색 정보가 공유되는 '핫(hot)' 클러스터링 환경을 지원할 수 있어야 합니다.
로드 밸런서와 통합된 클러스터는 서비스 중단을 방지하는 페일 오버(Fail Over)와 세션 데이터를 저장하는 세션 복제(Session Replication) 기능을 제공할 수 있습니다.
P2P(Peer-to-Peer): 서비스 디스커버리 클러스터의 모든 노드는 서비스 인스턴스의 상태를 상호 공유합니다.
부하 분산(load balanced): 서비스 디스커버리는 요청을 동적으로 분산시켜 관리하고 있는 모든 서비스 인스턴스에 분배해야 합니다.
회복성(resilient): 서비스 디스커버리 클라이언트는 서비스 정보를 로컬에 캐싱(caching) 해야 합니다.
결함 내성(fault tolerant): 서비스 디스커버리가 비정상 서비스 인스턴스를 감지하면 클라이언트는 요청을 처리하는 가용 서비스 목록에서 해당 인스턴스를 제거해야 합니다.

이제 서비스 디스커버리에 대해서 파헤쳐봅시다.

2.1 서비스 디스커버리 아키텍처

서비스 디스커버리를 노의하려면 다음 네 가지 개념을 이해해야 합니다.

서비스 등록(service registration): 서비스가 디스커버리 에이전트에 등록하는 방법입니다.
클라이언트 서비스 주소 검색(client lookup of service address): 서비스 클라이언트가 서비스 정보를 검색하는 방법입니다.
정보 공유(information sharing): 노드 간 서비스 정보를 공유하는 방법입니다.
상태 모니터링(health monitoring): 서비스가 서비스 디스커버리에 상태를 전달하는 방법입니다.

서비스 디스커버리의 주요 목표는 서비스의 물리적 위치를 수동을 구성할 필요 없이 위치를 알려줄 수 있는 아키텍처를 구축하는 것입니다.

서비스 인스턴스는 시작할 때 서비스 검색 인스턴스가 자신을 액세스하는 데 사용할 물리적 위치, 경로, 포트를 등록합니다. 서비스의 각 인스턴스에는 고유 IP 주소와 포트가 있지만 동일한 서비스 ID로 등록됩니다.

이때, 서비스 ID는 동일한 서비스 인스턴스 그룹을 고유하게 식별하는 키입니다.

여기서보면, 서비스 디스커버리의 인스턴스가 여러 개 있는데 서비스는 일반적으로 하나의 서비스 디스커버리 인스턴스에만 등록합니다.

서비스 인스턴스 관련 데이터를 클러스터 내 다른 노드에 전달하는 데이터 전파 방법으로 P2P 모델을 사용합니다.

마지막으로 각 서비스 인스턴스는 자기 상태를 서비스 디스커버리 서비스에 푸시(push)하거나 가져옵니다(pull). 정상 상태를 전달하지 못한 서비스는 가용 서비스 인스턴스 풀에서 제거됩니다. 이러한 방식을 Health Check라고 합니다.

클라이언트는 다른 서비스 인스턴스 정보를 캐싱할 수 있습니다.

만약 캐싱하지 않고 서비스 디스커버리 엔진에만 의존하면 어떻게 될까요?

이것은 서비스 디스커버리 엔진에 완전히 의존하기 때문에 단일 장애 지점으로 인해서 취약점이 될 수 있습니다.

이후 더욱 견고한 방법으로 클라이언트 측 로드 밸런싱(client-side load balancing)으로 알려진 방법을 사용합니다.

이 매커니즘은 존(zone)별 또는 라운드 로빈(round robin)같은 알고리즘을 사용합니다.

⚡️ 용어 정리 ⚡️

서비스 클라이언트(service client): 다른 서비스의 기능이나 데이터를 요청하는 마이크로서비스나 애플리케이션 컴포넌트

서비스 프로바이더(service provider): 요청을 받아 처리하고 응답하는 마이크로 서비스나 애플리케이션 컴포넌트

해당 사진에서 착각하면 안되는 점은 여기서 보는 클라이언트 애플리케이션은 웹 서버와 같은 클라이언트를 의미하는 것이 아닙니다. 서비스 서버를 의미하는 것으로 느슨한 결합으로 연결되어 있는 다른 외부 서비스 서버를 호출하는 클라이언트 서버를 의미합니다.

동작을 정리해봅시다.

서비스 소비자(클라이언트)가 요청하는 모든 인스턴스를 위해 디스커버리 서비스와 소통한 후 데이터를 서비스 소비자의 머신 로컬에 저장합니다.
클라이언트가 서비스를 호출할 때마다 서비스 소비자는 캐시에서 서비스 위치 정보를 검색합니다. 일반적으로 클라이언트 측 캐싱은 서비스 호출이 여러 서비스 인스턴스에 분배되도록 라운드 로빈 부하 분산 알고리즘처럼 단순한 알고리즘을 사용합니다.
클라이언트는 주기적으로 서비스 디스커버리 서비스와 소통해서 서비스 인스턴스에 대한 캐시를 갱신합니다.
클라이언트 캐시는 궁극적으로 일관적(eventually consistent)이지만 클라이언트가 서비스 디스커버리 인스턴스에 접속할 때 비정상 서비스 인스턴스를 호출할 위험은 항상 존재합니다.

예시로, 라이선싱 서비스와 조직 서비스를 가지고 동작하는 그림을 제시해주었는데 아래와 같습니다.

그림만으로 충분히 이해가 가능하므로 넘어가겠습니다.

3. 스프링 유레카 서비스 구축

여기서부터는 코드 설명과 함께 유레카 서비스 구축하는 방법을 제시하고 있습니다. 이전과 동일하게 코드에 대한 자세한 설명은 넘어가고, 필요한 부분만 적어놓겠습니다.

우선, 스프링 유레카 서버를 구축하기 위해서 스프링 부트로 프로젝트를 만들어 줍니다.

일련의 작업을 통해서 서비스 구축을 할텐데 이것은 일반적인 스프링 부트 프로젝트 구축과 동일합니다.

여기서 중요한 점은 Dependencies에 어떠한 의존성을 추가하게 되면서 유레카 서비스가 구축되는지를 봐야합니다.

Spring Boot Actuator
Eureka Server
Config Client

하나씩 설명을 통해서 살펴봅시다.

Spring Boot Actuator

설명: Spring Boot Actuator는 스프링 부트 애플리케이션 상태를 모니터링하고 관리하는데 도움이 되는 도구입니다.
역할:
- 애플리케이션의 건강 상태(Health Check), 메트릭(Metrics), 환경 속성(Environment Properties) 등을 파악할 수 있게 해줍니다.
- 유레카 서버에 서비스를 등록할 때, 애플리케이션 건강 상태를 주기적으로 확인하여 서비스의 가용성을 관리하는 데 사용됩니다.
- Actuator의 /health 엔드포인트는 유레카 서버가 클라이언트의 상태를 확인하는 데 사용될 수 있습니다.

⚡️ 용어 정리 ⚡️

Metrics

정의: 메트릭은 애플리케이션의 성능, 자원 사용량, 동작 상태 등 다양한 측정 가능한 데이터를 의미합니다.

목적: 메트릭을 수집하고 분석함으로써, 애플리케이션의 성능을 모니터링하고, 문제가 발생했을 때 빠르게 진단할 수 있으며, 시스템의 전반적인 상태를 이해할 수 있습니다.

예시: HTTP 응답 수, 응답 시간, 데이터베이스 접근 시간, CPU 사용률, 메모리 사용량 등이 예시입니다.

Environment Properties

정의: 환경 속성은 애플리케이션을 실행하는 데 필요한 구성 정보를 의미합니다. 이는 애플리케이션의 설정 파일, 시스템 환경 변수, 명령줄 인자 등 다양한 소스에서 올 수 있습니다.

목적: 환경 속성을 확인함으로써, 애플리케이션의 현재 구동 상태를 이해하고, 필요한 경우 적절한 조정을 할 수 있습니다.

예시: 데이터베이스 연결 문자열, 외부 API 엔드포인트, 애플리케이션 로그 레벨 설정 등이 예시입니다.

Eureka Server

설명: Eureka Server는 넷플릭스(Netflix)에서 개발한 서비스 디스커버리(Service Discovery) 도구입니다.
역할:
- 마이크로서비스 주소를 관리하고 서비스 디스커버리를 가능하게 합니다.
- 마이크로서비스들은 유레카 서버에 자신을 등록하고, 필요할 때 다른 서비스의 위치를 조회할 수 있습니다.
- 유레카 서버는 등록된 서비스 목록을 관리하고, 서비스간의 통신을 위한 중앙화된 레지스트리 역할을 수행합니다.

Config Client

설명: Config Client는 스프링 클라우드 컨피그(Spring Cloud Config)와 통합되어, 외부 구성 저장소에서 구성 정보를 가져오는 클라이언트입니다.
역할:
- 외부에 설정된 구성 정보를 애플리케이션에 동적으로 로드하는 데 사용됩니다.
- 유레카 서버와 같은 마이크로서비스가 구성 정보를 변경할 때마다 서버를 재시작하지 않고도 새로운 설정을 반영할 수 있습니다.
- 마이크로서비스의 설정을 중앙화하고 관리하는 데 도움이 되며, 환경에 따라 다른 설정을 적용하는 것을 최소화합니다.

정리하자면,
1. 클라우드 컨피그 서버의 클라이언트가 되기 위해서 Config Client의 의존성을 추가하고
2. 디스커버리의 기능을 수행하기 위해서 유레카 의존성을 추가하며
3. 디스커버리의 기능을 원할하게 수행하기 위한 보조 도구로 Actuator 의존성을 추가하는 것입니다.

구축하는 과정 중에 선택사항이 있는데, 컨피그 서버를 서비스 디스커버리에 등록할지, 안한지를 결정해야 합니다.

유레카 서버에 컨피그 서버를 등록하는 경우의 장단점은 아래와 같습니다.

장점

서비스 디스커버리: 컨피그 서버가 유레카 서버에 등록되면, 클라이언트 서비스는 유레카를 통해 컨피그 서버의 위치를 자동으로 찾을 수 있습니다.
부하 분산: 여러 인스턴스의 컨피그 서버가 유레카에 등록되면, 클라이언트 요청은 이러한 인스턴스 간에 분산될 수 있습니다. 이는 고가용성과 부하 분산을 지원합니다.
중앙집중식 관리: 모든 서비스가 유레카에 등록되면, 서비스 관리가 중앙집중화되고 통합적으로 이루어질 수 있습니다.

단점
1. 초기 구성 복잡성: 컨피그 서버가 시작될 때 유레카 서버에 등록하기 전에 자신의 구성을 로드해야 합니다. 이는 시작 과정이 복잡해질 수 있음을 의미합니다.
2. 종속성 문제: 컨피그 서버가 유레카 서버에 의존하게 되면, 유레카 서버에 문제가 발생했을 때 컨피스 서버의 가용성에 영향을 줄 수 있습니다.

여기서 단점의 1번에 대해서는 정확히 이해가 되지는 않습니다만 순환 의존성 문제가 발생할 수 있다는 것은 설명할 수 있을 것 같습니다.

컨피그 서버가 유레카 서버에 의존하게 되면, 컨피그 서버가 시작될 때 유레카 서버와의 연결 및 등록 과정이 필요합니다.
유레카 서버가 컨피그 서버에 의존하는 환경에서는 유레카 서버의 설정 변경이 컨피그 서버를 통해 관리되어야 할 수 있어야 합니다.
이로 인해서 순환 의존성 문제를 야기할 수 있습니다.

유레카에 등록된 서비스가 표시되는 데 최대 30초가 소요됩니다.
유레카는 서비스를 사용할 준비가 되었다고 알리기 전에 "10초 간격으로 연속 3회 ping"을 보내서 상태 정보를 확인해야 하기 때문입니다.

서비스 서버에서 유레카 서비스를 활성화하고 싶다면 @EnableEurekaServer 어노테이션을 사용하면 됩니다.

4. 스프링 유레카에 서비스 등록

먼저, 유레카의 클라이언트로 등록하기 위해서 의존성을 추가해줘야 합니다.

<dependency>
	<groupId>org.springframework.cloud</groupId>
    <artifactId>
    	spring-cloud-starter-netflix-eureka-client
  	</artifactId>
</dependency>

spring-cloud-starter-netflix-eureka-client 산출물에는 스프링 클라우드가 유레카 서비스와 상호 작용하는 데 필요한 JAR 파일들이 있습니다.

유레카에 등록된 모든 서비스는 애플리케이션 ID와 인스턴스 ID라는 두 가지 구성 요소와 연관되어 있습니다.

여기서, 애플리케이션 ID는 서비스 인스턴스의 그룹을 나타내는 것으로, 유레카에 등록될 서비스의 논리적 이름입니다.
이것은 각 서비스 서버의 설정 파일(bootstrap.yml)에서 설정할 수 있습니다.

인스턴스 ID는 각 서비스 인스턴스를 나타내고자 무작위로 생성된 숫자입니다.

다음은 유레카에 대한 서비스의 application.properties 파일 수정하기의 예시입니다.

eureka.instane.preferIpAddress = true ----- 서비스 이름 대신 서비스 IP 주소 등록
eureka.client.registerWithEureka = ture ----- 유레카 서비스 등록 여부
eureka.client.fetchRegistry = true ----- 레지스트리 사본을 로컬에 내려받기
eureka.client.serviceUrl.defaultZone = 
	http://localhost:8070/eureka/ ----- 유레카 서비스의 위치 설정

여기서 몇 가지 정리하고 가야되는 내용들이 보입니다.

먼저, 유레카는 호스트 이름(hostname)을 사용하여 접속하는 서비스를 등록한다는 점을 염두해두고 다음을 알아봅시다.

우선, defaultZone에 대해서 정리하고 가겠습니다.

defaultZone

eureka.client.serviceUrl.defaultZone 설정은 유레카 클라이언트가 유레카 서버와 통신하기 위해 사용하는 유레카 서버의 URL을 지정합니다.
여기서 http://localhost:8070/eureka/ 는 유레카 서버의 위치, 즉 유레카 서버의 IP 주소와 포트 번호를 포함한 URL입니다.
유레카 클라이언트는 이 URL을 사용하여 유라카 서버에 접속하고, 서비스 등록 및 조회를 수행합니다.

preferIpAddress 설정의 이유

eureka.instane.preferIpAddress를 true로 설정하면 유레카 클라이언트는 서비스를 유레카 서버에 등록할 때, 호스트 이름 대신 IP 주소를 사용합니다.
도커 환경에서, 컨테이너는 일반적으로 동적으로 할당된 내부 IP 주소를 가집니다. 컨테이너화된 환경에서는 각 컨테이너의 호스트 이름을 DNS를 통해 외부로 노출하고 관리하는 것이 어렵거나 불가능할 수 있습니다.
이러한 이유로, 컨테이너화된 환경에서는 IP 주소를 사용하는 것이 호스트 이름을 사용하는 것보다 더 신뢰할 수 있고 효과적인 방법입니다.

여기서, 왜 불가능할까요? 이어서 계속 정리를 하도록 하겠습니다. 일단 기억해둘 것은 앞서 Eureka가 서비스 집합을 검색할 때 애플리케이션 ID를 사용한다고 말했고 그것은 spring.application.name으로 등록한 것을 확인했습니다.

도커의 호스트 이름과 논리적 이름

도커 컨테이너는 시작할 때 임의의 호스트 이름을 할당받습니다. 이는 컨테이너 내부에서만 유효한 내부 호스트 이름입니다.
spring.application.name은 스프링 부트 애플리케이션의 논리적 이름을 설정하는 것으로, 유레카 서버에 서비스 등록할 때 사용되는 이름입니다.
유레카 서버는 이 논리적 이름을 사용하여 서비스를 식별하고 관리합니다. 하지만 서비스의 위치(호스트 이름 또는 IP 주소)를 결정할 때 preferIpAddress 설정에 따라 주소를 사용합니다.

즉, 유레카 서버는 요청을 통해 서비스를 확인할 것이고 서비스를 결정하고 나서부터는 어느 인스턴스로 보낼지 결정해야 합니다.

하지만, 여기서 호스트 이름을 사용한다면 각 컨테이너마다 각자의 도커 환경으로 동작하고 있고 임의의 호스트 이름을 배정받는 상황에서 그것을 통해 인스턴스 위치를 결정하는 것은 불가능에 가깝습니다.

따라서, IP 주소를 사용하여 서버의 IP 주소를 입력받도록 하는 것입니다.

여기까지 이해를 했다면, 한가지 더 의문점이 생겨야 합니다.

일단 임의의 호스트 네임을 통해서는 접근을 할 수 없어서 IP 주소를 사용해야 한다는 것인데 이 IP 주소를 통해서 바로 접근을 할 수 있냐가 문제입니다.

왜나면 컨테이너 환경에서 동작하는 애플리케이션이 확인하는 자신의 IP 주소는 기본적으로 사설 IP 주소이기 때문이죠.

정리를 해봅시다.

컨테이너 내부 IP 주소:
- 일반적으로, 컨테이너는 도커 또는 다른 컨테이너 오케스트레이션 도구(예: Kubernetes)에 의해 내부적으로 사설 IP 주소를 할당받습니다.
- 컨테이너 내부에서 실행되는 애플리케이션은 이 사설 IP 주소를 기본적으로 인식하게 됩니다.
서비스 등록과 네트워크 접근성:
- 유레카 클라이언트가 유레카 서버를 등록할 때, 컨테이터 내부 IP 주소를 사용하는 경우, 외부 네트워크 환경에서는 이 주소로 서비스에 접근할 수 없습니다.
- CI/CD 환경에서 일반적으로 사용하는 패턴은, 컨테이너를 호스트 네트워크에 연결하거나, 컨테이터의 포트를 외부에 노출시키는 것입니다. 이를 통해 외부에서 컨테이너에 접근할 수 있게 됩니다.
IP 주소 자동 등록:
- eureka.instance.preferIpAddress=true 설정을 사용하면, 유레카 클라이언트는 컨테이너의 IP 주소를 유레카 서버에 등록합니다.
- 이때, 컨테이너가 호스트 네트워크 모드로 실행되거나 적절한 네트워크 설정이 되어 있어야, 외부에서 컨테이너 서비스에 접근할 수 있습니다.
- 또는, 유레카 클라이언트는 특정 환경 변수나 구성을 통해 외부에서 접근 가능한 IP 주소로 유레카 서버에 등록할 수 있습니다.

여기까지 정리가 되었다면, 동작을 이해할 수 있을 것이다.

책의 필자는 preferIpAddress의 값을 항상 true로 설정한다고 합니다. 클라우드 기반의 마이크로서비스는 일시적(ephemeral)이고 무상태형(stateless)이므로 자유롭게 시작하고 종료할 수 있습니다. 따라서 IP 주소가 이러한 유형의 서비스에는 더 적합하다고 합니다.

마지막으로 확인해볼 프로퍼티는 eureka.client.fetchRegistry입니다.
해당 프로퍼티는 스프링 유레카 클라이언트에 레지스트리의 로컬 복사본을 가져오도록 지시합니다.

이 값을 true로 설정하면 레지스트리를 검색할 때마다 유레카 서비스를 호출하는 대신 레지스트리를 로컬에 캐싱하고, 클라이언트 소프트웨어는 30초마다 유레카 서비스에 레지스트리 변경 사항을 확인합니다.

조급해 하지 말자!

서비스가 유레카에 등록될 때 유레카는 서비스가 사용 가능해질 때까지 30초 동안 엔속 세 번의 상태를 확인하며 대기합니다. 이 워밍업 대기 시간 때문에 개발자가 서비스가 시작된 직후 서비스를 호출하면 유레카는 그 서비스가 등록되지 않은 것으로 혼동할 수 있습니다.

5. 서비스 디스커버리를 이용한 서비스 검색

서비스 디스커버리를 위해 서비스 소비자가 스프링 클라우드 로드 밸런서(Spring Cloud Load Balancer)와 상호 작용할 수 있는 세 가지 다른 스프링/넷플릭스 클라이언트 라이브러리가 있습니다.

로드 밸런서와 상호 작용하고자 추상화 수준이 가장 낮은 단계에서 높은 단계의 라이브러리 순으로 살펴볼 것입니다.

스프링 Discovery Client
REST 템플릿을 이용한 스프링 Discovery Client
넷플릭스 Feign 클라이언트

먼저, 호출할 API를 살펴봅시다.

@RequestMapping(value="/{licenseId}/{clientType}", method=RequestMethod.GET)
public License getLicensesWithClient(
@PathVariable("organizationId") String organizationId,
@PathVariable("licenseId") String licenseId, 
@PathVariable("clientType") String clitentType) {
	return licenseService.getLicense(licenseId, organizationId, clientType);
}

getLicense의 자세한 동작은 아래의 URL에서 확인해볼 수 있습니다.

Github: getLicense Service Code

5.1 스프링 Discovery Client로 서비스 인스턴스 검색

스프링 Discovery Client는 로드 밸런스(Spring Cloud Load Balancer)와 그 안에 등록된 서비스에 대해 가장 낮은 수준으로 접근할 수 있습니다.

즉, Discovery Client를 사용하면 스프링 클라우드 로드밸런서 클라이언트에 등록된 모든 서비스와 해당 URL을 쿼리할 수 있습니다.

디스커버리 클라이언트를 사용혀려면 먼저 다음 코드와 같이 @EnableDiscoveryClient 어노테이션을 추가해야 합니다.

@SpringBootApplication
@RefreshScope
@EnableDiscoveryClient ------ 유레카 Discovery Client를 활성화
public class LicenseServiceApplication {
	...
    ...
}

사용 예시를 한번 들여다 봅시다.

@Component
public class OrganizationDiscoveryClient {

	@Autowired
    public DiscoveryClient discoveryCleint; 
    
    public Organization getOrganization(String organizationId) {
    	RestTemplate restTemplate = new RestTemplate();
        List<ServiceInstance> instances = 	------ 조직 서비스의 모든 인스턴스 리스트를 얻는다.
        	discoveryClient.getInstances("organization-service");
            
        if (instancees.size() == 0) return null;
        String serviceUri = String.format(
        	"%s/v1/organization?%s", instances.get(0).getUri().toString(),
            organizationId);
            
        ResponseEntity<Organization> restExchange =
        	restTemplate.exchange(
            	serviceUri,
                HttpMethod.GET,
                null, Organization.class, organizationId);
                
        return restExchange.getBody();
    }
}

해당 코드를 살펴봅시다.

여기서 DiscoveryClient 클래스를 사용하여 스프링 클라우드 로드밸런서와 상호 작용하는데, 중요한 점은 등록된 모든 인스턴스를 검색하기 위해서 getInstances() 메서드를 사용한다는 것입니다.

이때 "서비스 키"를 전달하고 ServiceInstace 클래스틑 호스트 이름, 포트, URI 같은 서비스 인스턴스 정보를 보관합니다.

해당 방식은 몇 가지 문제점을 가지고 있는데,

스프링 클라우드 클라이언트 측 로드밸런서를 이용하지 못한다: Discovery Client를 직접 호출하면 서비스 리스트를 얻게 되지만, 호출할 서비스 인스턴스를 선정할 책임은 사용자에게 있습니다.
너무 많은 일을 한다: 코드에서 서비스를 호출하는데 사용될 URL을 생성해야 합니다. 이것은 작은 일이지만 코드를 적게 작성하면 디버그할 코드가 줄어듭니다.

코드에서 볼 수 있듯이 RestTemplate 클래스의 인스턴스를 "직접" 생성했습니다. @EnableDiscoveryClient를 통해 애플리케이션 클래스에서 스프링 Discovery Cleint를 활성화했다면, 스프링 프레임워크가 관리하는 모든 Rest 템플릿(template)은 해당 인스턴스에 로드 밸런서가 활성화된 인터셉터(interceptor)를 주입합니다. 이렇게 되면 RestTemplate 클래스로 URL를 생성하는 방식이 변경되는데, 직접적으로 RestTemplate을 인스턴스로 만들면 이 변경을 피할 수 있습니다.

5.2 로드 밸런서를 지원하는 스프링 Rest 템플릿으로 서비스 호출

로드 밸런서를 지원하는 RestTemplate 클래스를 사용하려면 스프링 클라우드의@LoadBalanced 어노테이션으로 RestTemplate 빈(bean)을 정의해야 합니다.

...

@SpringBootApplication
@RefreshScope
pulbic class LicenseServiceApplication {
	
    ...
    
    @LoadBalanced
    @Bean
    public RestTemplate getRestTemplate() {
    	return new RestTemplate();
	}
}

그 이후 사용할 때 URL을 정의하는 방식외에는 별 다른 차이점이 없고 표준 스프링 RestTemplate 클래스와 매우 유사합니다.

RestTemplate 호출에서 서비스 물리적 위치 대신 호출하려는 서비스의 유레카 서비스 ID를 사용하여 대상 URL을 생성해야 합니다.

...

@Component
public class OrganizationRestTemplateClient {
	@Autowired
    RestTemplate restTemplate;
    
    public Organization getOrganization(String organizationId) {
    	ResponseEntity<Organization> restExchange =
        	restTemplate.exchange(
            	"http://organization-service/v1/organization/{organizationId}",
            HttpMethod.GET, null,
            Organization.Class, organizationId);
        return restExchange.getBody();
    }
}

로드 밸런서를 지원하는 RestTemplate 클래스는 전달된 URL을 파싱하고 서버 이름으로 전달 된 것을 키로 사용하여 서비스의 인스턴스를 로드 밸런서에 쿼리합니다.

실제 서비스 위치와 포트는 개발자에게 완전히 추상화됩니다.

게다가 RestTemplate 클래스를 사용하면 스프링 클라우드 로드 밸런서는 서비스 인스턴스에 대한 모든 요청을 라운드 로빈 방식으로 부하 분산합니다.

5.3 넷플릭스 Feign 클라이언트로 서비스 호출

Feign 라이브러리는 REST 서비스를 호출하는 데 다른 접근 방식을 취합니다.

이 방식을 사용하려면 개발자는 먼저 자바 인터페이스를 정의한 후 스프링 클라우드 로드 밸런서가 호출할 유레카 기반 서비스를 매핑하기 위해 스프링 클라우드 어노테이션들을 추가해야 합니다.

@SpringBootApplication
@EnableFeignClients	------	코드에서 Feign 클라이언트를 사용하려고 추가합니다.
public class LicenseServiceApplication {
	...
    ...
}

...

@FeignClient("organization-service")	-----	Feign에 서비스를 알려 줍니다.
	public interface OrganizationFeignClient {
    	@RequestMapping(
        	method=RequestMethod.GET,
            value="/v1/organization/{organizationId}",
            consumes="application/json")
        Organization getOrganization(
        	@PathVariable("organizationId")
            String organizationId);
}