6장. 서비스 디스커버리

분산 아키텍처에서는 호스트 이름과 머신이 위치한 IP 주소를 파악하는 것이 필수적이다. 이 개념은 분산 컴퓨팅의 초기부터 사용되었으며, '서비스 디스커버리'라는 이름으로 공식화되었다. 서비스 디스커버리는 애플리케이션에서 사용하는 원격 서비스 주소를 포함하는 간단한 프로퍼티 파일을 관리하는 방식부터, UDDI 저장소와 같은 정교하고 구조화된 접근 방식까지 다양한 형태로 구현될 수 있다.

• 수펑 확장 (horizontal scaling or scale out): 이 패턴은 일반적으로 애플리케이션 아키텍처에서 클라우드 환경 내 서비스 인스턴스와 컨테이너 수를 늘리는 등 추가적인 조정을 필요로 한다.
• 회복성 (resiliency): 이 패턴은 비즈니스에 영향을 주지 않으면서 아키텍처와 서비스 내부에서 발생한 문제를 효과적으로 완화하는 능력을 의미한다. 마이크로서비스 아키텍처에서는 특정 서비스의 문제가 전체 시스템으로 확산되어 사용자에게 영향을 미치는 것을 방지하기 위해 각별한 주의가 필요하다.

첫 번째, 서비스 디스커버리를 사용하면 애플리케이션 팀이 해당 환경에서 실행 중인 서비스 인스턴스를 손쉽게 수평 확장할 수 있는 장점이 있다. 서비스 소비자는 서비스 인스턴스의 물리적 위치를 알지 못하고, 서비스는 추상화되어 제공된다. 이로 인해 새로운 서비스 인스턴스는 가용 서비스 풀에 동적으로 추가되거나 제거될 수 있다.

 

서비스 소비자를 중단하지 않고 서비스를 확장하거나 축소할 수 있는 능력은 매우 매력적인 개념이다. 모놀리식 싱글 테넌트 애플리케이션을 구축하는 데 익숙한 개발 팀은 종종 더 큰 하드웨어를 추가하는 수직 확장 방식만을 고려하지만, 서비스 디스커버리를 통해 더 많은 서버를 추가하는 수평 확장이 훨씬 강력한 접근 방식이 될 수 있음을 깨닫게 된다.

 

모놀리식 아키텍처에서는 개발 팀이 필요한 용량보다 더 많은 용량을 초과 구매하는 경우가 많다. 이때 용량 증가는 급격하게 이루어지며, 부드럽고 안정적인 확장은 드물다. 예를 들어, 휴일 시즌에 전자 상거래 사이트의 트래픽이 급증하는 상황을 생각할 수 있다. 그러나 마이크로서비스 아키텍처에서는 필요에 따라 서비스 인스턴스를 동적으로 확장할 수 있다. 서비스 디스커버리는 이러한 확장을 추상화하여, 서비스 소비자가 배포 과정에 영향을 받지 않도록 돕는다.

 

두 번째로, 서비스 디스커버리의 또 다른 장점은 애플리케이션의 회복성을 높여준다는 점이다. 만약 마이크로서비스 인스턴스가 비정상적이거나 사용할 수 없는 상태가 되면, 대부분의 서비스 디스커버리 엔진은 해당 인스턴스를 가용 서비스 목록에서 제외시킨다. 서비스 디스커버리 엔진은 비가용 상태인 서비스를 우회하여 요청을 라우팅함으로써, 다운된 서비스로 인한 피해를 최소화한다.

 

6.1 서비스 위치 확인

애플리케이션이 여러 서버에 분산된 자원을 호출할 때, 이 자원들의 물리적 위치를 알아야 한다. 클라우드 환경이 아닌 경우, 서비스의 위치 확인은 보통 DNS와 네트워크 로드 밸런서를 조합하여 해결된다. 전통적인 방식에서 애플리케이션은 다른 서버에 위치한 서비스를 호출할 때, 해당 서비스의 고유 경로와 DNS 이름을 사용하여 호출을 시도했다. DNS 이름은 상용 로드 밸런서인 F5나 HAProxy와 같은 오픈 소스 로드 밸런서의 위치로 정의된다.

 

전통적인 시나리오에서, 서비스 소비자가 요청을 보내면 로드 밸런서는 라우팅 테이블에 있는 서버 목록에서 하나의 서버를 선택하여 요청을 전달한다. 이 목록은 서비스를 호스팅하는 여러 서버들로 구성되어 있으며, 로드 밸런서는 이를 기반으로 트래픽을 분산시킨다.

 

기존 방식에서는 서비스 인스턴스가 고정된 수의 애플리케이션 서버에 배포되었으며, 서버 수는 변하지 않고 영속적으로 유지되었다. 즉, 서비스 호스팅을 위한 애플리케이션 서버는 늘어나거나 줄어들지 않았고, 서버가 고장 나면 동일한 IP 주소와 구성으로 복구되었다. 고가용성을 위해 보조 로드 밸런서는 주 로드 밸런서의 상태를 확인하기 위해 핑 신호를 보내고, 주 로드 밸런서가 동작하지 않으면 보조 로드 밸런서가 활성화되어 주 로드 밸런서의 IP 주소를 이어받아 요청을 처리했다.

 

이러한 모델은 사방이 벽으로 둘러싸인 회사 데이터 센터 안에서 실행되는 애플리케이션과 고정적인 서버에서 실행되는 비교적 적은 수의 서비스에서 잘 동작하지만 클라우드 기반의 마이크로 서비스 애플리케이션에서는 잘 동작하지 않는다.

• 고가용성 로드 밸런서를 만들 수 있더라도 전체 인프라스트럭처에서 보면 단일 장애 지점이다:
• 서비스를 하나의 로드 밸런서 클러스터에 집중시키면 여러 서버에 부하를 분산하는 인프라스트럭처의 수평 확장 능력이 제한된다: 많은 상용 로드 밸런서는 이중화 모델과 라이선싱 비용에 의한 제약을 받는다. 대부분의 상용 로드 밸런서는 핫스왑 모델을 사용하여 하나의 서버만 로드를 처리하고, 다른 서버는 주 로드 밸런서가 다운될 경우에만 페일오버를 담당하는 구조로 설계된다. 이는 하드웨어의 제약에 따라 제한되며, 고정된 용량에 맞추어진 라이선싱 모델을 제공하기 때문에 유연한 확장성이나 가변적인 로드 처리에는 한계가 있다.
• 전통적인 로드 밸런서 대부분은 고정적으로 관리된다: 이 로드 밸런서들은 서비스의 신속한 등록과 취소를 지원하지 않으며, 중앙 집중식 데이터베이스를 사용하여 경로 규칙을 저장한다. 새로운 경로를 저장하려면 대개 공급업체의 독점적인 API를 사용해야 하므로, 서비스의 동적 등록 및 취소가 제한적이고, 확장성이나 유연성이 부족하다.
• 로드 밸런서가 프록시 역할을 하므로 서비스 소비자 요청을 물리적 서비스에 매핑되어야 한다: 이 변환 계층은 수동으로 서비스 매칭 규칙을 정의하고 배포해야 하므로 서비스 인프라스트럭처의 복잡성을 증가시킨다. 또한 전통적인 로드 밸런서 시나리오에서는 새로운 서비스 인스턴스가 시작될 때 로드 밸런서에 자동으로 등록되지 않아, 추가적인 관리 작업이 필요하다.

이 네 가지 이유로 로드 밸런서를 비판할 필요는 없다. 로드 밸런서는 중앙 집중식 네트워크 인프라스트럭처로 처리할 수 있는 대부분의 애플리케이션 크기와 규모를 가진 기업 환경에서 효과적으로 작동한다. 또한, 로드 밸런서는 SSL 종료 처리와 서비스 포트 보안 관리에서 중요한 역할을 계속해서 수행한다. 특히, 로드 밸런서는 백엔드 서버에 대한 접근을 제한하여 보안을 강화하는데 도움을 주며, 이러한 최소 네트워크 접근은 PCI 규정 준수와 같은 산업 표준 인증 요구 사항을 충족하는데 중요한 요소로 작용한다.

 

하지만 대규모 트랜잭션과 이중화 처리가 필요한 클라우드 환경에서는 중앙 집중식 네트워크 인프라스트럭처가 효율적으로 확장되지 않으며, 비용 효율성도 낮아 제대로 작동하지 않는다. 클라우드에서는 수많은 서비스 인스턴스가 동적으로 생성되고 종료되기 때문에 중앙 집중식 시스템은 이러한 빠른 변화에 적응하기 어렵고, 이로 인해 관리의 복잡성과 비용이 증가할 수 있다.

 

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

클라우드 기반 마이크로서비스 환경에서 해결책은 아래와 같은 특성을 가진 서비스 디스커버리 메커니즘을 사용하는 것이다.

• 고가용성 (highly available): 서비스 디스커버리는 서비스 디스커버리 클러스터 내 노드 간의 서비스 검색 정보를 공유하는 핫 클러스터링 환경을 지원해야 한다. 만약 한 노드가 가용하지 않으면, 클러스터 내 다른 노드가 그 역할을 대신하여 서비스 중단을 방지한다. 클러스터는 고가용성, 안정성, 확장성을 제공하기 위해 동일한 구성을 갖고 협력하는 서버 인스턴스들의 그룹으로 정의할 수 있다. 로드 밸런서와 통합된 클러스터는 페일오버 기능을 통해 서비스 중단을 막고, 세션 복제 기능을 통해 세션 데이터를 유지하며 안정적인 서비스를 제공할 수 있다.
• P2P (peer-to-peer): 서비스 디스커버리 클래스터의 모든 노드는 서비스 인스턴스의 상태를 상호 공유한다.
• 부하분산 (load balanced): 서비스 디스커버리는 요청을 동적으로 분산시키며, 관리 중인 모든 서비스 인스턴스에 이를 분배해야 한다. 이를 통해 서비스 디스커버리는 초기 웹 애플리케이션 구현에서 사용되었던 고정적이고 수동으로 관리되던 로드 밸런서를 대체하는 역할을 한다. 서비스 디스커버리는 자동으로 서비스 인스턴스를 탐지하고, 트래픽을 적절하게 분산시키기 때문에 더 유연하고 확장성이 높은 아키텍처를 가능하게 한다.
• 회복성 (resilient): 서비스 디스커버리 클라이언트는 서비스 정보를 로컬에 캐싱해야 한다. 로컬 캐싱은 서비스 디스커버리 기능이 점차적으로 저하될 가능성을 고려한 것이다. 이 방식 덕분에 서비스 디스커버리가 가용하지 않더라도 애플리케이션은 여전히 작동할 수 있으며, 로컬 캐시에서 저장된 정보를 기반으로 서비스를 찾아 실행할 수 있다. 이를 통해 서비스 디스커버리 시스템에 문제가 발생해도 애플리케이션의 연속성과 안정성이 보장된다.
• 결함 내성 (falut tolerant): 서비스 디스커버리는 비정상적인 서비스 인스턴스를 탐지하면 해당 인스턴스를 가용 서비스 목록에서 자동으로 제거해야 한다. 이를 통해 클라이언트 요청이 정상적인 서비스 인스턴스로만 전달될 수 있다. 이 과정은 서비스 모니터링을 통해 자동으로 이루어져야 하며, 사람의 개입 없이 시스템이 문제를 탐지하고 조치를 취할 수 있어야 한다. 이와 같은 자동화된 처리는 시스템의 신뢰성과 효율성을 높이며, 다운타임을 최소화할 수 있다.

 

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

대게 이러한 일반적인 개념은 모든 서비스 디스커버리 구현체에 적용된다.

• 서비스 등록: 서비스가 디스커버리 에이전트에 등록하는 방법이다.
• 클라이언트의 서비스 주소 검색: 서비스 클라이언트가 서비스 정보를 검색하는 방법이다.
• 정보 공유: 노드 간 서비스 정보를 공유하는 방법이다. 
• 상태 모니터링: 서비스가 서비스 디스커버리에 상태를 전달하는 방법이다.

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

일반적으로 서비스 디스커버리 인스터스 앞에 로드 밸런서를 두지 않는다.

 

서비스 인스턴스는 시작할 때 서비스 검색 인스턴스가 자신을 액세스하는데 사용할 물리적 위치, 경로, 포트를 등록한다. 서비스의 각 인스턴스에는 고유 IP 줏와 포트가 있지만 동일한 서비스 ID로 등록된다. 이때 서비스 ID는 동일한 서비스 인스턴스 그룹을 고유하게 식별하는 키일 뿐이다.

 

서비스 디스커버리에서는 보통 하나의 서비스 디스커버리 인스턴스에만 서비스가 등록된다. 대부분의 서비스 디스커버리 구현체는 P2P 모델을 사용하여 서비스 인스턴스와 관련된 데이터를 다른 노드로 전파한다. 이 전파 방식은 서비스 구현체에 따라 달라지며, 하드코딩된 서비스 목록을 사용하거나, gossip 프로토콜과 같은 멀티캐스트/전염식 프로토콜을 통해 클러스터 내의 변경 사항을 다른 노드들이 인식할 수 있게 한다. 이러한 전파 방식은 서비스 디스커버리 시스템이 동적으로 확장되거나 변경될 때 중요한 역할을 한다.

 

마지막으로, 각 서비스 인스턴스는 자신의 상태를 서비스 디스커버리 서비스에 푸시하거나 가져옵니다. 만약 서비스가 정상 상태를 전달하지 못하면, 해당 서비스는 가용 서비스 인스턴스 풀에서 제거됩니다. 서비스 디스커버리에 등록된 후, 서비스는 자신의 기능을 사용하려는 애플리케이션이나 서비스에서 호출할 수 있도록 준비가 됩니다. 물론, 클라이언트가 서비스를 발견할 수 있는 다른 방식들도 존재할 수 있습니다. 이러한 방식들은 서비스 디스커버리 시스템의 특성이나 요구 사항에 따라 달라질 수 있습니다.

 

처음 접근 방식은 클라이언트가 서비스 디스커버리 엔진에만 전적으로 의존하여, 서비스를 호출할 때마다 서비스의 위치를 확인하는 방식입니다. 이 방법을 사용하면, 서비스 디스커버리 엔진은 각 서비스 호출 시마다 등록된 마이크로서비스 인스턴스를 확인합니다. 하지만 이 방식은 서비스 클라이언트가 서비스를 찾고 호출하는 데 있어 서비스 디스커버리 엔진에 의존하게 되어, 엔진에 문제가 생기면 서비스 호출이 중단될 수 있기 때문에 취약한 방법입니다.

 

더욱 견고한 접근 방법은 클라이언트 측 로드 밸런싱으로 알려진 방법을 사용하는 것이다. 이 매커니즘은 존 별 또는 라운드 로빈 같은 알고리즘을 사용하여 호출할 서비스의 인스턴스를 호출한다. 라운드 로빈 알고리즘식 로드 밸런싱을 이야기할 때 우리는 클라이언트 요청을 여러 서버에 분산시키는 방법을 의미한다. 이 방법은 클라이언트 요청을 차례로 각 서버에 전달하는 것이다. 유레카와 함께 클라이언트 측 로드 밸런싱을 사용하는 장점은 서비스 인스턴스가 다운되면, 인스턴스가 레지스터리에서 제거된다는 것이다. 이 작업이 완료되면 클라이언트 측 로드 밸런서는 레지스터리 서비스와 지속적으로 통신하여 자동으로 레지스트리를 업데이트한다.

 

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

서비스를 호출하는 과정에서 서비스 호출이 실패하면 로컬에 있는 서비스 디스커버리 캐시가 무효화되고 서비스 디스커버리 클라이언트는 서비스 검색 에이전트에서 항목 갱신을 시도한다.

 

6.2.2 스프링과 넷플릭스 유레카를 사용한 서비스 디스커버리

스프링 클라우드와 넷플릭스 유레카의 서비스 디스커버리 엔진을 사용하여 서비스 디스커버리 패턴을 구현한다. 클라이언트 측 로드 밸런싱을 위해 스프링 클라우드 로드 밸런서를 사용한다.

 

라이선싱 서비스는 호출을 받으면 지정된 조직 ID와 연관된 조직 정보를 검색하기 위해 조직 서비스를 호출한다.

 

조직 서비스의 실제 위치는 서비스 디스커버리 레지스트리에 저장된다. 예를 들어, 조직 서비스의 두 인스턴스를 서비스 디스커버리 레지스트리에 등록한 후, 클라이언트 측 로드 밸런싱을 사용하여 각 서비스 인스턴스에서 레지스트리를 검색하고 이를 캐시한다.

1. 서비스 부트스트래핑 시점에서 라이선싱 및 조직 서비스는 유레카 서비스에 등록한다. 이 등록 과정에서 시작하는 서비스의 서비스 ID와 해당 서비스 인스턴스의 물리적 위치 및 포트 번호를 유레카가 알려준다.
2. 라이선싱 서비스가 조직 서비스를 호출할 때 스프링 클라우드 로드 밸런서를 사용하여 클라이언트 측 로드 밸런싱을 제공한다. 이 로드 밸런서는 유레가 서비스에 접속하여 서비스 위치 정보를 검색하고 로컬에 캐시한다.
3. 스프링 클라우드 로드 밸런서는 유레카 서비스를 주기적으로 핑 (push)해서 로컬 캐시의 서비스 위치를 갱신한다.

이제 새로운 조직 서비스 인스턴스는 라이선싱 서비스의 로컬에서 볼 수 있고 비정상 인스턴스는 로컬 캐시에서 제거된다.

 

6.3 스프링 유레카 서비스 구축

스프링 클라우드 컨피그 서비스처럼 스프링 클라우드 유레카 서비스를 설정하려면 스프링 부트 프로젝트를 생성하고 어노테이션과 구성을 적용해야 한다.

 

※  예제 및 예제 생략

 

서비스를 로컬에서 테스트할 때 유레카가 등록된 서비스를 바로 알리지 않기 때문에, eureka.client.registerWithEureka와 같은 프로퍼티를 사용해야 한다. 기본적으로 유레카는 모든 서비스에 등록할 기회를 주고자 알리기 전에 기다린다. 로컬 테스트에서 이 프로퍼티를 사용하면 유레카 서비스가 시작되고 등록된 서비스를 표시하는 데 걸리는 시간을 단축할 수 있어 유용하다.

 

@EnableEurekaServer 어노테이션을 사용하면 유레카 서버를 활성화할 수 있다. 이를 통해 유레카 서비스를 시작할 수 있으며, 서비스 등록을 위해 유레카 서버를 실행해야 한다. 하지만 유레카 서버가 시작되었을 때 등록된 서비스가 없으므로, 먼저 스프링 클라우드 컨피그 서비스를 실행해야 한다. 그렇지 않으면 유레카 서버에서 에러가 발생할 수 있다.

이 문제를 피하려면 도커 컴포즈를 사용하여 여러 서비스를 동시에 실행할 수 있다. 도커 컴포즈는 여러 서비스의 실행 순서를 관리할 수 있으므로, 먼저 컨피그 서버를 실행하고 그다음 유레카 서버를 실행하여 의존성을 해결할 수 있다.

 

6.4 스프링 유레카에 서비스 등록

유레카에 등록된 서비스는 두 가지 주요 구성 요소인 애플리케이션 ID와 인스턴스 ID로 식별된다.

• 애플리케이션 ID는 서비스 인스턴스의 그룹을 나타낸다. 스프링 부트 마이크로서비스에서는 이 값이 spring.application.name 프로퍼티에 설정된 값으로 지정되며, 여러 인스턴스를 가진 서비스가 동일한 애플리케이션 ID를 공유하게 된다.
• 인스턴스 ID는 각 서비스 인스턴스를 고유하게 식별하기 위한 값으로, 서비스가 유레카에 등록될 때 자동으로 무작위로 생성된다. 이는 동일한 애플리케이션 ID를 가진 여러 인스턴스를 구분하는 데 사용된다.

eureka.client.registerWithEureka 프로퍼티는 조직 및 라이선싱 서비스가 유레카에 등록되도록 설정하는 역할을 한다. 이를 통해 해당 서비스가 유레카 서버에 자신의 존재를 알릴 수 있다.

반면, eureka.client.fetchRegistry 프로퍼티는 스프링 유레카 클라이언트가 레지스트리의 로컬 복사본을 가져오도록 지시한다. 이 값을 true로 설정하면, 클라이언트는 매번 유레카 서비스를 호출하는 대신 레지스트리를 로컬에 캐싱한다. 이후 클라이언트 소프트웨어는 30초마다 유레카 서버에 레지스트리 변경 사항을 확인하여 최신 정보를 동기화한다.

 

마지막으로, eureka.client.serviceUrl.defaultZone 프로퍼티는 클라이언트가 서비스의 위치를 확인할 때 사용하는 유레카 서비스 목록을 정의한다. 여러 유레카 서비스 주소를 쉼표(,)로 구분하여 추가할 수 있다. 하지만 이 장에서는 간편함을 위해 한 개의 유레카 서비스만 사용한다.

각 서비스는 부트스트랩 파일에서 앞서 정의한 모든 프로퍼티의 키-값 쌍을 선언할 수 있다. 그러나 목표는 구성 설정을 스프링 컨피그 서비스에 위임하는 것이다. 즉, 모든 구성 정보를 스프링 컨피그 저장소의 서비스 구성 파일에 등록하여 관리한다. 지금까지 부트스트랩 파일에는 애플리케이션 이름, 프로파일(필요한 경우), 그리고 스프링 클라우드 컨피그 URI만 포함되어 있었다.

 

유레카 서비스는 유레카 REST API와 유레카 대시보드를 제공한다.

 

6.4.1 유레카 REST API

※ 예제 및 예제 설명 생략

 

6.4.2 유레카 대시보드

※  예제 및 예제 설명 생략

 

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

라이선싱 서비스는 유레카를 이용하여 조직 서비스의 물리적 위치를 검색할 수 있다. 라이선싱 서비스는 유레카를 통해 조직 서비스의 위치를 직접적으로 알지 못해도, 유레카에서 제공하는 서비스 정보를 바탕으로 조직 서비스를 호출할 수 있다.

 

서비스 디스커버리를 구현하기 위해 서비스 소비자는 스프링 클라우드 로드 밸런서와 상호작용할 수 있는 세 가지 다른 스프링/넷플릭스 클라이언트 라이브러리를 사용할 것이다. 이를 통해 로드 밸런서와의 상호작용을 낮은 수준에서 높은 수준의 라이브러리로 점차적으로 설명할 것이다.

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

 

※  예제 및 예제 설명 생략

 

전달할 수 있는 클라이언트 타입은 아래와 같다.

• Discovery:  Discovery Client와 표준 스프링 RestTemplate 클래스를 사용하여 조직 서비스를 호출한다.
• Rest: 향상된 스프링 RestTemplate으로 로드 밸런서 (Spring Cloud Load Balancer)를 사용하는 서비스를 호출한다.
• Feign: 넷플릭스 Feign 클라이언트 라이브러리를 사용해서 로드 밸런서를 경유하여 서비스를 호출한다.

※  예제 및 예제 설명 생략

 

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

스프링 Discovery Client는 로드 밸런서 및 그 안에 등록된 서비스에 대해 가장 기본적인 수준으로 접근할 수 있는 방법을 제공한다. 즉, Discovery Client를 사용하면 스프링 클라우드 로드 밸런서 클라이언트에 등록된 모든 서비스와 해당 서비스의 URI를 쿼리할 수 있다.

 

※  예제 및 예제 설명 생략

 

@EnableDiscoveryClient는 스프링 클라우드에서 애플리케이션이 Discovery Client와 스프링 클라우드 로드 밸런서 라이브러리를 사용할 수 있도록 활성화하는 역할을 한다.

 

※  예제 및 예제 설명 생략

 

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

로드 밸런서를 지원하는 RestTemplate의 사용 예를 살펴보면, 스프링을 통해 로드 밸런서와 상호 작용할 수 있는 일반적 메커니즘 중 하나를 확인할 수 있다. 로드 밸런서를 지원하는 RestTemplate 클래스를 사용하려면, 스프링 클라우드의 @LoadBalanced 어노테이션으로 RestTemplate 빈을 정의해야 한다.

 

※  예제 및 예제 설명 생략

 

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

스프링 로드 밸런서를 지원하는 RestTemplate 클래스의 대안으로는 넷플릭스의 Feign 클라이언트 라이브러리가 있다. Feign 라이브러리는 REST 서비스를 호출하는 다른 접근 방식을 제공한다. 이 방식을 사용하려면, 개발자는 먼저 자바 인터페이스를 정의하고, 이후 스프링 클라우드 로드 밸런서가 호출할 유레카 기반 서비스를 매핑하기 위해 스프링 클라우드 어노테이션을 추가해야 한다. 인터페이스를 정의한 후에는 서비스를 추가하기 위해 추가적인 코드를 작성할 필요가 없다.

 

※  예제 및 예제 설명 생략