회로 차단기 패턴

2025-04-04

회로 차단기 패턴은 애플리케이션이 원격 서비스 또는 리소스에 연결할 때 복구하는 데 다양한 시간이 걸릴 수 있는 오류를 처리하는 데 도움이 됩니다. 회로 차단기는 오류를 감지한 후 결함이 있는 서비스에 대한 액세스를 일시적으로 차단합니다. 이 작업은 시스템이 효과적으로 복구할 수 있도록 반복된 실패 시도를 방지합니다. 이 패턴은 애플리케이션의 안정성과 복원력을 향상시킬 수 있습니다.

컨텍스트 및 문제

분산 환경에서는 일시적인 오류로 인해 원격 리소스 및 서비스에 대한 호출이 실패할 수 있습니다. 일시적인 오류에는 초과 커밋되거나 일시적으로 사용할 수 없는 리소스, 느린 네트워크 연결 또는 시간 초과가 포함됩니다. 이러한 오류는 일반적으로 짧은 시간 후에 수정됩니다. 이러한 오류를 관리하려면 다시 시도 패턴과 같은 전략을 사용하도록 클라우드 애플리케이션을 디자인해야 합니다.

예기치 않은 이벤트는 수정하는 데 더 오래 걸리는 오류를 만들 수 있습니다. 이러한 오류는 연결의 일부 손실에서 전체 서비스 오류까지 심각도 범위가 될 수 있습니다. 이러한 상황에서 애플리케이션은 성공할 가능성이 없는 작업을 지속적으로 다시 시도해서는 안 됩니다. 대신 애플리케이션은 실패한 작업을 신속하게 인식하고 그에 따라 오류를 처리해야 합니다.

서비스가 사용 중인 경우 시스템의 한 부분에서 오류가 발생하면 연속 오류가 발생할 수 있습니다. 예를 들어 시간 초과를 구현하기 위해 서비스를 호출하는 작업을 구성할 수 있습니다. 이 기간 내에 서비스가 응답하지 않으면 작업이 실패 메시지와 함께 응답합니다.

그러나 이 전략은 제한 시간이 만료될 때까지 동일한 작업에 대한 동시 요청을 차단할 수 있습니다. 이러한 차단된 요청은 메모리, 스레드 및 데이터베이스 연결과 같은 중요한 시스템 리소스를 보유할 수 있습니다. 이 문제는 리소스를 소진할 수 있으며, 동일한 리소스를 사용해야 하는 시스템의 다른 관련 없는 부분이 실패할 수 있습니다.

이러한 상황에서는 작업이 즉시 실패하고 성공할 가능성이 있는 경우에만 서비스를 호출하려고 시도해야 합니다. 이 문제를 해결하려면 더 짧은 시간 제한 시간을 설정합니다. 그러나 대부분의 경우 작업이 성공할 수 있을 만큼 시간 초과가 충분한지 확인합니다.

해결 방법

회로 차단기 패턴을 사용하면 애플리케이션이 실패할 가능성이 있는 작업을 반복적으로 실행하지 못하게 할 수 있습니다. 이 패턴을 사용하면 오류가 수정될 때까지 기다리거나 오류가 영구적인지 확인할 때 CPU 주기를 낭비하지 않고 애플리케이션을 계속 실행할 수 있습니다. 회로 차단기 패턴을 사용하면 애플리케이션에서 오류가 해결되는 시기를 감지할 수도 있습니다. 오류가 해결되면 애플리케이션에서 작업을 다시 호출할 수 있습니다.

비고

회로 차단기 패턴은 재시도 패턴과 다른 용도로 사용됩니다. 다시 시도 패턴을 사용하면 애플리케이션이 최종적으로 성공할 것으로 예상하여 작업을 다시 시도할 수 있습니다. 회로 차단기 패턴은 애플리케이션이 실패할 가능성이 있는 작업을 수행할 수 없도록 합니다. 애플리케이션은 회로 차단기를 통해 작업 호출에 재시도 패턴을 사용하여 이 두 패턴을 결합할 수 있습니다. 그러나 재시도 논리는 회로 차단기가 반환하는 예외에 민감하게 반응해야 하며, 회로 차단기가 오류가 일시적이지 않음을 나타내면 재시도를 중지해야 합니다.

회로 차단기는 실패할 수 있는 작업에서 프록시 역할을 합니다. 프록시는 최근 오류 수를 모니터링하고 이 정보를 사용하여 작업을 계속할지 아니면 예외를 즉시 반환할지 결정해야 합니다.

다음 상태를 포함하는 상태 컴퓨터로 프록시를 구현할 수 있습니다. 이러한 상태는 전기 회로 차단기의 기능을 모방합니다.

종료: 애플리케이션의 요청이 작업으로 전달됩니다. 프록시는 최근 실패 횟수를 유지 관리합니다. 작업에 대한 호출이 실패하면 프록시가 이 수를 증가합니다. 최근 오류 수가 지정된 기간 내에 지정된 임계값을 초과하면 프록시가 Open 상태로 전환되고 시간 제한 타이머가 시작됩니다. 타이머가 만료되면 프록시가 반쯤 열려 있는 상태로 전환됩니다.

비고

제한 시간 동안 시스템은 애플리케이션이 작업을 다시 시도하도록 허용하기 전에 오류를 발생시킨 문제를 해결하려고 합니다.
열다: 애플리케이션의 요청이 즉시 실패하고 예외가 애플리케이션에 반환됩니다.
하프 오픈: 애플리케이션에서 제한된 수의 요청이 작업을 통과하고 호출할 수 있습니다. 이러한 요청이 성공하면 회로 차단기는 오류를 발생시킨 오류가 수정되고 회로 차단기가 닫힌 상태로 전환된다고 가정합니다. 오류 카운터가 다시 설정됩니다. 요청이 실패하면 회로 차단기는 오류가 여전히 존재한다고 가정하므로 열기 상태로 되돌려집니다. 시스템이 오류에서 복구할 수 있도록 시간 제한 타이머를 다시 시작합니다.

비고

하프 오픈 상태는 복구 서비스가 갑자기 요청으로 넘쳐나지 않도록 방지하는 데 도움이 됩니다. 서비스가 복구되면 복구가 완료될 때까지 제한된 양의 요청을 지원할 수 있습니다. 그러나 복구가 진행되는 동안 작업이 넘쳐나면 서비스가 시간 초과되거나 다시 실패할 수 있습니다.

다음 다이어그램은 각 상태에 대한 카운터 작업을 보여 줍니다.

닫힌 상태의 오류 카운터는 시간 기준입니다. 주기적으로 자동으로 다시 설정됩니다. 이 디자인은 회로 차단기가 가끔 오류가 발생하는 경우 열기 상태로 들어가지 않도록 하는 데 도움이 됩니다. 오류 임계값은 지정된 간격 동안 지정된 수의 실패가 발생하는 경우에만 Open 상태를 트리거합니다.

하프 오픈 상태의 성공 카운터는 작업을 호출하는 데 성공한 시도 횟수를 기록합니다. 회로 차단기는 지정된 수의 성공적인 연속 작업 호출 후 닫힌 상태로 되돌아갑니다. 호출에 실패하면 회로 차단기가 즉시 Open 상태가 되며 다음에 반쯤 열린 상태가 되면 성공 카운터가 다시 설정됩니다.

비고

시스템 복구는 실패한 구성 요소 복원 또는 다시 시작 또는 네트워크 연결 복구와 같은 외부 작업을 기반으로 합니다.

회로 차단기 패턴은 시스템이 오류로부터 복구되는 동안 안정성을 제공하여 성능에 대한 영향을 최소화합니다. 시스템의 응답 시간을 유지하는 데 도움이 될 수 있습니다. 이 패턴은 작업이 실패할 가능성이 있을 경우, 시간 초과되거나 응답이 없는 상태로 기다리지 않고 즉시 요청을 거부합니다. 회로 차단기가 상태를 변경할 때마다 이벤트를 발생시킬 경우 이 정보는 회로 차단기가 Open 상태로 전환될 때 보호된 시스템 구성 요소의 상태를 모니터링하거나 관리자에게 경고하는 데 도움이 될 수 있습니다.

이 패턴을 사용자 지정하고 다양한 유형의 오류에 맞게 조정할 수 있습니다. 예를 들어 회로 차단기에 증가하는 시간 제한 타이머를 적용할 수 있습니다. 처음에는 회로 차단기를 Open 상태로 몇 초 동안 배치할 수 있습니다. 오류가 해결되지 않으면 제한 시간을 몇 분으로 늘리고 그에 따라 조정합니다. 경우에 따라 오류를 반환하고 예외를 발생시키는 대신 Open 상태는 애플리케이션에 의미 있는 기본값을 반환할 수 있습니다.

비고

일반적으로 회로 차단기는 오류 수 및 시간 제한 기간과 같은 미리 구성된 임계값에 의존했습니다. 이 방법은 결정적이지만 때로는 최적이 아닌 동작을 초래했습니다.

AI 및 기계 학습을 사용하는 적응 기술은 실시간 트래픽 패턴, 변칙 및 기록 실패율에 따라 임계값을 동적으로 조정할 수 있습니다. 이 방법은 복원력과 효율성을 향상시킵니다.

문제 및 고려 사항

이 패턴을 구현할 때 다음 요소를 고려합니다.

예외 처리: 회로 차단기를 통해 작업을 호출하는 애플리케이션은 작업을 사용할 수 없는 경우 예외를 처리할 수 있어야 합니다. 예외 관리는 애플리케이션을 기반으로 합니다. 예를 들어 애플리케이션이 일시적으로 기능을 저하하거나, 대체 작업을 호출하여 동일한 작업을 수행하거나, 동일한 데이터를 가져오거나, 사용자에게 예외를 보고하고 나중에 다시 시도하도록 요청할 수 있습니다.
예외 유형: 요청 실패의 원인은 심각도에 따라 달라질 수 있습니다. 예를 들어 원격 서비스가 충돌하고 복구하는 데 몇 분이 필요하거나 오버로드된 서비스가 시간 초과를 유발하기 때문에 요청이 실패할 수 있습니다. 회로 차단기는 발생하는 예외 유형을 검사하고 이러한 예외의 특성에 따라 전략을 조정할 수 있습니다. 예를 들어 회로 차단기를 Open 상태로 트리거하려면 사용할 수 없는 서비스로 인한 오류 수에 비해 더 많은 시간 제한 예외가 필요할 수 있습니다.
모니터링: 회로 차단기는 운영 팀이 시스템 상태를 평가할 수 있도록 실패한 요청과 성공적인 요청 모두에 대한 명확한 관찰 가능성을 제공해야 합니다. 서비스 전반에서 엔드 투 엔드 가시성을 위해 분산 추적을 사용합니다.
복구: 회로 차단기가 보호되는 작업의 복구 패턴과 일치하도록 구성해야 합니다. 예를 들어 회로 차단기가 오랫동안 Open 상태로 유지되는 경우 오류의 원인이 해결되더라도 예외가 발생합니다. 마찬가지로 회로 차단기는 Open 상태에서 반쯤 열린 상태로 너무 빨리 전환할 경우 애플리케이션의 응답 시간을 변동시키고 줄일 수 있습니다.
실패한 작업 테스트:Open 상태에서는 타이머를 사용하여 하프 오픈 상태로 전환할 시기를 결정하는 대신 회로 차단기가 원격 서비스 또는 리소스를 주기적으로 ping하여 사용 가능한지 여부를 확인할 수 있습니다. 이 ping은 이전에 실패한 작업을 호출하거나 원격 서비스에서 제공하는 특별한 상태 검사 작업을 사용할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴참조하세요.
수동 재정의: 실패한 작업의 복구 시간이 매우 가변적인 경우 관리자가 회로 차단기를 닫고 오류 카운터를 다시 설정할 수 있는 수동 재설정 옵션을 제공해야 합니다. 마찬가지로 관리자는 회로 차단기를 강제로 열기 상태로 전환하고 보호된 작업을 일시적으로 사용할 수 없는 경우 시간 제한 타이머를 다시 시작할 수 있습니다.
동시성: 많은 수의 애플리케이션 동시 인스턴스가 동일한 회로 차단기에 액세스할 수 있습니다. 구현은 동시 요청을 차단하거나 작업에 대한 각 호출에 과도한 오버헤드를 추가해서는 안 됩니다.
리소스 구분: 여러 기본 독립 공급자가 있을 수 있는 경우 한 유형의 리소스에 대해 단일 회로 차단기를 사용하는 경우 주의해야 합니다. 예를 들어 여러 분할된 데이터베이스가 포함된 데이터 저장소에서는 한 분할된 데이터베이스에 완전히 액세스할 수 있고 다른 분할된 데이터베이스에는 일시적인 문제가 발생할 수 있습니다. 이러한 시나리오의 오류 응답이 병합되는 경우 애플리케이션은 오류가 발생할 가능성이 있는 경우에도 일부 분할된 데이터베이스에 액세스하려고 시도할 수 있습니다. 그리고 성공할 가능성이 있더라도 다른 분할된 데이터베이스에 대한 액세스가 차단될 수 있습니다.
가속화된 회로 차단: 때때로 실패 응답에는 회로 차단기를 즉시 트립시키고 최소 시간 동안 트립 상태를 유지할 수 있는 충분한 정보가 포함될 수 있습니다. 예를 들어 오버로드된 공유 리소스의 오류 응답은 애플리케이션이 즉시 다시 시도하는 대신 몇 분 후에 다시 시도해야 함을 나타낼 수 있습니다.
다중 리전 배포입니다: 단일 지역 또는 다중 리전 배포를 위한 회로 차단기를 디자인할 수 있습니다. 다중 변경 배포를 위해 설계하려면 제어된 장애 조치, 대기 시간 최적화 및 규정 준수를 보장하는 데 도움이 되는 글로벌 부하 분산 장치 또는 사용자 지정 지역 인식 회로 중단 전략을 사용합니다.
서비스 메시 회로 차단기: 애플리케이션 계층에서 또는 교차 절단 추상화된 기능으로 회로 차단기를 구현할 수 있습니다. 예를 들어 서비스 메시는 애플리케이션 코드를 수정하지 않고 사이드카 또는 독립된 기능으로 회로 차단을 지원하는 경우가 많습니다.

비고

서비스가 클라이언트를 제한하는 경우 HTTP 429(너무 많은 요청)를 반환하거나 서비스를 사용할 수 없는 경우 HTTP 503(서비스를 사용할 수 없음)을 반환할 수 있습니다. 응답에는 예상 지연 기간과 같은 다른 정보가 포함될 수 있습니다.
실패한 요청 재생: 단순히 빠르게 실패하는 대신 Open 상태에서 회로 차단기는 각 요청의 세부 정보를 업무 일지에 기록하고 원격 리소스 또는 서비스를 사용할 수 있게 되면 이러한 요청을 재생할 수 있도록 정렬할 수도 있습니다.
외부 서비스에 대한 부적절한 시간 제한: 회로 차단기는 시간이 오래 걸리는 외부 서비스의 오류로부터 애플리케이션을 완전히 보호하지 못할 수 있습니다. 제한 시간이 너무 길면 회로 차단기가 작업이 실패했음을 나타내기 전에 회로 차단기를 실행하는 스레드가 장기간 차단될 수 있습니다. 이 시간 동안 다른 많은 애플리케이션 인스턴스는 회로 차단기를 통해 서비스를 호출하고 모든 스레드가 실패하기 전에 여러 스레드를 연결하려고 시도할 수도 있습니다.
컴퓨팅 다각화에 대한 적응성: 회로 차단기는 콜드 시작 및 확장성과 같은 요인이 오류 처리에 영향을 미치는 서버리스 워크로드에서 컨테이너화된 워크로드에 이르기까지 다양한 컴퓨팅 환경을 고려해야 합니다. 적응형 접근 방식은 컴퓨팅 유형에 따라 전략을 동적으로 조정할 수 있으므로 이질적인 아키텍처 전반에서 복원력을 보장할 수 있습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

이러한 작업이 실패할 가능성이 있는 경우 과도한 원격 서비스 호출 또는 공유 리소스에 대한 액세스 요청을 중지하여 연속 실패를 방지하려고 합니다.
실시간 장애 신호를 기반으로 트래픽을 지능적으로 라우팅하여 다중 지역 복원력을 향상시키려고 합니다.
서비스 수준 목표를 유지하고 대기 시간이 긴 서비스에서 성능 저하를 방지할 수 있도록 느린 종속성으로부터 보호하려고 합니다.
일시적인 연결 문제를 관리하고 분산 환경에서 요청 오류를 줄이려고 합니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

메모리 내 데이터 구조와 같은 애플리케이션의 로컬 프라이빗 리소스에 대한 액세스를 관리해야 합니다. 이 환경에서 회로 차단기는 시스템에 오버헤드를 추가합니다.
애플리케이션의 비즈니스 논리에서 예외를 처리하는 대신 사용해야 합니다.
잘 알려진 재시도 알고리즘은 충분하며 종속성은 재시도 메커니즘을 처리하도록 설계되었습니다. 이 시나리오에서는 애플리케이션의 회로 차단기가 시스템에 불필요한 복잡성을 더할 수 있습니다.
회로 차단기가 다시 설정될 때까지 기다리면 허용할 수 없는 지연이 발생할 수 있습니다.
메시지 기반 또는 이벤트 기반 아키텍처가 있는 경우, 이는 종종 실패한 메시지를 수동 또는 지연 처리할 수 있도록 배달 실패 메시지를 '데드 레터 큐'로 라우팅하기 때문입니다. 기본 제공 오류 격리 및 재시도 메커니즘은 종종 충분합니다.
오류 복구는 전역 부하 분산 장치 또는 서비스 메시의 상태 검사와 같은 인프라 또는 플랫폼 수준에서 관리됩니다.

워크로드 디자인

워크로드 디자인에서 회로 차단기 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

기둥	이 패턴으로 핵심 목표를 지원하는 방법
안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다.	이 패턴은 오류 종속성 오버로드를 방지하는 데 도움이 됩니다. 이 패턴을 사용하여 워크로드의 정상적인 저하를 트리거합니다. 자동 복구 기능이 있는 회로 차단기를 결합하여 자체 보존 및 자기 치유를 제공합니다. - RE:03 오류 모드 분석 - 일시적인 오류 - RE:07 자기 보존
성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다.	이 패턴은 다시 시도 오류 접근 방식을 방지하므로 종속성 복구 중에 과도한 리소스 사용이 발생할 수 있으며 복구를 시도하는 종속성에 대한 성능을 오버로드할 수 있습니다. - PE:07 코드 및 인프라 - PE:11 라이브 문제 응답

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

예시

이 예제에서는 Azure Cosmos DB 수명 무료 계층을 사용하여 할당량 초과를 방지하는 데 도움이 되는 회로 차단기 패턴을 구현합니다. 이 계층은 주로 비임계 데이터를 위한 것이며, 초당 특정 리소스 단위 할당량을 할당하는 용량 계획에 따라 작동합니다. 계절적 이벤트 중에는 수요가 제공된 용량을 초과하여 응답이 429 발생할 수 있습니다.

수요 급증이 발생하면 동적 임계값이 있는 Azure Monitor 경고 는 운영 및 관리 팀에 데이터베이스에 더 많은 용량이 필요하다는 사실을 감지하고 사전에 알립니다. 동시에 연속 오류를 방지하기 위해 기록 오류 패턴 여행을 사용하여 조정되는 회로 차단기입니다. 이 상태에서 애플리케이션은 기본 또는 캐시된 응답을 반환하여 정상적으로 저하됩니다. 애플리케이션은 전반적인 시스템 안정성을 유지하면서 특정 데이터를 일시적으로 사용할 수 없음을 사용자에게 알릴 수 있습니다.

이 전략은 비즈니스 근거에 부합하는 복원력을 향상시킵니다. 워크로드 팀이 예기치 않게 운영 비용을 늘리지 않고 의도적으로 비용 증가를 관리하고 서비스 품질을 유지할 수 있도록 용량 급증을 제어합니다. 수요가 가라앉거나 용량 증가가 확인되면 회로 차단기가 다시 설정되고 애플리케이션이 기술 및 예산 목표 모두에 부합하는 전체 기능으로 돌아갑니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

흐름 A: 닫힌 상태

시스템은 정상적으로 작동하며 모든 요청은 HTTP 응답을 반환하지 않고 데이터베이스에 429 도달합니다.
회로 차단기는 닫힌 상태로 유지되며 기본 또는 캐시된 응답은 필요하지 않습니다.

흐름 B: 열린 상태

회로 차단기가 첫 번째 429 응답을 받으면 Open 상태로 돌아갑니다.
후속 요청은 즉시 단락되어 기본 또는 캐시된 응답을 반환하고 사용자에게 일시적인 성능 저하를 알릴 수 있습니다. 애플리케이션은 추가 오버로드로부터 보호됩니다.
Azure Monitor는 로그 및 원격 분석 데이터를 수신하고 동적 임계값에 대해 평가합니다. 경고 규칙의 조건이 충족되면 경고가 트리거됩니다.
작업 그룹은 작업 팀에 오버로드 조건에 대해 사전에 알깁니다.
워크로드 팀 승인 후 운영 팀은 프로비전된 처리량을 늘려 오버로드를 완화하거나 부하가 자연스럽게 가라앉는 경우 크기 조정을 지연할 수 있습니다.

흐름 C: Half-Open 상태

미리 정의된 제한 시간이 지나면 회로 차단기는 제한된 수의 평가판 요청을 허용하는 반쯤 열린 상태로 들어갑니다.
응답을 반환 429 하지 않고 이러한 평가판 요청이 성공하면 차단기가 닫힌 상태로 다시 설정되고 정상적인 작업이 Flow A로 다시 복원됩니다. 오류가 지속되면 차단기는 열기 상태 또는 흐름 B로 되돌아갑니다.

구성 요소

Azure App Service 는 클라이언트 요청의 기본 진입점 역할을 하는 웹 애플리케이션을 호스트합니다. 애플리케이션 코드는 회로 차단기 정책을 적용하고 회로가 열릴 때 기본 또는 캐시된 응답을 제공하는 논리를 구현합니다. 이 아키텍처는 다운스트림 시스템의 오버로드를 방지하고 최대 수요 또는 실패 시 사용자 환경을 유지하는 데 도움이 됩니다.
Azure Cosmos DB 애플리케이션의 데이터 저장소 중 하나입니다. 소규모 프로덕션 워크로드에 이상적인 무료 계층을 통해 비임계 데이터를 제공합니다. 회로 차단기 메커니즘은 수요가 많은 기간 동안 데이터베이스에 대한 트래픽을 제한하는 데 도움이 됩니다.
Azure Monitor 는 중앙 집중식 모니터링 솔루션으로 작동합니다. 모든 활동 로그를 집계하여 포괄적인 엔드 투 엔드 관찰 가능성을 보장합니다. Azure Monitor는 집계 및 분석을 위해 App Service에서 로그 및 원격 분석 데이터와 Azure Cosmos DB(예: 응답 수)에서 429 주요 메트릭을 받습니다.
Azure Monitor 경고는 기록 데이터를 기반으로 잠재적인 중단을 식별하기 위해 경고 규칙을 동적 임계값에 대해 비교합니다. 미리 정의된 경고는 임계값이 위반되면 운영 팀에 알립니다.

경우에 따라 워크로드 팀은 프로비전된 처리량의 증가를 승인할 수 있지만 운영 팀은 부하가 너무 높지 않기 때문에 시스템이 자체적으로 복구할 수 있을 것으로 예상합니다. 이러한 경우 회로 차단기 제한 시간이 자연스럽게 경과합니다. 이 시간 동안 429 응답이 중단되면 임계값 계산은 장기간 중단을 감지하고 학습 알고리즘에서 제외합니다. 따라서 다음에 오버로드가 발생할 때 임계값은 Azure Cosmos DB에서 더 높은 오류 속도를 대기하여 알림을 지연합니다. 이러한 조정을 통해 회로 차단기는 즉각적인 경고 없이 문제를 처리할 수 있으므로 비용과 운영 효율성이 향상됩니다.

신뢰할 수 있는 웹앱 패턴은 회로 차단기 패턴을 클라우드에 수렴하는 웹 애플리케이션에 적용합니다.
다시 시도 패턴은 애플리케이션이 이전에 실패한 작업을 투명하게 다시 시도하여 서비스 또는 네트워크 리소스에 연결하려고 할 때 예상되는 임시 오류를 처리하는 방법을 설명합니다.
상태 엔드포인트 모니터링 패턴은 회로 차단기가 서비스에서 노출하는 엔드포인트에 요청을 전송하여 서비스의 상태를 테스트하는 방법을 설명합니다. 서비스는 상태를 나타내는 정보를 반환해야 합니다.