서론
Hystrix 는 Netflix 에서 제공하는 Circuit breaker 모듈이다.
Circuit breaker는 차단기를 의미하는데, 전자회로에서 이상 전류의 발생을 중간에서 차단하는 장치이다. 비슷한 의미로 소프트웨어 애플리케이션에서도 사용되는데, 이상 현상이 있는 서비스에 대한 요청을 일시적으로 차단하여 이상 동작을 최소화하도록 처리하는 것을 말한다.
소프트웨어 애플리케이션의 Circuit breaker에 대한 내용은 http://martinfowler.com/bliki/CircuitBreaker.html에서 확인이 가능하다.
마이크로서비스 아키텍처에서는 Circuit breaker의 역할이 중요하다. 아키텍처 구조상 다양한 통신채널(Rest API 또는 Message bus 등)로 서로 통신을 하게 되는데, 이 과정에서 네트워크 문제 등으로 서로 간의 통신할 수 없는 경우가 많이 있다. 이럴 경우 연쇄적인 오류를 방지한다거나, 문제가 있는 서비스에 계속해서 요청하고 대기하는 등의 작업을 최소화할 필요가 있다.
Spring cloud에서는 Ribbon Loadbalancer와 함께 Hystrix를 이용한 Circuit breaker 를 사용하여 이러한 문제를 최대한 단순하게 처리할 수 있도록 제공하고 있다.
이번 포스트는 이 내용을 정리해보고자 한다.
이번 포스트에서 참고한 내용은 아래와 같다.
Calistaenterprise 블로그 : http://callistaenterprise.se/blogg/teknik/2015/04/15/building-microservices-with-spring-cloud-and-netflix-oss-part-2/
Josh Long의 Devoxx 2015 : https://www.youtube.com/watch?v=SFDYdslOvu8&list=WL&index=3
이번 포스트를 준비하면서 테스트한 환경은 아래와 같다.
- Configuration Server 와 Discover Server : 이전 포스트 참고
- JDK 8 : 1.8.0_65
- Intellij 15.0.3
- Gradle build : 2.10
- Spring IO : 2.0.1.RELEASE
- Spring Boot : 1.3.2
- Spring Cloud : Angel.SR6
- Lombok : 1.12.6
- IDEA Lombok plugin : 0.9.7
- Configuration server의 git 저장소 : https://github.com/roadkh/blog-cloud-sample-config.git
- yml 을 이용한 Property
- RabbitMQ : 3.6.0 (Docker 를 이용했으나, 직접 설치를 해도 상관이 없다)
기존 blog_02 브랜치와 비교하여 Repository 변경과 버전 변경이 약간 있다.
또한, dependency를 위한 repository가 기존의 jcenter(bintray)에서 maven central로 변경되었다.
스프링 프로젝트를 진행함에서는 bintray에는 최신 버전이 올라오지 않는 경우가 많이 발견되었다. 앞으로 스프링 프로젝트를 진행할 때는 Gradle 을 Build tool로 사용한다면, jcenter() 대신에 mavenCentral()을 사용해야 할 것 같다. 버전 변경은 maven central로 repository를 변경하면서 기존의 버전 문제가 없어져서 함께 업그레이드되었다.
기본 구성
이전 포스트와 같은 그림에 Hystrix 모듈이 추가되고 Turbine과 Hystrix Dashboard 가 추가되었다. 최종적으로는 위와 같은 형태를 보이게 된다.
Hystrix 적용
Hystrix 의 적용은 Composite API와 Edge server 에만 적용을 해보려고 한다.
우선은 amqp를 이용하지 않는 hystrix 를 먼저 적용을 해보자.
Edge server에는 기본적으로 Hystrix 모듈이 포함되어있다. Loadbalancer 를 처리하면 RibbonCommand를 사용하기 위해서 포함된 것으로 보인다. 따라서 Edge server에는 별다른 작업을 진행할 필요는 없다.
Composite API의 build.gradle 에 아래와 같이 hystrix dependency를 추가하자.
...
compile('org.springframework.cloud:spring-cloud-starter-hystrix')
...
뒤에 나올 hystrix-dashboard를 사용하기 위해서는 /hystrix.stream 이라는 RequestMapping이 필요한다 이를 위해서는 spring actuator 를 dependency를 추가해줘야 할 필요가 있다. 그런데 현재 사용한 구조에서는 eureka를 설정하는 과정에서 이미 actuator가 활성화되어있어서 추가하지 않았다.
만약 eureka를 설정하지 않거나 actuator가 dependency에 없다면 actuator를 추가해줘야 hystrix-dashboard에서 모니터링이 가능하다.
다음으로 CompositeApiApplication.java 에 @EnableCircuitBreaker를 추가한다.
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class CompositeApiApplication {
public static void main(String[] args) {
SpringApplication.run(CompositeApiApplication.class, args);
}
}
이제 Hystrix 를 이용하여 Fallback이 일어나는 경우의 처리를 추가해보자.이것은 @HystrixCommand 라는 어노테이션의 fallbackMethod 라는 속성을 통해서 설정할 수 있다.
product 의 리스트를 조회하는 ProductCompositeServiceBean의 getProducts() 메소드에 @HystrixCommand를 추가한 내용을 소스로 확인해보자.
/**
* Product list 에 대한 fallback method
* @param page
* @param size
* @param sort
* @return
*/
public Page<Product> getDefaultProducts(int page, int size, String sort) {
logger.debug("page : {}, size : {}", page, size);
return new PageImplBean<Product>();
}
/**
* Product list 를 조회하는 API Service Method.
*
* @param page
* @param size
* @param sort
* @return
*/
@HystrixCommand(fallbackMethod = "getDefaultProducts")
@Override
public Page<Product> getProducts(int page, int size, String sort) {
String uri = new StringBuffer(PRODUCT_API_URL).append("/?size={size}&page={page}&sort={sort}").toString();
Map<String Object> pageMap = new HashMap<>();
pageMap.put("page", page);
pageMap.put("size", size);
pageMap.put("sort", sort);
ResponseEntity<PageImplBean<Product>> responseEntity = restTemplate.exchange(uri, HttpMethod.GET, null, new ParameterizedTypeReference<PageImplBean<Product>>() {
}, pageMap);
if (responseEntity == null || responseEntity.getStatusCode() != HttpStatus.OK) {
return null;
}
return responseEntity.getBody();
}
@HystrixCommand의 fallbackMethod에 호출할 메소드 이름을 지정하고 호출될 메소드를 정의하면 완료다. ProductCompositeController 에서 getProducts() 메소드를 실행하고 메소드가 로직 수행 중 오류를 발생시켜 Exception이 발생하면 getDefaultProducts를 실행하게 된다.
@HystrixCommand는 javanica 라는 Netflix의 라이브러리를 이용하여 처리한다고 한다.
Hystrix의 기본 동작 방식은 5초 동안 20회 이상 실패할 경우 Circuit 을 Open하는 방식이다. 여기서 용어가 약간 헷갈리는데 Circuit이 Open 상태이면 해당 호출을 막는 것이고, Circuit이 Close 상태이면 정상 상태를 말하는 것이다. fallbackMethod외에 다른 Property 들이 있는데, 이 부분은 Spring cloud의 Reference를 확인해 볼 필요가 있다.
실제 테스트는 잠시 후에 hystrix dashboard를 통해서 정리해보겠다.(미리 확인하고 싶다면 전체 서비스가 정상인 상태에서 product/review/recommendation api 중 하나를 재실행하자. 재실행한 API 가 product 인 경우는 http://localhost:9000/composite/, review 또는 recommendation 인 경우는 http://localhost:9000/composite/product/1 로 접속해보면 데이터를 통해서 확인할 수 있다.)
Hystrix Dashboard
Hystrix Dashboard는 앞의 Hystrix 설정에 따른 Circuit breaker의 상태를 모니터링 할 수 있는 dashboard를 제공해주는 라이브러리이다. 사실 라이브러리라기 보다는 솔루션에 가깝다고 할 정도로 간단한 설정으로 실행할 수 있다.
우선 hystrix-dashboard의 build.gradle 이다.
dependencies {
compile('org.springframework.cloud:spring-cloud-starter-config')
compile('org.springframework.cloud:spring-cloud-starter-eureka')
compile('org.springframework.cloud:spring-cloud-starter-hystrix-dashboard')
}
configuration 서버와 eureka 관련 설정은 없어도 상관없는 것이라고 볼 때, compile('org.springframework.cloud:spring-cloud-starter-hystrix-dashboard') 만 추가하면 hystrix-dashboard 를 사용할 수 있다.
아래는 HystrixDashboardApplication 의 소스이다.
@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrixDashboard
public class HystrixDashboardApplication {
public static void main(String[] args) {
SpringApplication.run(HystrixDashboardApplication.class, args);
}
}
끝이다. 이제 HystrixDashboardApplication을 실행한 후에 http://localhost:7979/hystrix 로 접속해 보면 아래와 같은 화면을 볼 수 있다.
위 화면에서 보면 getRecommendationByProduct의 Circuit 항목이 Open으로 되어있는 것을 볼 수 있다. 현재 Recommendation API가 정상적으로 뜨지 않은 상태에서의 화면이다. 이후 Recommendation API 가 정상 상태가 되면 다른 메소드들 처럼 Circuit이 Closed 상태로 변하게 된다.
위와 같이 Hystrix 설정이 되어있는 서비스마다 따로 호출해서 확인을 하는 방법도 있겠지만, 아무래도 불편하다. 다음절에서는 aggregator 역할을 하는 Turbine을 설정해보자.
Turbine
Turbine은 Hystrix 를 이용한 Circuit 정보를 모아주는 역할(Aggregator)을 해 준다.
Hystrix 설정과 Hystrix dashboard 만으로도 모니터링을 충분하게 할 수 있겠지만, 많은 서비스가 구역마다 올라간다거나 하는 경우 cluster로 묶어서 관리할 수 있다면 더 좋지 않을까 하는 생각을 하게 되는데 이 요구를 만족하게 해주는 것이 turbine이다.
다만, 현재까지 테스트는 default cluster나 개별 서비스를 cluster로 지정하는 것까지는 성공했으나, 여러 서비스를 Cluster 별로 묶는다거나 하는 작업은 실패했다.
이번 정리에서는 default cluster 만으로 정리를 하려고 한다. 자세한 정보는 Spring cloud reference의 Hystrix dashboard 항목을 참고해 보자.
또 한가지 실패한 내용이 AMQP 를 사용하지 않는 turbine 설정이었다. 여러 번 시도는 했으나 무엇을 잘 못 했는지를 아직도 알지 못하고 있다. 따라서, AMQP와 RabbitMQ를 이용해서 정리할 것이다. RabbitMQ는 default 설정으로 docker를 사용해서 설치했는데, 이미 설치된 rabbitmq가 있다면 그대로 이용할 수도 있을 것이다. 참고삼아 그 내용도 정리해본다.
## Docker가 이미 설치되어있고 사용자가 docker 그룹이라면... # RabbitMQ 이미지를 Docker hub을 이용하여 설치 road$ docker run -d --hostname rabbitmq --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq # RabbitMQ의 management plugin 활성화 road$ docker start -i -t rabbitmq bash road$ rabbitmq-plugins enable rabbitmq_management
기존에 작업했던 Composite API 의 build.gradle 에 spring-cloud-netflix-hystrix-amqp를 추가한다.
...
# 기존에 추가했던 hystrix 모듈
compile('org.springframework.cloud:spring-cloud-starter-hystrix')
# AMQP 관련하여 새롭게 추가된 모듈
compile('org.springframework.cloud:spring-cloud-netflix-hystrix-amqp')
...
Edge server의 build.gradle 에도 spring-cloud-netflix-hystrix-amqp 를 추가하자. Edge server 에는 이미 spring-cloud-starter-hystrix 가 있으므로 amqp 관련만 추가하면 된다.
이제 Turbine 프로젝트를 만들고 build.gradle 작업을 해보자.
...
dependencies {
compile('org.springframework.cloud:spring-cloud-starter-eureka')
compile('org.springframework.cloud:spring-cloud-starter-turbine-amqp')
}
Turbine 서버는 AMQP로 작업을 하는 경우 Configuration 서버는 쓰지 않는 것이 좋은 것 같다. 이상하게 port 들을 조정하는데도 port 중복이 발생한다. Turbine 의 기본 포트는 8989 인데, 이 포트는 Tomcat이 아니라 application 안의 Rx server가 사용하게 된다. 따라서 Tomcat이 해당 포트를 점유하려고 하면 오류가 발생하게 된다. Reference에서는 server.port, turbine.amqp.port, management.port 를 조정하라고 되어있는데, Configuration 서버의 설정을 사용하는 경우 계속 오류가 발생한다. 같은 설정을 Configuration 서버에 설정하는 것과 로컬에 설정하는 것이 다르게 동작한다. 어떤 문제 때문인지는 모르겠다. 내가 잘못한 것일지도 모른다.
그래서 프로젝트의 Resources 폴더에 application.yml을 만들고 아래와 같이 설정하였다.
spring:
application:
name: turbine
server:
port: ${PORT:8989}
management:
port: -1
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
instance:
preferIpAddress: false
leaseRenewalIntervalInSeconds: 10
leaseExpirationDurationInSeconds: 30
metadataMap:
instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
이제 TurbineServiceApplication 을 아래와 같이 만들자. 여담이지만, 클래스 이름을 TurbineApplication 이라고 하려고 했는데 해당 클래스 이름을 이미 Spring이 사용하고 있다. 중복돼도 패키지가 달라서 상관없지만, 클래스 검색할 때 귀찮아서 다른 이름을 사용했다.
@SpringBootApplication
@EnableDiscoveryClient
@EnableTurbineAmqp
public class TurbineServiceApplication {
public static void main(String[] args) {
SpringApplication.run(TurbineServiceApplication.class, args);
}
}
Spring cloud 프로젝트들이 다 그렇듯 너무 간단하다. @EnableTurbineAmqp 만 사용하면 된다. 이름에서도 알 수 있지만, AMQP를 사용하지 않을 때에는 @EnableTurbine 을 사용하면 된다.
다른 설정 없이 위와 같은 상황에서 Turbine을 실행하자.
모든 서비스가 올라온 후에 Hystrix 설정이 된 서비스에 최소 한 번 이상의 요청을 해야만 한다. 그래야 hystrix의 정보가 RabbitMQ 에 message로 보내지고 Turbine이 그 정보를 이용할 수 있다. 그전까지는 계속 Loading.. 이라는 메시지를 보게 될 것이다.
우선 RabbitMQ의 Management dashboard를 이용해서 몇 가지 내용을 보면 아래와 같다.
아래의 내용으로 별도로 설정을 해야 하는 것이 아니라 Turbine이 정상적으로 실행되고 모니터링을 시작해서 정상적인 모습으로 나올 때의 RabbitMQ의 모습이다. 별도로 RabbitMQ에 설정해야 하는 것은 아무것도 없다.(물론 기본값으로 실행할 때의 이야기지만...)
대략 위와 같은 내용이 확인될 것이다.
이제 Hystrix dashboard에 접속하고, http://localhost:8989 를 입력해보자.
Hystrix 메인 화면에 보면
Cluster via Turbine (custom cluster): http://turbine-hostname:port/turbine.stream?cluster=[clusterName]라고 되어있는데, http://localhost:8989 형식으로만 해도 default cluster를 이용할 수 있다.
물론, http://localhost:8989/turbine.stream 을 입력해도 http://localhost:8989/turbine.stream?cluster=default 를 입력해도 결과는 같다.
위쪽에는 Circuit의 상태 아래쪽에는 Thread의 상태이며, Edge server와 Composite api의 정보가 모두 함께 나온다. 메소드 명 앞에 있는 것이 해당 서비스들의 Eureka 에 등록된 Service Id 로 이 값이 디폴트 값이다.
정보는 기본값으로 2초에 한 번씩 갱신(hystrix dashboard 메인 화면에서 수정 가능하다)되는데, 값이 변하는 모습을 보기 위해서 ab 를 이용해 테스트해 보았다.
로컬에서 작업한 만큼 대단한 부하를 주기는 힘들어서 아래 정도의 부하를 주고 모니터링을 해보았다.
ab -n 600 -c 10 http://localhost:9000/composite/product/1
그 중 한 장을 스크린샷으로 보면 다음과 같다.
원은 앞에 설명했듯이 현재 부하의 정도나 상태 등을 나타내는 것이고 그 외에도 90%, 99%, 99.9% 의 응답속도라던가 요청 수 쓰레드의 움직임 등을 함께 관찰할 수 있다.
결론
Circuit breaker는 아름답게 에러를 처리해야 한다는 마이크로서비스의 철학에 부합하기 위해 꼭 필요한 기능 중의 하나라고 할 수 있다.
Spring cloud 의 솔루션들을 정리해나가면 나갈수록 워낙 단순하게 사용할 수 있도록 만들어놔서 정리할 게 별로 없다는 점이 사실 곤혹스럽다. 그나마 여러 가지 옵션을 적용해보면서 달라지는 점을 정리한다면 모르겠는데 그러지도 못하고 있다.
좀 더 많은 옵션에 대해서 테스트를 진행해 보고 싶었는데 능력부족이다.
나중에 프로젝트를 진행하는 과정에서 많은 부분을 다뤄볼 수 있지 않을까 싶다.
현재에서 가장 궁금한 것은 Composite API 자체에 문제가 있는 경우에는 Edge Server의 Default fallback이 없다는 부분이다. 이 부분을 설정으로 해결할 수 있을 것인가 찾아봤는데 아직 찾지 못했다. 어쩌면 이 부분은 override를 한다거나 해서 커스터마이징을 해야 할지도 모르겠다.
혹시 이 글을 보시는 본 중에서 아시는 분은 메일이나 댓글로 알려주시면 감사하겠습니다.
댓글
댓글 쓰기