답변.

서킷 브레이커는 분산 시스템에서 연쇄적인 오류와 성능 저하를 방지하기 위한 아키텍처 패턴입니다. 그 본질은 외부 시스템에 대한 호출을 담당하는 구성 요소가 작업의 성공 여부를 검사하는 것입니다. 실패한 시도가 너무 많아지면 서킷 브레이커가 자동으로 "열리고" 시스템이 복구될 때까지 추가 호출이 차단됩니다.

예시: 인증 마이크로서비스가 응답하지 않을 경우, 주문 서비스는 서킷 브레이커를 사용하여 요청을 즉시 보내지 않고 오류를 반환하여 종속 시스템에 대한 높은 부하를 방지합니다.

파이썬 코드 예시 (pybreaker 라이브러리 사용):

import pybreaker
import requests

breaker = pybreaker.CircuitBreaker(fail_max=3, reset_timeout=30)

@breaker
def call_service():
    return requests.get("https://api.service.com/data")

try:
    response = call_service()
except pybreaker.CircuitBreakerError:
    print("서비스가 일시적으로 사용 불가능합니다. 나중에 다시 시도해 주세요.")

주요 특징:

실패의 전파를 제한하고 시스템 복구를 가속화합니다.
사용자에게 경고하여 애플리케이션이 다운되는 것을 방지하는 graceful degradation을 허용합니다.
신뢰할 수 없거나 과부하가 걸린 시스템과의 통합에 적합합니다.

함정 질문.

서킷 브레이커는 재시도와 같은 것인가요?

아니요. 재시도는 실패한 작업을 반복하지만, 서킷 브레이커는 많은 실패가 발생할 경우 호출 체인을 끊어 시스템에 휴식을 줍니다. 일반적으로 이 패턴은 조합하여 사용됩니다: 내부에서 재시도하고 외부에서 서킷 브레이커를 사용합니다.

자체 마이크로서비스 간에 서킷 브레이커를 도입해야 하나요, 동시에 배포되는 경우에?

네, 서비스가 내결함성 또는 네트워크 장애를 경험할 수 있는 경우에 필요합니다. 구성 오류나 부하에 대한 위험은 아무도 면역이 아닙니다, 당신의 마이크로서비스조차도요.

서킷 브레이커는 외부 API 통합에만 필요하나요?

아니요, 이 패턴은 데이터베이스, 캐시, 메시지 큐를 포함한 자체 인프라 내에서의 신뢰할 수 없는 상호 작용에도 적용될 수 있습니다.

서킷 브레이커는 아키텍처 수준에서 무엇이며, 언제, 왜 적용해야 하나요?

답변.

함정 질문.