Circuit Breaker

케이스 1넷플릭스 — Hystrix

넷플릭스는 원격 시스템 접근 지점을 격리해 연쇄 장애를 막는 Hystrix 라이브러리를 만들었습니다. 스레드 풀 격리와 차단기 상태 기계를 결합한 구조입니다. 기본값은 요청 임계수 20건, 오류율 50%, 대기 창 5초입니다.
도입효과: 스레드 격리로 처리하는 Hystrix 명령 실행 건수 일 100억 건 이상(프로젝트 위키 기준)^[3]

케이스 2우아한형제들 — 공통 플랫폼 연동에 Resilience4j 적용

우아한형제들은 검색·광고·쿠폰을 사내 공통 플랫폼으로 옮기면서 동기 연동이 만드는 강한 의존과 장애 전파를 문제로 짚었습니다. Spring Cloud Hystrix가 유지보수 모드로 들어간 점을 고려해 Resilience4j를 골랐습니다. 차단기 상태는 프로메테우스와 그라파나로 봅니다.
도입효과: 슬라이딩 윈도 10회, 실패율 기준 50%, 열림 상태 대기 10초(2024-01-11 공개 설정값)^[6]

케이스 3화해 — 파이썬 자체 구현과 레디스 공유 상태

화해는 Hystrix와 Resilience4j가 자바 생태계이고 파이썬 대안은 검증이 부족하다고 보고 차단기를 직접 만들었습니다. 인스턴스마다 상태가 갈라지는 문제는 레디스로 상태를 공유해 풀었습니다. 실제로 ML 서빙 API 장애 때 차단기와 대체 응답이 동작했습니다.
도입효과: 실패율 기준 80%, 최소 호출 수 900건, 시간 기반 윈도 300초, 150 TPS 부하에서 레디스 CPU 4% 미만(2024-08-29)^[7]

케이스 4라인 — Armeria에 차단기 내장

라인은 사내 오픈소스 비동기 통신 라이브러리 Armeria에 차단기를 넣었습니다. 한 네트워크가 갑자기 응답하지 않으면 연쇄 장애로 이어진다는 문제의식에서 출발했습니다. 실패율 기준과 최소 요청 수, 윈도 기간을 설정할 수 있게 만들었습니다.
도입효과: 내장 제공 시작 버전 0.13.0, 설정 항목 3종(실패율 기준·최소 요청 수·윈도 기간)(2016-07-24)^[8]

오늘 바로 해보기
1. 외부 의존 호출 중 가장 느린 것 하나를 골릅니다.
2. 최근 한 달 실패율과 응답 시간 분포를 확인합니다.
3. 실패율 기준과 최소 호출 수를 우리 트래픽 규모에 맞춰 정합니다.
4. 차단됐을 때 돌려줄 대체 응답을 먼저 정의합니다.
5. 차단기 상태 변화를 지표로 내보내 대시보드에 올립니다.

한계와 진화
모두가 차단기를 권하지는 않습니다. AWS Builders' Library의 마크 브루커는 차단기가 테스트하기 어려운 모드 동작을 만들고 복구 시간을 크게 늘릴 수 있다고 지적하며, AWS는 재시도를 로컬 토큰 버킷으로 제한하는 쪽을 선호한다고 적었습니다. 또 대표 구현이던 Hystrix는 1.5.18에서 멈춰 유지보수 모드로 들어갔고, 넷플릭스 스스로 활성 프로젝트를 권합니다.

기준값은 그대로 복사하면 위험합니다. 같은 패턴이라도 우아한형제들은 10회 윈도에 실패율 50%를, 화해는 900건 윈도에 실패율 80%를 썼습니다. 트래픽 형태가 다르면 기준도 달라야 합니다. 낮은 트래픽에서는 비율 기반 차단이 오작동하므로 최소 요청 수를 반드시 같이 정해야 합니다.