MSA | 서킷 브레이커 (feat. Resilience4j)

❇️ 추가 지식 : 서킷브레이커(Circuit Breaker) 가 무엇인가?

출처 : https://ko.wikipedia.org/wiki/회로_차단기

유래 : 
  전기 회로에서 과열된 회로를 차단하는 장치 (a.k.a. 두꺼비집)

쓰임 :
  주식 시장 - 주가가 갑자기 급락할 때, 주식매매 일시 정지하는 제도
  소프트웨어 - 장애전파 차단을 목적으로 시스템 간 연동을 차단하는 기술

< 정의 >

서로 다른 시스템끼리 연동할 때, 장애가 발생한 서비스로의 요청을 일시적으로 차단하여, 장애전파를 방지하는기술

목적 : 시스템의 전체적인 안정성을 유지할 수 있다.

기능 :

• 시스템 연동 시, 호출 실패 감지
• 이후 회복시, 자동으로 시스템 연동

 

< 서킷 브레이커 상태 >

1. 클로즈드 (CLOSED)

• 서비스가 정상 호출/응답 되고 있는 상태

2. 오픈 (OPEN)

• 문제 발생이 감지된 상태

3. 하프-오픈 (HALF_OPEN)

• 서비스가 오픈 상태가 된 후 특정 대기 시간이 지나면 전환되는 상태

위의 3가지 보통 상태와 아래의 특별 상태가 2개가 존재한다.
이번에는 보통 상태만 정리했다.

4. DISABLED

• 항상 호출을 허용하는 상태

5. FORCED_OPEN

• 항상 호출을 거부하는 상태

 

< 상태 변화 결정 방식 >

슬라이딩 윈도(Sliding window)를 사용하여 상태의 변화여부를 결정한다.

슬라이딩 윈도 방식은 횟수 방식(COUNT_BASED)과 시간 방식(TIME_BASED)으로 나뉜다.

알고리즘의 그 슬라이딩 윈도인가..? 나중에 알아보기로 하자……………….

 

1. 정해진 확률보다 높은 확률로 호출에 실패하게 되면 상태를 OPEN으로 변경한다.

2. OPEN 상태에서는 시스템 호출을 시도하지 않으며, 바로 호출 실패 Exception 발생 또는 정해진 fallback 동작을 수행한다.

3. OPEN 이후 설정한 시간이 지나면 HALF_OPEN 상태로 변경되며, 호출이 정상화되었는지 1번의 실패 확률로 확인한다.

4. 정상화 여부에 따라 CLOSED와 OPEN 상태로 변경된다.

 

 

< Fallback 메커니즘 >

서비스 호출에 실패한 경우 fallback method를 실행시킬 수 있다.

fallback method

• 요청에 실패한 서비스의 대체 로직

public String fallbackMethod(Throwable t) {
    // 필요한 로직 작성
    return "Fallback response";
}

로직을 작성하는 부분에 주로

서비스 호출 실패 시 알림 설정 (주로 Slack, MM, 등 SMS) 이나 클라이언트에게 알릴 메시지나 대체 페이지 등을 설정한다.

장점

• 장애 발생 시, 사용자에게 일정한 응답(무분별한 오류 페이지보단 알림, 공지 등) 제공 가능

 

✨ 서킷 브레이커 상태 및 상태 변화 동작 (정리)

클로즈드 (CLOSED)

• 서비스가 정상 호출/응답 되고 있는 상태 (기본 상태)
• — 동작
• 호출 실패 시, 실패 카운터가 증가
• 설정해둔 임계값을 초과하면 OPEN 상태로 변경
• 예시 : 설정한 임계값이 50%일 때, 5번의 호출 중 3번이 실패하여 실패율이 60%가 되면 OPEN 상태로 변경

오픈 (OPEN)

• 문제 발생이 감지된 상태
• — 동작
• 모든 요청을 즉시 실패로 처리하며, 설정된 동작(에러 응답 또는 fallback)을 수행
• 설정된 대기 시간이 지나면, HALF_OPEN 상태로 변경
• 예시 : 설정한 대기 시간이 20초일 때, OPEN 상태로 변경되면 20초 동안 모든 요청이 차단

하프-오픈 (HALF_OPEN)

• 서비스가 오픈 상태가 된 후 특정 대기 시간이 지나면 전환되는 상태

— 동작

• 제한된 수의 요청을 허용하여 시스템의 정상화 여부를 확인
• 요청 모두 성공 → CLOSED 상태로 변경
• 요청 실패 → OPEN 상태로 변경
• 예시 : 요청 허용 수가 3개일 때, 3번의 요청을 모두 성공하면 CLOSED 상태로 변경하고, 하나라도 실패하면 OPEN 상태로 변경

 

---

 

📝Resilience4j

서킷 브레이커를 구현하기 위해 Resilience4j를 사용한다.

Spring Cloud에서 Hystrix (넷플릭스가 개발한 서킷 브레이커 라이브러리)를 사용했었지만,

maintenance 모드로 전환되어 Resilience4j가 대체 모듈로 선택되었다.

⚠️ maintenance 모드 ? (유지모드) 

• 스프링 버전이 업그레이드되면서 더 이상 해당 모듈에 기능을 추가하지 않는 상태

 

< Resilience4j 설정 >

1. 의존성

Spring boot에서 resilience4j를 사용할 때 start.spring.io 에서 의존성을 추가하면 안된다.

spring starter에서 추가하면 구현체가 들어오는 것이 아닌 인터페이스가 들어오므로 구현체를 따로 만들어서 사용해야한다. 따라서 resilience4j 프로젝트 깃헙을 참고해서 구현체를 가져와서 사용한다.

dependencies {
    // spring boot 버전에 따라 선택하여 사용
    implementation 'io.github.resilience4j:resilience4j-spring-boot3:2.2.0'
	  implementation 'org.springframework.boot:spring-boot-starter-aop'
}

출처 : https://resilience4j.readme.io/docs/getting-started-3

2. application 설정

앞서 설정해둔 임계값, 시간 등을 언급했는데 그 값들은 설정 파일에서 지정한다.

여러가지 설정 옵션은 많지만 무의미한 코드 복붙은 TIL에 하지 않기로 했으므로 스킵

 

< Resilience4j Dashboard와 Prometheous >

Resilience4j Dashboard를 사용해서 서킷 브레이커의 상태를 모니터링할 수 있다.

그런데 Prometheous도 모니터링 도구로 알고 있는데 왜 둘 다 사용하는 것일까?

⚠️ Resilience4j Dashboard랑 Prometheus 는 뭐가 다른거지?

Resilience4j Dashboard

• 주요 기능 : Resilience4j의 서킷 브레이커의 상태를 모니터링하는 것
• 사용 목적 : 장애 복원력(resilience)을 관리하고, 서킷 브레이커가 열렸는지, 실패율이 높은지 등을 확인
• 대시보드 : Spring Boot Actuator 앤드 포인트를 활용하여 상태를 시각화한다.

Prometheus

• 주요 기능 : 모니터링 및 시계열 데이터 수집을 하는 것
• 사용 목적 : 애플리케이션 및 시스템 메트릭 수집 (CPU 사용량, 메모리, 요청 수, 오류율 등)
• 대시보드 : Grafana와 함께 사용하여 데이터를 시각화할 수 있다.

⇒ Prometheus는 일반적인 모니터링 도구이고, Resilience4j Dashboard는 서킷 브레이커 및 장애 복원력을 모니터링하는 도구이다.
따라서, Resilience4j에서 제공하는 메트릭을 Prometheus로 보내서 모니터링하는 방법으로 활용한다.

 

⚠️ 둘 다 모니터링 도구인데 왜 굳이 Prometheus로 데이터를 보냄..??

Prometheus와 Resilience4j Dashboard는 역할과 접근 방식이 다르다.

Resilience4j Dashboard

• 실시간 상태 확인용
• Resilience4j 내부 상태를 실시간으로 보여준다.
• 개별 애플리케이션의 장애 복원력을 확인할 수 있지만, 장기적인 매트릭 저장이나 분석 기능이 부족하다.

Prometheus

1. 장기적인 데이터 저장 및 분석용
   • 장기적인 시계열 데이터를 저장하고, 분석할 수 있는 강력한 기능을 제공한다.
   • “지난 1시간동안 서킷이 몇 번 열렸지?”, “지난 7일 동안 특정 API 실패율은 어땠지?” 와 같은 분석을 할 수 있다.
   • 과거 데이터를 비교하여 장애 패턴을 분석할 수 있다.
2. 여러 서비스의 메트릭을 한 곳에서 관리 가능
   
   • Resilience4j Dashboard는 개별 애플리케이션의 Resilience4j의 상태만 보여주는 것에 비해 Phrometheus는 여러 개의 MSA에서 오는 데이터를 한 번에 수집하고, 모니터링할 수 있다.
3. Grafana와 연동하여 데이터를 시각화할 수 있다.
   
   

< 결론 >

• Resilience4j Dashboard는 개별 애플리케이션의 실시간 상태를 확인하는 용도
• Prometheus는 장기적인 데이터 저장 및 분석을 위해 필요
• Prometheus에 데이터를 보내면 여러 서비스의 장애 패턴을 한눈에 파악할 수 있음
• Grafana와 결합하면 더 강력한 시각화 가능

 

< 모니터링 설정 >

1. 의존성

dependencies {
    implementation 'io.github.resilience4j:resilience4j-micrometer'
    implementation 'io.micrometer:micrometer-registry-prometheus'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
}

start.spring.io 에서 prometheus와 actuator를 설정할 수 있다.

resilience4j-micrometer는 resilience4j 프로젝트 깃헙에서 찾을 수 있다.

해당 페이지의 설명을 통해서 micrometer가 모니터링 모듈인 것을 알 수 있었다.

Resilience4j는 InfluxDB 또는 Prometheus와 같은 가장 널리 사용되는 모니터링 시스템을 지원하는 Micrometer용 모듈을 제공합니다.
출처 : https://resilience4j.readme.io/docs/micrometer

 

1. 설정 파일

application 설정 파일에서 endpoint로 prometheus를 설정해주어야 한다.

management:
  endpoints:
    web:
      exposure:
        include: prometheus
  prometheus:
    metrics:
      export:
        enabled: true

그러면 http://${hostname}:${port}/actuator/prometheus 로 접속해서 서킷브레이커 항목을 확인할 수 있다.

 

⚠️ actuator는 뭔데 의존성에도 등장하고, endpoint로 주소에도 등장하는 걸까..?

Spring Boot Actuator 라이브러리는 Spring Boot 애플리케이션의 상태와 운영 정보를 모니터링하고 관리할 수 있도록 다양한 REST API 앤드포인트를 제공한다.

actuator/{sth} 이런 형태로 특정 앤드포인트에 접근할 수 있다.

 

---

참고 강의/글

스파르타 코딩 MSA 강의
우아한 기술 블로그 | 개발자 의식의 흐름대로 적용해보는 서킷브레이커