회로 차단기 패턴 (소프트웨어 공학) 편집하기

회로 차단기 패턴(영어: Circuit Breaker Pattern)은 분산 시스템이나 마이크로서비스 아키텍처에서 반복적인 호출 실패가 전체 시스템으로 전파되는 것을 방지하기 위해 해당 호출을 일시 차단하고 복구 시점을 제어하는 내결함성 설계 패턴이다.
==의도 및 목적==
*호출 대상 서비스에 반복적인 실패가 발생할 때 호출을 계속 시도함으로써 호출자 또는 다른 종속 서비스의 자원이 고갈되는 것을 방지한다. 
*장애가 발생한 서비스에 대해 빠르게 실패를 반환(fail fast)하거나 대체 경로(fallback)를 적용하여 전체 시스템의 안정성을 유지한다. 
*장애 후 자동으로 또는 점진적으로 호출을 재개하여 서비스 복구 시점에 안정적으로 정상 흐름으로 복귀할 수 있게 한다. 
==적용 맥락==
*동기 호출로 외부 서비스 또는 타 마이크로서비스에 의존하는 경우.
*대상 서비스의 지연(latency)이나 오류가 호출자 성능에 직접적인 영향을 줄 때.
*반복 호출이 스레드, 커넥션 풀 등 공통 자원을 소모해 전파형 장애(cascading failure)를 야기할 위험이 있을 때. 
==구조 및 상태==
*Closed(닫힘)
**기본 상태로 모든 호출이 대상 서비스로 전달된다.
**최근 실패율이나 오류 횟수가 임계값(threshold)을 초과하면 Open으로 전이 조건을 만족한다.
*Open(열림)
**대상 서비스가 위험 상태로 판단되면 호출을 즉시 실패 처리하거나 fallback을 사용한다.
**설정된 대기 시간(wait duration)이 지나면 Half‑Open으로 전이한다.
*Half‑Open(반열림)
**제한된 수의 검증 요청을 허용하여 대상 서비스의 복구 여부를 확인한다.
**검증 요청 성공 시 Closed로 복귀하고, 실패 시 다시 Open으로 전환한다.
===상태 전이 흐름===
#Closed 상태에서 오류율이 임계값 초과 → Open으로 전환.
#Open 상태에서 지정된 시간 경과 → Half‑Open으로 전환(시험적 요청 허용).
#Half‑Open에서 허용된 검증 요청이 연속 성공 → Closed로 전환.
#Half‑Open에서 실패 발생 → Open으로 재전환.
==구성 요소 및 주요 매개변수==
*실패 카운터(failure count) 또는 실패율(failure rate) 측정 방식
*임계값(threshold) 및 측정 윈도(time window)
*Open 상태 유지 시간(wait duration in open state)
*Half‑Open에서 허용할 시도(requests allowed) 수
*대체 경로(fallback) 또는 기본 응답(default response)
*모니터링/로그(성공/실패, 전이 이벤트) 기록
==구현 기법 및 라이브러리==
*라이브러리 사용
**Resilience4j (Java) — 회로 차단기, 재시도, 타임리미트 등 제공. <ref>Resilience4j. https://resilience4j.readme.io/</ref>
**Polly (.NET) — 정책 기반의 회로 차단기 및 재시도 지원. 
*미들웨어/프록시 방식
**API 게이트웨이나 서비스 프록시 레이어에 회로 차단기를 두어 호출자와 대상 서비스 사이에서 중앙 제어.
*자체 구현
**단순 실패 카운터 + 시간 기반 전이 로직으로 직접 구현 가능하지만, 경합이나 분산 환경 고려 필요.
==예시 코드 (Java + Resilience4j)==
<syntaxhighlight lang="java">
import io.github.resilience4j.circuitbreaker.CircuitBreaker;
import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig;
import java.time.Duration;

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)                     // 실패 비율 50% 이상이면 열림
    .slidingWindowSize(20)                        // 최근 20건을 기준으로 실패율 계산
    .waitDurationInOpenState(Duration.ofSeconds(60)) // OPEN 상태 유지 시간 60초
    .permittedNumberOfCallsInHalfOpenState(5)     // HALF-OPEN 시 허용 호출 수
    .build();

CircuitBreaker circuitBreaker = CircuitBreaker.of("externalServiceCB", config);

String result = circuitBreaker.executeSupplier(() -> externalService.call());
</syntaxhighlight>
==장점==
*반복 호출로 인한 자원 고갈을 막아 전체 시스템 장애 확률을 낮춘다. 
*장애 발생 시 빠른 실패(fail fast)로 호출자 응답 시간을 개선하거나 대체 흐름을 제공할 수 있다.
*서비스 복구를 자동으로 감지하고 안정적으로 호출을 재개할 수 있다.
==주의사항 및 운영 고려사항==
*임계값 및 시간 파라미터 튜닝이 중요하다. 부적절한 설정은 정상 서비스까지 차단하는 원인이 될 수 있다. 
*분산환경에서는 각 노드의 상태를 어떻게 공유(또는 비공유)할지 설계해야 한다(로컬 차단기 vs 중앙 차단기).
*너무 많은 회로 차단기 또는 과도한 복잡성은 테스트 및 운영 부담을 증가시킨다.
*회로가 열린 경우 호출자 쪽에서 적절한 fallback, 캐시, 사용자 안내 등을 제공해야 사용자 경험을 보호할 수 있다.
*모니터링(전이 이벤트, 실패 원인 로그)과 알림 체계를 함께 구성해야 빠른 대응이 가능하다.
==관련 패턴==
*Retry Pattern — 실패 시 재시도. 회로 차단기와 조합 시, 회로가 열린 경우 재시도는 중단해야 함.
*Fallback Pattern — 실패 시 대체 동작 제공. 회로가 열렸을 때 특히 유용.
*Bulkhead Pattern — 자원을 분리하여 충돌 전파를 방지. 회로 차단기와 함께 사용하면 복원력 향상.
==요약==
회로 차단기 패턴은 반복 실패로 인한 전파형 장애를 방지하고, 장애 복구 시점을 안정적으로 제어함으로써 분산 시스템의 내결함성을 높이는 핵심 패턴이다. 다만 임계값 설정, 분산 설계, 대체 경로 설계, 모니터링 등 실무적 고려사항을 충분히 반영해야 한다.
==같이 보기==
*[[Retry Pattern]]
*[[Fallback Pattern]]
*[[Bulkhead Pattern]]
*[[마이크로서비스 아키텍처]]
*[[내결함성 설계]]
==참고 문헌==
*Microsoft Learn. "Circuit Breaker Pattern". https://learn.microsoft.com/
*AWS Prescriptive Guidance. "Circuit Breaker Pattern". https://docs.aws.amazon.com/
*Resilience4j. "Resilience4j Documentation". https://resilience4j.readme.io/
*Baeldung. "Circuit Breaker Pattern in Microservices". https://www.baeldung.com/
*Red Hat. "The pros and cons of the Circuit Breaker architecture pattern". https://www.redhat.com/
==각주==
<references />
[[분류:소프트웨어 공학]]