인프런 커뮤니티 질문&답변

작성한 질문수

동적 외부 API 의존 구조에서 CircuitBreaker 적용 기준에 대한 질문

작성

수정됨

현재 외부 API를 호출해서 데이터를 서빙하는 BE를 개발중 입니다.

(MSA는 아니고, 단일 BE에서 외부 클러스터 API에 의존하는 구조 입니다.)

공급자(외부 클러스터)를 클라이언트(FE)에서 동적으로 추가/삭제할 수 있고, 공급자마다 endpoint(URL)이 서로 다른 구조 입니다.

현재 아키텍처는

BE -> HAProxy -> 외부 Cluster 형태로 구성되어 있고, HAProxy 앞단에서 기본적인 네트워크 장애 처리는 되고 있습니다.

또한 공급자 데이터는 별도의 RDB 테이블로 관리하고, 이를 Redis에 동기화하여 런타임에 조회해서 사용하는 구조입니다.

이런 상황에서 고민되는 부분은 다음과 같습니다.

공급자 단위로 장애 격리를 하기 위해 CircuitBreaker를 적용하는 것이 적절한 선택인지
만약 적용한다면, 공급자가 런타임에 추가/삭제 되는 구조라서 @CircuitBreaker 같은 정적 방식보다는 Resilience4j의 Registry 방식으로 리소스를 동적으로 관리하는 게 맞는지, 인스턴스 별 서킷의 상태를 공유를 해야하는지..

비슷한 구조를 운영해보신 경험이 있다면, CircuitBreaker를 실제로 두는지 / 두지 않는다면 어떤 기준으로 판단하셨는지 의견을 듣고 싶습니다.

답변 1

안녕하세요, 인프런 AI 인턴입니다.
이동준님,

외부 API에 의존하는 구조에서 CircuitBreaker를 사용하는 것은 장애 격리를 위해 매우 유용할 수 있습니다. 특히, 외부 공급자가 동적으로 추가/삭제될 수 있는 경우에는 더욱 그렇습니다.

CircuitBreaker 적용 여부: 각 공급자 별로 장애를 격리하기 위한 CircuitBreaker 적용은 적절한 선택일 수 있습니다. 이렇게 하면 특정 공급자가 장애가 발생했을 때, 전체 시스템에 미치는 영향을 최소화할 수 있습니다.
Resilience4j Registry 방식 사용: 런타임에 공급자가 동적으로 추가/삭제되는 구조라면, Resilience4j의 Registry 방식을 통해 CircuitBreaker를 관리하는 것이 적절할 수 있습니다. 이는 각 공급자 별로 동적으로 리소스를 관리할 수 있는 유연성을 제공합니다. 또한, 각 인스턴스의 서킷 상태를 공유할지 여부는 애플리케이션의 특성과 요구사항에 따라 달라질 수 있습니다. 하지만 일반적으로 애플리케이션 인스턴스 간에 서킷 상태를 공유하지 않는 것이 더 일반적이며, 이는 각 인스턴스가 독립적으로 장애를 관리할 수 있게 합니다.

비슷한 구조에서는 보통 다음과 같은 기준으로 CircuitBreaker 적용을 결정합니다:
- 공급자 API의 신뢰성 및 가용성
- 네트워크 환경의 안정성
- 장애 발생 시 비즈니스에 미치는 영향

이와 관련된 구현을 고려할 때는, CircuitBreaker의 매개변수 설정(예: 실패 임계값, 대기 시간 등)도 신중하게 설정해야 합니다.

더 궁금하신 점이 있으면 언제든지 질문해 주세요!

도움이 되었기를 바랍니다.

Spring Boot에서 Circuit Breaker에 대한 정보는 아래 링크에서 확인할 수 있습니다.
Spring Boot 문서: Circuit Breaker

작성한 질문수