장애를 막는 것이 아니라 전파를 막는 기술
대규모 트래픽 환경에서 장애는 반드시 발생한다. 중요한 것은 장애를 완전히 없애는 것이 아니라, 장애가 전체 시스템으로 확산되지 않도록 막는 것이다. 서킷 브레이커는 이 목적을 위해 사용되는 대표적인 안정성 패턴이다. 이 글에서는 서킷 브레이커의 개념과 왜 필요한지, 그리고 어떤 문제를 해결하는지를 중심으로 정리한다.
장애는 왜 전파되는가
마이크로서비스 환경에서 하나의 요청은 여러 서비스를 거친다.
- API 서버
- 인증 서버
- 외부 결제 시스템
- DB 또는 외부 API
이 중 하나라도 느려지거나 실패하면, 그 영향은 연쇄적으로 전파된다.
이것이 장애 전파(cascading failure) 다.
서킷 브레이커란 무엇인가
서킷 브레이커는 장애가 감지되면 호출을 차단하는 보호 장치다.
전기 회로의 차단기와 같은 개념에서 이름이 왔다.
서킷 브레이커의 목적은 다음과 같다.
- 실패 요청을 빠르게 차단
- 불필요한 재시도 방지
- 전체 시스템 보호
즉, 실패한 시스템을 계속 호출하지 않도록 막는다.
왜 단순 재시도는 위험한가
장애 상황에서 가장 흔한 대응은 재시도다.
하지만 재시도는 다음 문제를 만든다.
- 이미 느린 시스템에 요청이 더 몰림
- 스레드, 커넥션 고갈
- 장애 범위 확대
서킷 브레이커는 “더 이상 시도하지 말아야 할 시점”을 판단하는 역할을 한다.
서킷 브레이커의 기본 상태
서킷 브레이커는 보통 세 가지 상태를 가진다.
- Closed
- 정상 상태
- 요청을 그대로 전달
- Open
- 장애 감지 상태
- 요청을 즉시 실패 처리
- Half-Open
- 복구 확인 상태
- 일부 요청만 허용
이 상태 전환을 통해 시스템 회복 여부를 판단한다.
Open 상태에서 무엇이 달라지는가
서킷 브레이커가 Open 상태가 되면 다음 변화가 발생한다.
- 외부 시스템 호출 차단
- 즉시 실패 응답 반환
- 리소스 사용량 급감
이 덕분에 장애 시스템과 호출하는 시스템 모두를 보호할 수 있다.
서킷 브레이커가 Scale Out을 도와주는 이유
Scale Out은 트래픽 증가에 대응하는 전략이다.
하지만 장애 상황에서는 Scale Out이 오히려 문제를 키울 수 있다.
- 장애 시스템에 더 많은 요청 전달
- Pod 수 증가
- 리소스 낭비
서킷 브레이커는 확장 이전에 차단을 수행해 Scale Out의 부작용을 줄인다.
타임아웃과 서킷 브레이커의 차이
두 개념은 자주 함께 사용되지만 역할은 다르다.
- 타임아웃
- 요청 하나의 최대 대기 시간 제한
- 서킷 브레이커
- 반복 실패 자체를 차단
타임아웃은 필수지만, 그것만으로는 장애 전파를 막기 어렵다.
서킷 브레이커를 적용하기 좋은 지점
다음 위치는 서킷 브레이커 적용 효과가 크다.
- 외부 API 호출
- 결제, 인증 시스템
- DB가 아닌 외부 의존성
- 지연 가능성이 있는 내부 서비스
모든 호출에 적용할 필요는 없다.
서킷 브레이커를 도입하면 생기는 변화
서킷 브레이커를 도입하면 시스템의 성격이 바뀐다.
- 빠르게 실패하는 구조
- 장애 시 응답 일관성 증가
- 전체 시스템 안정성 향상
“느리게 실패하는 시스템”에서
“빠르게 실패하는 시스템”으로 전환된다.
서킷 브레이커는 장애를 숨기지 않는다
중요한 오해 중 하나는 이것이다.
- 서킷 브레이커 = 장애를 감춘다
실제로는 반대다.
- 장애를 명확히 드러냄
- 로그와 메트릭으로 관찰 가능
- 운영자가 대응할 시간 확보
서킷 브레이커는 장애를 관리 가능한 상태로 만든다.
Kubernetes 환경에서 더 중요한 이유
Kubernetes 환경에서는 다음 특성이 있다.
- 요청 수 급증
- Pod 자동 확장
- 외부 의존성은 그대로
이 구조에서 서킷 브레이커가 없으면 장애 전파 속도가 매우 빨라진다.
정리
서킷 브레이커는 장애를 없애는 기술이 아니라, 장애의 전파를 차단하는 기술이다. 반복되는 실패 호출을 빠르게 차단함으로써 시스템 전체를 보호하고, Scale Out 환경에서도 안정성을 유지할 수 있게 한다. 대규모 트래픽과 마이크로서비스 환경에서 서킷 브레이커는 선택이 아니라 필수에 가까운 패턴이다.