<div id="readability-page-1" class="page"><article id="post-1884">
			
		<div>
			
<p><a href="https://martinfowler.com/bliki/CircuitBreaker.html">https://martinfowler.com/bliki/CircuitBreaker.html</a></p>



<figure></figure>



<p>서킷 브레이커는 장애가 난 외부 시스템에 요청을 낭비하지 않기 위해 사용하는 패턴이다.</p>



<h2>배경</h2>



<p>어떤 외부 시스템에 원격 호출을 하는 소프트웨어를 만들었다고 하자. 만약 이 외부 시스템에서 장애가 발생했다면 우리 입장에선 요청이 타임아웃 되는 걸 통해 알 수 있을 것이다.</p>



<p>하지만 단시간 내에 클라이언트가 우리 시스템을 수백번 넘게 실행한다면, 수백번의 요청이 타임아웃 날 것이다. 단지 몇 번의 재시도만 해도 외부 시스템의 장애를 알 수 있는데, 수백번의 요청들이 각각 외부 시스템이 장애가 난 걸 알 때 까지 기다리는 건 자원 낭비다. 이 때문에 서킷 브레이커라는 패턴이 탄생하게 되었다.</p>



<h2>기본 이론</h2>



<p>서킷 브레이커의 이론은 간단하다. 원격 호출하는 부분을 서킷 브레이커라는 장애를 확인하는 객체로 감싸자는 것이다. 서킷 브레이커를 통해 원격 호출을 했다가 장애를 만나면 서킷 브레이커가 이를 기억한다. 정해진 횟수를 초과하면 이후에 이 원격 호출을 시도하려고 하면 서킷 브레이커에 의해 호출하지 않고 예외를 발생시킨다.</p>



<figure><a href="https://wraithkim.files.wordpress.com/2022/03/image2022-3-11_16-56-3.png"><img data-attachment-id="1886" data-permalink="https://wraithkim.wordpress.com/image2022-3-11_16-56-3/" data-orig-file="https://wraithkim.files.wordpress.com/2022/03/image2022-3-11_16-56-3.png" data-orig-size="789,203" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="image2022-3-11_16-56-3" data-image-description="" data-image-caption="" data-medium-file="https://wraithkim.files.wordpress.com/2022/03/image2022-3-11_16-56-3.png?w=300" data-large-file="https://wraithkim.files.wordpress.com/2022/03/image2022-3-11_16-56-3.png?w=789" src="https://wraithkim.files.wordpress.com/2022/03/image2022-3-11_16-56-3.png?w=789" alt="" title="Kim Dong Hwan[ 김동환 ] > Circuit Breaker > image2022-3-11_16-56-3.png" sizes="(max-width: 789px) 100vw, 789px"></a></figure>



<p>위의 그림은 서킷 브레이커의 상태 머신을 나타낸다. 여기서 closed는 원격 호출이 가능한 상태를 의미한다. 장애가 누적되면 open 상태로 바뀌고 호출은 차단된다. 추가로 half_open이란 상태도 있는데 이는 다음과 같다. 서킷 브레이커는 장애가 발생한 상황 뿐만 아니라 장애가 복구된 상황도 고려했다. 마지막으로 원격 호출을 시도한 시점부터 정해진 시간이 지난 후에 다시 시도한다면, 서킷 브레이커는 원격 호출을 한다. 만약 호출이 성공했다면 장애가 복구되었다고 판단한다. 실패 했다면 다시 차단 상태로 바꾼다. 이와 같이 장애가 복구되었는지 판단하는 상태를 half_open이라고 한다.</p>



<h2>라이브러리화</h2>



<p>결국 차단할 지 나타내는 상태 변수와, 시도 횟수, 마지막 시도 시점, 반복문을 조합하면 간단한 서킷 브레이커가 완성된다. 하지만 이걸 매번 만드는 건 귀찮은 일이다. 또한 예로 들어, 차단할 조건을 몇 분 이내에 횟수를 초과했을 경우로 한다든지, 복구 조건도 10번 시도해서 50% 이상 성공하면 복구 시켜준다든지, 차단 시 오류 대신 단계를 넘어가게 한다든지 등 다양한 방법으로 개조할 수도 있다. 이런 번거로움을 없애기 위해 라이브러리로 보통 사용한다.</p>



<h2>다른 예시들</h2>



<p>위에선 예시로 원격 호출을 들었지만 뭐가 됐든 자원이 있는지 확인하는데 오래걸리거나 자원이 복구될 때까지 오래 걸리는 것이면 서킷브레이커를 활용하기 좋다. 예를 들어 쓰레드 풀에서 쓰레드를 가져다가 반납을 늦게 하는 환경이라면 언제 반납할 지도 모르는 걸 기다리지 말고 서킷브레이커로 차단시키는 방법도 있다. 또는 producer-consumer 관계에서 consumer가 소비하는 게 느리다면, 큐가 가득 찼을 때 서킷브레이커로 차단하도록 구성할 수도 있다.</p>
			
			
								</div>
</article></div>

Wraithkim의 지식공방

https://martinfowler.com/bliki/CircuitBreaker.html 서킷 브레이커는 장애가 난 외부 시스템에 요청을 낭비하지 않기 위해 사용하는 패턴이다. 배경 어떤 외부 시스템에 원격 호출을 하는 소프트웨어를 만들었다고 하자. 만약 이 외부 시스템에서 장애가 발생했다면 우리 입장에선 요청이 타임아웃 되는 걸 통해 알 수 있을 것이다. 하지만 단시간 내에 클라이언트가 우리 시스템을 수백번 넘게 실행한다면, 수백번의 요청이 타임아웃 날 것이다. 단지 […]

Circuit Breaker

댓글