1. 개요

서비스는 Resiliency Pattern을 통해 장애를 회피할 수 있다.

• Timeout (시간만료)
• Circuit Breaker (차단기)
• Bulkheads (칸막이 벽)
• Load Shedding (부하분배, 부하제한)
• Fail Fast (빠른 실패)
• Handshaking (상호동의)
• Graceful Degradation (점진적 기능저하)
• Asynchronous Calls (비동기 호출)

특히 마이크로 서비스가 도입되면서 Circuit Breaker의 개념을 도입하는 곳이 많아지고 있다.

의존 서비스의 상태가 좋지 않다고 하자. 200번 요청했는데 100번 이상 문제가 발생하고 있다. 그러면 일단 지금은 의존 서비스에 요청을 보내지 않고 예비 결과값을 리턴해버린다. 그리고 조금 지나서 다시 의존 서비스에 요청을 보내봐서 문제가 없으면 다시 요청을 흘린다. 이렇게 되면 클라이언트는 빠른 처리가 가능하고 서버는 부담을 완화할 수 있다.

그래서 특정 시스템에 일정 횟수 이상의 오류가 반복된다면 Circuit을 오픈하여 해당 시스템을 오픈하지 않게끔 한다. 이렇게 Cascading failure를 방지한다. (Circuit이 닫혀야 요청이 흘러가는 것이다, 열리는 막힘)

Hystrix는 Netflix 내부에서 개발되어 OSS로 공개한 Circuit Breaker이다.

2. 소개

• Latency and Fault Tolerance
• Realtime Operations
• Concurrency

3. 동작방식

• 서비스마다 각각의 스레드 풀을 할당한다.
• 계층화된 요청차단 : 스레드 풀에 넣는 단계와 스레드에서 실행되는 단계에서 각각 요청을 중지시키도록 구분되어 있다. 과도한 스레드 자원 사용을 막을 수 있는 것이다. 또 단계마다 발생하는 예외가 달라서 원인을 파악하기 쉽다.
• Hystrix 스레드 풀은 요청마다 하나의 스레드를 연결하여 실행한다.

3.1. 모든 것이 정상일 때

3.2. 백엔드에 문제가 생겨서 사용자 요청이 블락되고 있을 때

3.3. 계단식으로 문제가 증가할 때

3.4. Hystrix를 사용할 때

4.  단점

• 튜닝, 운영에 대한 복잡도가 증가한다.
• 모니터링이 필요하다.
• 특성상 과거에 대한 상황은 볼 수 없다.

5. 고민사항

• Circuit Breaker를 모든 곳에 적용할 것인가? 사실 필요한 곳에만 적용하는 것이 맞다.
• Write가 발생하는 앱에 적용 시 조심스러운 부분이 있다.

6. Hystrix Dashboard

start.spring.io에서 Hystrix Dashboard(spring-cloud-starter-netflix-hystrix-dashboard)를 추가한 후 Spring Boot 앱을 기동한다.

접속 URL은 Spring Boot 주소에 /hystrix를 붙이면 된다. 예를 들어 http://localhost:9080/hystrix 이다.

하지만 Dependency만 추가하고 접속하면 Whitelabel Error Page가 뜰 것이다. @EnableHystrixDashboard가 누락되었기 때문이다.

package io.sarc.springcloud.HystrixDemo;
 
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;
 
@EnableHystrixDashboard
@SpringBootApplication
public class HystrixDemoApplication {
  public static void main(String[] args) {
    SpringApplication.run(HystrixDemoApplication.class, args);
  }
}