스프링 클라우드, 마이크로서비스 개발을 소개하면서 단일 애플리케이션을 MSA로 분리하여 개발하는 방법을 알아본다. 13장에서는 MSA의 개요를 알아보고 서비스 발견(discovery)를 알아볼 것이다. 이 때, 스프링 기반의 MSA를 등록하고 발견하기 위해 넷플릭스의 유레카 서비스 레지스트리 를 사용한다.

MSA 알아보기
서비스 레지스트리 생성하기
서비스 등록 및 발견하기

• 니모의 문피쉬와 같다.
• 각각의 문피쉬들이 모여 황새치, 문서, 배 등 재미있는 모양을 만들어낸다.
• 그러나 각각의 문피쉬는 자신만의 비늘, 지느러미, 아가미, 눈, 장기, 그리고 희망과 꿈을 가진다.

서비스의 아키텍처를 구성할 때 모든 서비스를 하나의 패키지에 담아 빌드하고 배포하는 방법

• 전체를 파악하기 어렵다
• 테스트가 더 어렵다
• 라이브러리 간의 충돌이 생기기 쉽다
• 확장 시에 비효율적이다
• 적용할 테크놀러지를 결정할 때도 애플리케이션 전체를 고려해야 한다(언어, 프레임워크..)
• 프로덕션으로 이양하기 위해 많은 노력이 필요하다
• 부분의 장애가 전체 서비스의 장애로 이어진다.(out of memory...)

• 쉽게 이해할 수 있다.
• 테스트가 쉽다
• 라이브러리 비호환성 문제가 생기지 않는다(덜하다)
• 독자적으로 규모를 조정할 수 있다
• 각 마이크로서비스에 적용할 테크놀러지를 다르게 선택할 수 있다
• 언제든 프로덕션으로 이양할 수 있다

참고
Nginx 공식문서 (https://www.nginx.com/blog/introduction-to-microservices/)

뭔가를 발견하거나 알아냈을 때 지르는 기쁨의 탄성.

마이크로서비스에서 서로를 찾을 때 사용되는 서비스 레지스트리의 이름

유레카는 모든 서비스의 중앙 집중 레지스트리로 작동한다.

유레카 자체도 마이크로서비스라고 생각할 수 있다.

모든 마이크로서비스는 유레카에 자신을 30초에 한 번씩 등록한다

other service가 유레카에서 'some service'란 이름으로 찾는다.

some service가 여러 개라면 리본이 인스턴스를 선택하고 해당 인스턴스를 사용한다.

클라이언트 측의 로드밸런서

중앙집중화된 로드밸런서와 비교해 장점을 가진다.

1. 클라이언트 수에 비례해 로드밸런서 크기가 조정된다.
2. 각 클라이언트에 가장 적합한 로드 밸런싱 알고리즘을 사용하도록 수정할 수 있다.

프로젝트명 service-registry

패키지 이름 taco

스프링 스타터 프로젝트 의존성 대화상자에 Spring Cloud Discovery를 확장, Eureka Server를 선택하고 Finish를 클릭.

<properties>
...
		<!-- 다른 버전의 스프링 클라우드를 사용하고 싶을 경우 변경 -->
		<spring-cloud.version>Hoxton.SR3</spring-cloud.version>
</properties>
...
<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
		</dependency>
...
</dependencies>
...
<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>${spring-cloud.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
</dependencyManagement>

...
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootAppliation
@EnableEurekaServer // 추가!
public class ServiceRegistryApplication {

	@Test
	public void contextLoads() {
	}

}

애플리케이션이 시작되는 부트스트랩 클래스인 ServiceRegistryApplication을 수정한다.

유레카 서버가 활성화된다.

여기까지 작업하고 앱을 시작하면 웹브라우저에서 유레카 대시보드가 나타난다.

대시보드에서 그 중 어떤 서비스 인스턴스가 유레카에 등록되었는지를 볼 수 있다. 서비스를 등록할 때 유레카 대시보드를 자주 보게 될 것이다.

유레카가 30초에 한번씩 예외 메시지를 출력하는 중인데, 아직 레지스트리를 완전하게 구성하지 않았기 때문이며, 유레카가 정상 동작하는 것은 맞다.

장애에 대비하기 위해 여러 개의 유레카 서버가 함께 동작하도록 하는 것이 안전하다.

따라서 기본적으로 유레카는 다른 유레카 서버로부터 서비스 레지스트리를 가져오거나 다른 유레카 서버의 서비스로 자신을 등록하기도 한다.

때문에 프로덕션 설정에서는 유레카를 두 대 이상 동작하게 된다. 그러나 개발 목적으로는 하나의 유레카 서버면 충분하다.

이 때 유레카 서버를 올바르게 구성하지 않으면 30초마다 예외 메시지를 출력한다. 유레카는 30초마다 다른 유레카 서버와 통신하면서 자신이 작동 중임을 알리고 레지스트리 정보를 공유하기 때문이다.

유레카 서버가 혼자임을 알도록 구성할 필요가 있다.

단일 유레카 서버 구성

server:
  port: 8761
  
eureka:
  instance:
    hostname: localhost
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

eureka.client.registerWithEureka, eureka.client.fetchRegistry는 유레카가 다른 유레카와 상호 작용하는 방법을 알려주는 속성이다. 두 속성의 기본값을 true로, 해당 유레카 서버가 다른 유레카 서버로부터 레지스트리 정보를 가져오게 할 것인지(fetchRegistry), 다른 유레카 서버의 서비스로 자신을 등록할 것인지(registerWithEureka)를 설정할 수 있다.

serviceUrl.defaultZone은 유레카 url을 말한다. 중괄호 안에 지정된 다른 속성값으로 대체되어 실 주소는 http://localhost:8761/eureka 가 된다.

자체 보존 모드 비활성화

server:
    enable-self-preservation: false

유레카 서버는인스턴스가 자신을 등록하고 등록 갱신 요청을 30초마다 전송하기를 기대한다. 일반적으로 세 번의 갱신기간(90초) 동안 서비스 인스턴스로부터 등록 갱신 요청을 받지 못하면 해당 서비스 인스턴스의 등록을 취소하게 된다. 만일 이렇게 중단되는 서비스가 임계값(threshold)을 초과하면 유레카 서버는 네트워크 문제가 생긴 것으로 간주하고 레지스트리에 등록된 나머지 서비스 데이터를 보존하기 위해 자체 보존(self-preservation) 모드가 된다. 따라서 추가적인 서비스 인스턴스의 등록 취소가 방지된다.

프로덕션 설정에서는 이 값을 true로 설정해 실제 네트워크 문제가 생겼을 때 나머지 활성화된 서비스들의 등록 취소를 방지할 수 있다.

개발 서버에서는 문제가 될 수 있으므로 이 값을 false로 한다. 인스턴스 상태가 자주 변경될 수 있는 개발환경에서 이 모드가 활성화된다면 중단된 서비스의 등록이 계속 유지되어 다른 서비스가 해당 서비스를 사용하려고 할 때 문제를 발생시킬 수 있기 때문이다.

대신 이 값을 false로 하면 아래와 같은 메시지가 출력될 것이다.

THE SELF PRESERVATION MODE IS TURNED OFF. THIS MAY NOT PROTEXT INSTANCE EXPIRY 
IN CASE OF NETWORK/OTHER PROBLEMS.

두 개 이상의 유레카 인스턴스를 구성하는 가장 간단한 방법은 application.yml 파일에 스프링 프로파일을 지정하는 것이다. 그리고 한 번에 하나씩 프로파일을 사용해서 유레카를 두번 시작시킨다.

# 기본 프로파일(공통)
eureka:
  client:
#    registerWithEureka: false 삭제
#    fetchRegistry: false 삭제
    serviceUrl:
      defaultZone: http://${other.eureka.host}:${other.eureka.port}/eureka/
---
# 프로파일1
spring:
  profiles: eureka-1
  application:
    name: eureka-1

server:
  port: 8761

eureka:
  instance:
    hostname: eureka1.tacocloud.com

# 프레임워크와 상관없이 공통 프로파일의 변수값을 대체하기 위한 용도
other:
  eureka:
    host: eureka2.tacocloud.com
    port: 8762

---
# 프로파일2
spring:
  profiles: eureka-2
  application:
    name: eureka-2

server:
  port: 8762

eureka:
  instance:
    hostname: eureka2.tacocloud.com

# 프레임워크와 상관없이 공통 프로파일의 변수값을 대체하기 위한 용도
other:
  eureka:
    host: eureka1.tacocloud.com
    port: 8762

지금까지 유레카 서버를 설정하고 등록했다면 이제 유레카 서비스 레지스트리에 등록할 마이크로서비스를 구성해보겠다.

ingredient-service 프로젝트에 의존성을 추가해준다.

pom.xml 파일에서 마우스 오른쪽 클릭 > Spring - Edit Starters 클릭 > Spring Cloud Discovery - Spring Discovery Client 선택 후 OK

// pom.xml
</dependencies>
	<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>
				spring-cloud-starter-netflix-eureka-client
			</artifactId>
	</dependency>
</dependencies>
// spring cloud version도 추가됨.
<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>Finchley.SR1</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
</dependencyManagement>

유레카 클라이언트 의존성을 추가하면 유레카를 이용해 서비스를 찾는데 필요한 모든 것이 자동으로 추가된다. (유레카의 클라이언트 라이브러리, 리본 로드 밸런서 등)

이렇게 되면 이 애플리케이션을 유레카 서비스 레지스트리의 클라이언트로 활성화시킬 수 있다. 애플리케이션이 시작되면 8761포트로 서비스하는 유레카 서버에 연결하고, UNKNOWN이라는 이름으로 유레카 애플리케이션에 자신을 등록한다.

유레카 클라이언트 속성 구성

서비스의 기본 이름인 UNKNOWN을 그대로 두면 유레카 서버에 등록되는 모든 서비스 이름이 같게 되므로 변경해보자.

spring:
    application:
        name: ingredient-service

이제 유레카 대시보드에 ingredient-service 라는 이름으로 서비스가 나타난다.

server:
    port: 0

서비스 포트의 충돌을 막기위해 포트를 0으로 설정한다. 서버 포트를 0으로 설정하면 각 서비스 애플리케이션이 시작될 때 포트 번호가 무작위로 선택된다.

eureka:
        client:
        service-url:
            defaultZone: http://eureka1.tacocloud.com:8761/eureka/,
                         http://eureka2.tacocloud.com:8762/eureka/

위 url의 포트로 리스닝하는 유레카 서버에 등록되도록 클라이언트가 구성된다. 장애 대비를 위해 두 개의 유레카 서버를 사용하도록 구성했다.

이렇게 되면 첫 번째 유레카 서버에 등록을 시도하고, 실패하면 두번째에 피어(peer)로 지정된 유레카 서버의 레지스트리에 등록을 시도하게 된다.

유레카를 사용하면 서비스를 사용하는 컨슈머 코드에 URL을 하드코딩하는 대신 서비스명을 적으면 된다.

덕분에 사용되는 서비스의 특정 인스턴스와 해당 컨슈머가 밀접하게 결합되는 것을 막고, 사용되는 서비스의 포스트나 포트가 변경되어도 해당 컨슈머가 정상 동작하도록 하는 장점이 있다.

컨슈머가 찾은 서비스의 인스턴스가 여러 개일 경우에는?

컨슈머 애플리케이션이 인스턴스를 선택할 필요없이 리본 클라이언트 로드밸런서가 하나의 서비스 인스턴스를 선택해준다.

유레카에서 찾은 서비스를 선택 및 사용하는 방법은 두 가지가 있다

A. 로드 밸런싱된 RestTemplate

B. Feign에서 생성된 클라이언트 인터페이스

이 중 어느 방법을 선택할지는 개인의 취향에 달려있다.

A-1. RestTemplate 사용해 서비스 사용하기

before

public Ingredient getIngredientById(String ingredientId) {
    return rest.getForObject(
        "http://localhost:8080/ingredients/{id}", 
        Ingredient.class, ingredientId);
}

after

// RestTemplateConfig.java
@Configuration
@Conditional(NotFeignAndNotWebClientCondition.class)
public class RestTemplateConfig {

  @Bean
  @LoadBalanced
  public RestTemplate restTemplate() {
    return new RestTemplate();
  }
...

// IngredientServiceClient.java
@Component
public class IngredientServiceClient {

  private RestTemplate rest;
  
  public IngredientServiceClient(@LoadBalanced RestTemplate rest) {
    this.rest = rest;
  }
  
  public Ingredient getIngredientById(String ingredientId) {
    return rest.getForObject(
        "http://ingredient-service/ingredients/{id}", 
        Ingredient.class, ingredientId);
  }
...
}

스프링 RestTemplate에서 HTTP GET 요청을 수행할 때는 before처럼 URL이 하드코딩 되어있었다.

RestTemplateConfig.java

로드밸런싱된 RestTemplate 빈을 선언하고, @Bean @LoadBalanced 을 메서드에 지정한다.

@LoadBalanced 는 두 가지 의미를 지닌다.

1. 현재의 RestTemplate이 리본을 통해서만 서비스를 찾는다는 것을 스프링 클라우드에 알려준다
2. 주입 식별자로 동작한다. 주입 식별자는 서비스 이름으로, getForObject()의 HTTP 요청에서 호스트와 포트 대신 사용할 수 있다.

IngredientServiceClient.java

식자재를 찾기 위해 로드 밸런싱된 RestTemplate를 사용하는 예시이다.

before과 달라지는 점은 아래와 같다.

1. 로드밸런싱된 RestTemplate을 필요로 하는 빈에 주입하고,
2. getIngredientById() 메서드에 호스트와 포트 대신 해당 서비스명을 사용하도록 변경한다.

이렇게 되면 (동작원리) 내부적으로 ingredient-service 라는 서비스 이름을 찾아서 인스턴스를 선택하도록 RestTemplate이 리본에 요청한다. 그리고 선택된 서비스 인스턴스의 호스트와 포트 정보를 포함하도록 리본이 URL을 변경한후 원래대로 RestTemplate이 사용된다.

ingredient-service 서비스의 컨트롤러(IngredientController.java)

@Controller
@RequestMapping("/ingredients")
public class IngredientController {

  private IngredientServiceClient client;

  public IngredientController(IngredientServiceClient client) {
    this.client = client;
  }
  
...

  @GetMapping("/{id}")
  public String ingredientDetailPage(@PathVariable("id") String id, Model model) {
    log.info("Fetched an ingredient from a RestTemplate-based service.");
    model.addAttribute("ingredient", client.getIngredientById(id));
    return "ingredientDetail";
  }
  
}

A-2. WebClient로 서비스 사용하기

11장에서 배운 WebClient가 HTTP 클라이언트를 제공하는 방법을 알아보았다. 리액티브 프로그래밍에 관심이 많다면 RestTemplate 대신 WebClient를 사용할 수 있다.

Flux와 Mono같은 리액티브 타입과 함께 동작하게 하려면, RestTemplate 을 사용했던 것과 같은 방법으로 WebClient를 로드 밸런싱된 클라이언트로 사용할 수 있다.

// WebClientConfig.java
@Configuration
public class WebClientConfig {

  @Bean
  @LoadBalanced
  public WebClient.Builder webClientBuilder() {
    return WebClient.builder();
  }
...
}

// IngredientServiceClient.java
@Service
@Profile("webclient")
public class IngredientServiceClient {

  private WebClient.Builder wcBuilder;
  
  public IngredientServiceClient(@LoadBalanced WebClient.Builder wcBuilder) {
    this.wcBuilder = wcBuilder;
  }
  
  public Mono<Ingredient> getIngredientById(String ingredientId) {  
    return wcBuilder.build()    
        .get()      
        .uri("http://ingredient-service/ingredients/{id}", ingredientId)    
        .retrieve().bodyToMono(Ingredient.class);
  }

B. Feign 클라이언트 인터페이스 정의하기

Feign 은 REST 클라이언트 라이브러리이며, 인터페이스를 기반으로 하는 방법을 사용해 REST 클라이언트를 정의한다.

간단히 말해서, 스프링 데이터가 리퍼지터리 인터페이스를 자동으로 구현하는 것과 유사한 방법을 사용한다.

의존성 추가

<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-openfeign</artifactId>
		</dependency>
</dependencies>

Feign 활성화

@Configuration
@EnableFeignClients
public class FeignClientConfig {
}

IngredientClient.java 인터페이스 정의

package tacos.ingredientclient.feign;

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import tacos.ingredientclient.Ingredient;

@FeignClient("ingredient-service")
public interface IngredientClient {

  @GetMapping("/ingredients/{id}")
  Ingredient getIngredient(@PathVariable("id") String id);
...
}

ingredient-service라는 이름으로 유레카에 등록된 서비스를 사용해 식자재를 가져오는 클라이언트를 작성하였다.

인터페이스만 정의하면 Feign이 런타임시에 이 인터페이스를 찾는다. 그리고 Feign이 자동으로 구현 클래스를 생성한 후 스프링 애플리케이션 컨텍스트에 빈으로 노출시킨다.

@FeignClient 어노테이션은 해당 클래스 내의 모든 메서드가 ingredient-service에 대한 요청임을 나타낸다. 내부적으로 ingredieng-service는 리본이 찾게 된다.

@GetMapping 어노테이션은 리본이 선택한 호스트와 포트의 /ingredients/{id} 경로로 HTTP GET 요청을 수행하게 된다.

ingredient-service 서비스의 컨트롤러(IngredientController.java)

RestTemplate로 사용하는 경우와 같다.

@Controller
@RequestMapping("/ingredients")
public class IngredientController {

  private IngredientClient client;

	@Autowired
  public IngredientController(IngredientClient client) {
    this.client = client;
  }
  
...
  
  @GetMapping("/{id}")
  public String ingredientDetailPage(@PathVariable("id") String id, Model model) {
    log.info("Fetched an ingredient from a Feign client.");
    model.addAttribute("ingredient", client.getIngredient(id));
    return "ingredientDetail";
  }
  
}

추가. Feign에는 자신의 어노테이션인 @RequestLine 과 @Param 이 있는데, 스프링 MVC의 @RequestMapping, @PathVariable과 거의 유사하다.

Feign, WebClient, RestTemplate 이중 어느 것을 사용하든 REST 클라이언트에서 특정 호스트 이름, 포트를 하드코딩하는 것을 막아준다.