현대의 마이크로서비스 아키텍처에서는 수많은 서비스가 서로 호출하며 동작합니다.

하지만 그중 하나라도 장애가 발생하면 전체 시스템이 연쇄적으로 영향을 받을 수 있습니다.
이를 막기 위해 사용되는 핵심 안정성 패턴이 바로 "서킷 브레이커(Circuit Breaker)"입니다.

이 글에서는 서킷 브레이커란 무엇인지, 어떻게 동작하는지, 그리고 Spring Boot, 마이크로서비스 환경에서 어떻게 사용하는지를 상세히 설명합니다.

✅ 서킷 브레이커란?

서킷 브레이커(Circuit Breaker)는 시스템에서 특정 기능이나 외부 API 호출이 지속적으로 실패할 경우,
일시적으로 호출을 차단하여 전체 시스템의 안정성을 확보하는 디자인 패턴입니다.

쉽게 말해, 문제 있는 시스템과의 연결을 끊어서 장애 확산을 막는 안전장치입니다.

🔄 서킷 브레이커 동작 원리

서킷 브레이커는 보통 다음과 같은 3단계 상태를 갖습니다:

상태설명

Closed(닫힘)	정상 상태, 모든 요청 허용
Open(열림)	실패율이 높아지면 요청을 차단
Half-Open(반쯤 열림)	일정 시간 후 일부 요청을 보내 테스트. 성공 시 Closed 복귀, 실패 시 다시 Open

⚠️ 왜 서킷 브레이커가 중요한가?

주요 문제점:

외부 시스템(API, DB 등)이 느려지거나 장애 발생
호출하는 쪽은 계속 재시도 → 서버 자원 낭비, 전체 시스템 지연
서비스 전체 다운 가능성

서킷 브레이커의 역할:

실패 감지 → 자동 차단 → 자동 복원
시스템 자체 보호 및 서비스 연쇄 장애 차단

🛠 서킷 브레이커 실전 예제 (Spring Boot + Resilience4j)

YAML 설정 예시:

resilience4j.circuitbreaker:
  instances:
    userService:
      slidingWindowSize: 10
      failureRateThreshold: 50
      waitDurationInOpenState: 10s
      permittedNumberOfCallsInHalfOpenState: 2

적용 코드 예시:

@CircuitBreaker(name = "userService", fallbackMethod = "fallback")
public String getUserData() {
    return restTemplate.getForObject("http://user-api/data", String.class);
}

public String fallback(Throwable t) {
    return "서비스가 일시적으로 사용 불가합니다.";
}

📈 어디에 적용하면 좋을까?

적용 대상설명

외부 결제 시스템	일시적 장애로 전체 결제 시스템 마비 방지
파일 저장소 API	S3, FTP 등 외부 API가 느려질 경우 차단
인증 서버	인증 실패가 계속될 경우 fallback 제공

🔒 다른 안정성 패턴과의 차이

패턴역할

Retry	실패 시 일정 횟수 재시도
Timeout	응답 지연 시 자동 중단
Bulkhead	서비스 리소스 분리로 장애 고립
Circuit Breaker	실패율 높으면 자동 차단 후 회복 시도

💡 도입 시 주의사항

너무 민감하게 설정하면 정상 요청도 차단될 수 있음
Retry, Timeout, Bulkhead와 함께 조합 사용 권장
Fallback 로직 꼭 필요 (예: 대체 응답, 캐시 제공)

📝 결론

서킷 브레이커(Circuit Breaker)는 마이크로서비스 환경에서 서비스 장애 확산을 막기 위한 핵심 안정성 패턴입니다.
특히 외부 API, DB, 인증 시스템 등과 연동하는 서비스에서는 반드시 도입해야 할 전략적 방어 메커니즘입니다.

장애를 빠르게 감지하고,
과감히 차단하고,
안전하게 복원합니다.

🚨 서킷 브레이커(Circuit Breaker)란? 마이크로서비스 장애 방지 핵심 패턴